01 Oct, 2005

1 commit

  • The following patch updates the way SELinux classifies and handles IP
    based protocols.

    Currently, IP sockets are classified by SELinux as being either TCP, UDP
    or 'Raw', the latter being a default for IP socket that is not TCP or UDP.

    The classification code is out of date and uses only the socket type
    parameter to socket(2) to determine the class of IP socket. So, any
    socket created with SOCK_STREAM will be classified by SELinux as TCP, and
    SOCK_DGRAM as UDP. Also, other socket types such as SOCK_SEQPACKET and
    SOCK_DCCP are currently ignored by SELinux, which classifies them as
    generic sockets, which means they don't even get basic IP level checking.

    This patch changes the SELinux IP socket classification logic, so that
    only an IPPROTO_IP protocol value passed to socket(2) classify the socket
    as TCP or UDP. The patch also drops the check for SOCK_RAW and converts
    it into a default, so that socket types like SOCK_DCCP and SOCK_SEQPACKET
    are classified as SECCLASS_RAWIP_SOCKET (instead of generic sockets).

    Note that protocol-specific support for SCTP, DCCP etc. is not addressed
    here, we're just getting these protocols checked at the IP layer.

    This fixes a reported problem where SCTP sockets were being recognized as
    generic SELinux sockets yet still being passed in one case to an IP level
    check, which then fails for generic sockets.

    It will also fix bugs where any SOCK_STREAM socket is classified as TCP or
    any SOCK_DGRAM socket is classified as UDP.

    This patch also unifies the way IP sockets classes are determined in
    selinux_socket_bind(), so we use the already calculated value instead of
    trying to recalculate it.

    Signed-off-by: James Morris
    Signed-off-by: Stephen Smalley
    Signed-off-by: Linus Torvalds

    James Morris
     

29 Sep, 2005

1 commit

  • The attached patch adds extra permission grants to keys for the possessor of a
    key in addition to the owner, group and other permissions bits. This makes
    SUID binaries easier to support without going as far as labelling keys and key
    targets using the LSM facilities.

    This patch adds a second "pointer type" to key structures (struct key_ref *)
    that can have the bottom bit of the address set to indicate the possession of
    a key. This is propagated through searches from the keyring to the discovered
    key. It has been made a separate type so that the compiler can spot attempts
    to dereference a potentially incorrect pointer.

    The "possession" attribute can't be attached to a key structure directly as
    it's not an intrinsic property of a key.

    Pointers to keys have been replaced with struct key_ref *'s wherever
    possession information needs to be passed through.

    This does assume that the bottom bit of the pointer will always be zero on
    return from kmem_cache_alloc().

    The key reference type has been made into a typedef so that at least it can be
    located in the sources, even though it's basically a pointer to an undefined
    type. I've also renamed the accessor functions to be more useful, and all
    reference variables should now end in "_ref".

    Signed-Off-By: David Howells
    Signed-off-by: Linus Torvalds

    David Howells
     

18 Sep, 2005

2 commits


14 Sep, 2005

2 commits


10 Sep, 2005

