Re: [PATCH] remove sys_security

From: Stephen Smalley (sdsat_private)
Date: Wed Oct 23 2002 - 09:09:47 PDT

  • Next message: Christoph Hellwig: "Re: [PATCH] remove sys_security"

    On Wed, 23 Oct 2002, Stephen C. Tweedie wrote:
    
    > Good question --- what is the reason you need these, and are other
    > security modules likely to need similar functionality?  If so, there's
    > an argument for new syscalls which take a credentials/sid area as a
    > return argument.
    
    The extended *stat calls enable applications to obtain file SIDs along
    with the regular file status for a variety of purposes, e.g. SELinux
    provides patched versions of ls (displaying security contexts to users),
    find (searching for files with particular security contexts or displaying
    the contexts of files matching the find criteria to users), cp -p and tar
    (preserving contexts on copies and in archives), logrotate (preserving
    contexts when logs are rotated), and crond (checking the context on a
    user-generated crontab spool file to protect against running cron jobs
    with a given process SID from a less trusted source).  While you don't
    always need to get both the file status and the security attributes for a
    given file, you often do for programs like ls, cp, tar, etc.
    
    If we migrate SELinux to using extended attributes to store file security
    contexts (pending their merging into 2.5), then we could replace the
    extended *stat with getxattr, although getxattr doesn't provide an atomic
    way of getting both the regular file status information and the security
    attributes for a given file.  Closest approximation to stat_secure() would
    be an open(...O_RDONLY), fstat(), fgetxattr(), close() sequence to ensure
    that the file status and security attributes are from the same inode, but
    this assumes that you can always read the file in order to stat it and
    isn't exactly ideal.
    
    For System V IPC and socket IPC, the extended calls enable applications to
    obtain security information about the sender and the data so that the
    security-aware applications can make security decisions and label data
    appropriately.  An extended form of SCM_CREDENTIALS that supports
    additional security data and is not limited to local domain sockets [the
    SELinux calls work for INET sockets if labeled networking is used] might
    be reasonable for socket IPC.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    
    
    
    
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Wed Oct 23 2002 - 09:11:33 PDT