6 commits

  • With the use of RCU in files structure, the look-up of files using fds can now
    be lock-free. The lookup is protected by rcu_read_lock()/rcu_read_unlock().
    This patch changes the readers to use lock-free lookup.

    Signed-off-by: Maneesh Soni
    Signed-off-by: Ravikiran Thirumalai
    Signed-off-by: Dipankar Sarma
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     
  • In order for the RCU to work, the file table array, sets and their sizes must
    be updated atomically. Instead of ensuring this through too many memory
    barriers, we put the arrays and their sizes in a separate structure. This
    patch takes the first step of putting the file table elements in a separate
    structure fdtable that is embedded withing files_struct. It also changes all
    the users to refer to the file table using files_fdtable() macro. Subsequent
    applciation of RCU becomes easier after this.

    Signed-off-by: Dipankar Sarma
    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dipankar Sarma
     
  • This patch removes the inode_post_link and inode_post_rename LSM hooks as
    they are unused (and likely useless).

    Signed-off-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     
  • This patch removes the inode_post_create/mkdir/mknod/symlink LSM hooks as
    they are obsoleted by the new inode_init_security hook that enables atomic
    inode security labeling.

    If anyone sees any reason to retain these hooks, please speak now. Also,
    is anyone using the post_rename/link hooks; if not, those could also be
    removed.

    Signed-off-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     
  • This patch modifies tmpfs to call the inode_init_security LSM hook to set
    up the incore inode security state for new inodes before the inode becomes
    accessible via the dcache.

    As there is no underlying storage of security xattrs in this case, it is
    not necessary for the hook to return the (name, value, len) triple to the
    tmpfs code, so this patch also modifies the SELinux hook function to
    correctly handle the case where the (name, value, len) pointers are NULL.

    The hook call is needed in tmpfs in order to support proper security
    labeling of tmpfs inodes (e.g. for udev with tmpfs /dev in Fedora). With
    this change in place, we should then be able to remove the
    security_inode_post_create/mkdir/... hooks safely.

    Signed-off-by: Stephen Smalley
    Cc: Hugh Dickins
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     
  • The following patch set enables atomic security labeling of newly created
    inodes by altering the fs code to invoke a new LSM hook to obtain the security
    attribute to apply to a newly created inode and to set up the incore inode
    security state during the inode creation transaction. This parallels the
    existing processing for setting ACLs on newly created inodes. Otherwise, it
    is possible for new inodes to be accessed by another thread via the dcache
    prior to complete security setup (presently handled by the
    post_create/mkdir/... LSM hooks in the VFS) and a newly created inode may be
    left unlabeled on the disk in the event of a crash. SELinux presently works
    around the issue by ensuring that the incore inode security label is
    initialized to a special SID that is inaccessible to unprivileged processes
    (in accordance with policy), thereby preventing inappropriate access but
    potentially causing false denials on legitimate accesses. A simple test
    program demonstrates such false denials on SELinux, and the patch solves the
    problem. Similar such false denials have been encountered in real
    applications.

    This patch defines a new inode_init_security LSM hook to obtain the security
    attribute to apply to a newly created inode and to set up the incore inode
    security state for it, and adds a corresponding hook function implementation
    to SELinux.

    Signed-off-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     

05 Sep, 2005

3 commits

  • Linus Torvalds
     
  • This patch adds endian notations to the SELinux code.

    Signed-off-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     
  • This patch improves memory use by SELinux by both reducing the avtab node
    size and reducing the number of avtab nodes. The memory savings are
    substantial, e.g. on a 64-bit system after boot, James Morris reported the
    following data for the targeted and strict policies:

    #objs objsize kernmem
    Targeted:
    Before: 237888 40 9.1MB
    After: 19968 24 468KB

    Strict:
    Before: 571680 40 21.81MB
    After: 221052 24 5.06MB

    The improvement in memory use comes at a cost in the speed of security
    server computations of access vectors, but these computations are only
    required on AVC cache misses, and performance measurements by James Morris
    using a number of benchmarks have shown that the change does not cause any
    significant degradation.

    Note that a rebuilt policy via an updated policy toolchain
    (libsepol/checkpolicy) is required in order to gain the full benefits of
    this patch, although some memory savings benefits are immediately applied
    even to older policies (in particular, the reduction in avtab node size).
    Sources for the updated toolchain are presently available from the
    sourceforge CVS tree (http://sourceforge.net/cvs/?group_id=21266), and
    tarballs are available from http://www.flux.utah.edu/~sds.

    Signed-off-by: Stephen Smalley
    Signed-off-by: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     

02 Sep, 2005

1 commit


30 Aug, 2005

5 commits


23 Aug, 2005

1 commit

  • CONFIG_SECURITY=y and CONFIG_SYSFS=n results in the following compile
    error:

    ...
    LD vmlinux
    security/built-in.o: In function `securityfs_init':
    inode.c:(.init.text+0x1c2): undefined reference to `kernel_subsys'
    make: *** [vmlinux] Error 1

    Signed-off-by: Adrian Bunk
    Signed-off-by: Chris Wright

    Adrian Bunk
     

09 Aug, 2005

1 commit


05 Aug, 2005

2 commits

  • The attached patch makes sure that a keyring that failed to instantiate
    properly is destroyed without oopsing [CAN-2005-2099].

    The problem occurs in three stages:

    (1) The key allocator initialises the type-specific data to all zeroes. In
    the case of a keyring, this will become a link in the keyring name list
    when the keyring is instantiated.

    (2) If a user (any user) attempts to add a keyring with anything other than
    an empty payload, the keyring instantiation function will fail with an
    error and won't add the keyring to the name list.

    (3) The keyring's destructor then sees that the keyring has a description
    (name) and tries to remove the keyring from the name list, which oopses
    because the link pointers are both zero.

    This bug permits any user to take down a box trivially.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     
  • The attached patch prevents an error during the key session joining operation
    from hanging future joins in the D state [CAN-2005-2098].

    The problem is that the error handling path for the KEYCTL_JOIN_SESSION_KEYRING
    operation has one error path that doesn't release the session management
    semaphore. Further attempts to get the semaphore will then sleep for ever in
    the D state.

    This can happen in four situations, all involving an attempt to allocate a new
    session keyring:

    (1) ENOMEM.

    (2) The users key quota being reached.

    (3) A keyring name that is an empty string.

    (4) A keyring name that is too long.

    Any user may attempt this operation, and so any user can cause the problem to
    occur.

    Signed-Off-By: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells
     

04 Aug, 2005

1 commit

  • This fixes five bugs in the key management syscall interface:

    (1) add_key() returns 0 rather than EINVAL if the key type is "".

    Checking the key type isn't "" should be left to lookup_user_key().

    (2) request_key() returns ENOKEY rather than EPERM if the key type begins
    with a ".".

    lookup_user_key() can't do this because internal key types begin with a
    ".".

    (3) Key revocation always returns 0, even if it fails.

    (4) Key read can return EAGAIN rather than EACCES under some circumstances.

    A key is permitted to by read by a process if it doesn't grant read
    access, but it does grant search access and it is in the process's
    keyrings. That search returns EAGAIN if it fails, and this needs
    translating to EACCES.

    (5) request_key() never adds the new key to the destination keyring if one is
    supplied.

    The wrong macro was being used to test for an error condition: PTR_ERR()
    will always return true, whether or not there's an error; this should've
    been IS_ERR().

    Signed-Off-By: David Howells
    Signed-Off-By: Linus Torvalds

    David Howells
     

29 Jul, 2005

1 commit

  • This patch fixes the address length checks in the selinux_socket_connect
    hook to be no more restrictive than the underlying ipv4 and ipv6 code;
    otherwise, this hook can reject valid connect calls. This patch is in
    response to a bug report where an application was calling connect on an
    INET6 socket with an address that didn't include the optional scope id and
    failing due to these checks.

    Signed-off-by: Stephen Smalley
    Signed-off-by: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Stephen Smalley
     

28 Jul, 2005

1 commit

  • Implement kernel labeling of the MLS (multilevel security) field of
    security contexts for files which have no existing MLS field. This is to
    enable upgrades of a system from non-MLS to MLS without performing a full
    filesystem relabel including all of the mountpoints, which would be quite
    painful for users.

    With this patch, with MLS enabled, if a file has no MLS field, the kernel
    internally adds an MLS field to the in-core inode (but not to the on-disk
    file). This MLS field added is the default for the superblock, allowing
    per-mountpoint control over the values via fixed policy or mount options.

    This patch has been tested by enabling MLS without relabeling its
    filesystem, and seems to be working correctly.

    Signed-off-by: James Morris
    Signed-off-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Morris
     

13 Jul, 2005

1 commit


09 Jul, 2005

2 commits

  • Once again, the simple_attr in libfs was actually sufficient - I'd
    thought the __attribute__(format(printk(1,2))) was more mysterious than
    it really is.

    At last, here is the full patch to make seclvl use securityfs.

    Signed-off-by: Serge Hallyn
    Signed-off-by: Chris Wright
    --

    seclvl.c | 228 +++++++++++++++++++--------------------------------------------
    1 files changed, 70 insertions(+), 158 deletions(-)

    Index: linux-2.6.13-rc1/security/seclvl.c
    ===================================================================

    serue@us.ibm.com
     
  • Here's a small patch against 2.6.13-rc2 that adds securityfs, a virtual
    fs that all LSMs can use instead of creating their own. The fs should
    be mounted at /sys/kernel/security, and the fs creates that mount point.
    This will make the LSB people happy that we aren't creating a new
    /my_lsm_fs directory in the root for every different LSM.

    It has changed a bit since the last version, thanks to comments from
    Mike Waychison.

    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Chris Wright

    Greg KH
     

08 Jul, 2005

1 commit


02 Jul, 2005

1 commit


30 Jun, 2005

1 commit

  • Currently selinux_sb_copy_data requires an entire page be allocated to
    *orig when the function is called. This "requirement" is based on the fact
    that we call copy_page(in_save, nosec_save) and in_save = orig when the
    data is not FS_BINARY_MOUNTDATA. This means that if a caller were to call
    do_kern_mount with only about 10 bytes of options, they would get passed
    here and then we would corrupt PAGE_SIZE - 10 bytes of memory (with all
    zeros.)

    Currently it appears all in kernel FS's use one page of data so this has
    not been a problem. An out of kernel FS did just what is described above
    and it would almost always panic shortly after they tried to mount. From
    looking else where in the kernel it is obvious that this string of data
    must always be null terminated. (See example in do_mount where it always
    zeros the last byte.) Thus I suggest we use strcpy in place of copy_page.
    In this way we make sure the amount we copy is always less than or equal to
    the amount we received and since do_mount is zeroing the last byte this
    should be safe for all.

    Signed-off-by: Eric Paris
    Cc: Stephen Smalley
    Acked-by: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric Paris
     

26 Jun, 2005

4 commits

  • kfree(NULL) is legal.

    Signed-off-by: Jesper Juhl
    Acked-by: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     
  • 2.6.12-rc6-mm1 has a few remaining synchronize_kernel()s, some (but not
    all) in comments. This patch changes these synchronize_kernel() calls (and
    comments) to synchronize_rcu() or synchronize_sched() as follows:

    - arch/x86_64/kernel/mce.c mce_read(): change to synchronize_sched() to
    handle races with machine-check exceptions (synchronize_rcu() would not cut
    it given RCU implementations intended for hardcore realtime use.

    - drivers/input/serio/i8042.c i8042_stop(): change to synchronize_sched() to
    handle races with i8042_interrupt() interrupt handler. Again,
    synchronize_rcu() would not cut it given RCU implementations intended for
    hardcore realtime use.

    - include/*/kdebug.h comments: change to synchronize_sched() to handle races
    with NMIs. As before, synchronize_rcu() would not cut it...

    - include/linux/list.h comment: change to synchronize_rcu(), since this
    comment is for list_del_rcu().

    - security/keys/key.c unregister_key_type(): change to synchronize_rcu(),
    since this is interacting with RCU read side.

    - security/keys/process_keys.c install_session_keyring(): change to
    synchronize_rcu(), since this is interacting with RCU read side.

    Signed-off-by: "Paul E. McKenney"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Paul E. McKenney
     
  • This patch,based on sample code by Roland McGrath, adds an execheap
    permission check that controls the ability to make the heap executable so
    that this can be prevented in almost all cases (the X server is presently
    an exception, but this will hopefully be resolved in the future) so that
    even programs with execmem permission will need to have the anonymous
    memory mapped in order to make it executable.

    The only reason that we use a permission check for such restriction (vs.
    making it unconditional) is that the X module loader presently needs it; it
    could possibly be made unconditional in the future when X is changed.

    The policy patch for the execheap permission is available at:
    http://pearls.tuxedo-es.org/patches/selinux/policy-execheap.patch

    Signed-off-by: Lorenzo Hernandez Garcia-Hierro
    Acked-by: James Morris
    Acked-by: Stephen Smalley
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lorenzo Hernández García-Hierro
     
  • This patch adds an execstack permission check that controls the ability to
    make the main process stack executable so that attempts to make the stack
    executable can still be prevented even if the process is allowed the
    existing execmem permission in order to e.g. perform runtime code
    generation. Note that this does not yet address thread stacks. Note also
    that unlike the execmem check, the execstack check is only applied on
    mprotect calls, not mmap calls, as the current security_file_mmap hook is
    not passed the necessary information presently.

    The original author of the code that makes the distinction of the stack
    region, is Ingo Molnar, who wrote it within his patch for
    /proc//maps markers.
    (http://marc.theaimsgroup.com/?l=linux-kernel&m=110719881508591&w=2)

    The patches also can be found at:
    http://pearls.tuxedo-es.org/patches/selinux/policy-execstack.patch
    http://pearls.tuxedo-es.org/patches/selinux/kernel-execstack.patch

    policy-execstack.patch is the patch that needs to be applied to the policy in
    order to support the execstack permission and exclude it
    from general_domain_access within macros/core_macros.te.

    kernel-execstack.patch adds such permission to the SELinux code within
    the kernel and adds the proper permission check to the selinux_file_mprotect() hook.

    Signed-off-by: Lorenzo Hernandez Garcia-Hierro
    Acked-by: James Morris
    Acked-by: Stephen Smalley
    Cc: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Lorenzo Hernandez García-Hierro
     

24 Jun, 2005

2 commits

  • Export this symbol to GPL modules for eCryptfs: an out-of-tree GPL'ed
    filesystem.

    Signed off by: Michael Halcrow

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Halcrow
     
  • The attached patch makes the following changes:

    (1) There's a new special key type called ".request_key_auth".

    This is an authorisation key for when one process requests a key and
    another process is started to construct it. This type of key cannot be
    created by the user; nor can it be requested by kernel services.

    Authorisation keys hold two references:

    (a) Each refers to a key being constructed. When the key being
    constructed is instantiated the authorisation key is revoked,
    rendering it of no further use.

    (b) The "authorising process". This is either:

    (i) the process that called request_key(), or:

    (ii) if the process that called request_key() itself had an
    authorisation key in its session keyring, then the authorising
    process referred to by that authorisation key will also be
    referred to by the new authorisation key.

    This means that the process that initiated a chain of key requests
    will authorise the lot of them, and will, by default, wind up with
    the keys obtained from them in its keyrings.

    (2) request_key() creates an authorisation key which is then passed to
    /sbin/request-key in as part of a new session keyring.

    (3) When request_key() is searching for a key to hand back to the caller, if
    it comes across an authorisation key in the session keyring of the
    calling process, it will also search the keyrings of the process
    specified therein and it will use the specified process's credentials
    (fsuid, fsgid, groups) to do that rather than the calling process's
    credentials.

    This allows a process started by /sbin/request-key to find keys belonging
    to the authorising process.

    (4) A key can be read, even if the process executing KEYCTL_READ doesn't have
    direct read or search permission if that key is contained within the
    keyrings of a process specified by an authorisation key found within the
    calling process's session keyring, and is searchable using the
    credentials of the authorising process.

    This allows a process started by /sbin/request-key to read keys belonging
    to the authorising process.

    (5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
    KEYCTL_NEGATE will specify a keyring of the authorising process, rather
    than the process doing the instantiation.

    (6) One of the process keyrings can be nominated as the default to which
    request_key() should attach new keys if not otherwise specified. This is
    done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
    constants. The current setting can also be read using this call.

    (7) request_key() is partially interruptible. If it is waiting for another
    process to finish constructing a key, it can be interrupted. This permits
    a request-key cycle to be broken without recourse to rebooting.

    Signed-Off-By: David Howells
    Signed-Off-By: Benoit Boissinot
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    David Howells