07 Jan, 2009

3 commits

  • James Morris
     
  • Fix a regression in cap_capable() due to:

    commit 3b11a1decef07c19443d24ae926982bc8ec9f4c0
    Author: David Howells
    Date: Fri Nov 14 10:39:26 2008 +1100

    CRED: Differentiate objective and effective subjective credentials on a task

    The problem is that the above patch allows a process to have two sets of
    credentials, and for the most part uses the subjective credentials when
    accessing current's creds.

    There is, however, one exception: cap_capable(), and thus capable(), uses the
    real/objective credentials of the target task, whether or not it is the current
    task.

    Ordinarily this doesn't matter, since usually the two cred pointers in current
    point to the same set of creds. However, sys_faccessat() makes use of this
    facility to override the credentials of the calling process to make its test,
    without affecting the creds as seen from other processes.

    One of the things sys_faccessat() does is to make an adjustment to the
    effective capabilities mask, which cap_capable(), as it stands, then ignores.

    The affected capability check is in generic_permission():

    if (!(mask & MAY_EXEC) || execute_ok(inode))
    if (capable(CAP_DAC_OVERRIDE))
    return 0;

    This change passes the set of credentials to be tested down into the commoncap
    and SELinux code. The security functions called by capable() and
    has_capability() select the appropriate set of credentials from the process
    being checked.

    This can be tested by compiling the following program from the XFS testsuite:

    /*
    * t_access_root.c - trivial test program to show permission bug.
    *
    * Written by Michael Kerrisk - copyright ownership not pursued.
    * Sourced from: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html
    */
    #include
    #include
    #include
    #include
    #include
    #include

    #define UID 500
    #define GID 100
    #define PERM 0
    #define TESTPATH "/tmp/t_access"

    static void
    errExit(char *msg)
    {
    perror(msg);
    exit(EXIT_FAILURE);
    } /* errExit */

    static void
    accessTest(char *file, int mask, char *mstr)
    {
    printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
    } /* accessTest */

    int
    main(int argc, char *argv[])
    {
    int fd, perm, uid, gid;
    char *testpath;
    char cmd[PATH_MAX + 20];

    testpath = (argc > 1) ? argv[1] : TESTPATH;
    perm = (argc > 2) ? strtoul(argv[2], NULL, 8) : PERM;
    uid = (argc > 3) ? atoi(argv[3]) : UID;
    gid = (argc > 4) ? atoi(argv[4]) : GID;

    unlink(testpath);

    fd = open(testpath, O_RDWR | O_CREAT, 0);
    if (fd == -1) errExit("open");

    if (fchown(fd, uid, gid) == -1) errExit("fchown");
    if (fchmod(fd, perm) == -1) errExit("fchmod");
    close(fd);

    snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
    system(cmd);

    if (seteuid(uid) == -1) errExit("seteuid");

    accessTest(testpath, 0, "0");
    accessTest(testpath, R_OK, "R_OK");
    accessTest(testpath, W_OK, "W_OK");
    accessTest(testpath, X_OK, "X_OK");
    accessTest(testpath, R_OK | W_OK, "R_OK | W_OK");
    accessTest(testpath, R_OK | X_OK, "R_OK | X_OK");
    accessTest(testpath, W_OK | X_OK, "W_OK | X_OK");
    accessTest(testpath, R_OK | W_OK | X_OK, "R_OK | W_OK | X_OK");

    exit(EXIT_SUCCESS);
    } /* main */

    This can be run against an Ext3 filesystem as well as against an XFS
    filesystem. If successful, it will show:

    [root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
    ---------- 1 dhowells dhowells 0 2008-12-31 03:00 /tmp/xxx
    access(/tmp/xxx, 0) returns 0
    access(/tmp/xxx, R_OK) returns 0
    access(/tmp/xxx, W_OK) returns 0
    access(/tmp/xxx, X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK) returns 0
    access(/tmp/xxx, R_OK | X_OK) returns -1
    access(/tmp/xxx, W_OK | X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1

    If unsuccessful, it will show:

    [root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
    ---------- 1 dhowells dhowells 0 2008-12-31 02:56 /tmp/xxx
    access(/tmp/xxx, 0) returns 0
    access(/tmp/xxx, R_OK) returns -1
    access(/tmp/xxx, W_OK) returns -1
    access(/tmp/xxx, X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK) returns -1
    access(/tmp/xxx, R_OK | X_OK) returns -1
    access(/tmp/xxx, W_OK | X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1

    I've also tested the fix with the SELinux and syscalls LTP testsuites.

    Signed-off-by: David Howells
    Tested-by: J. Bruce Fields
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • This reverts commit 14eaddc967b16017d4a1a24d2be6c28ecbe06ed8.

    David has a better version to come.

    James Morris
     

06 Jan, 2009

1 commit

  • We used to have rather schizophrenic set of checks for NULL ->i_op even
    though it had been eliminated years ago. You'd need to go out of your
    way to set it to NULL explicitly _and_ a bunch of code would die on
    such inodes anyway. After killing two remaining places that still
    did that bogosity, all that crap can go away.

    Signed-off-by: Al Viro

    Al Viro
     

05 Jan, 2009

1 commit

  • Fix a regression in cap_capable() due to:

    commit 5ff7711e635b32f0a1e558227d030c7e45b4a465
    Author: David Howells
    Date: Wed Dec 31 02:52:28 2008 +0000

    CRED: Differentiate objective and effective subjective credentials on a task

    The problem is that the above patch allows a process to have two sets of
    credentials, and for the most part uses the subjective credentials when
    accessing current's creds.

    There is, however, one exception: cap_capable(), and thus capable(), uses the
    real/objective credentials of the target task, whether or not it is the current
    task.

    Ordinarily this doesn't matter, since usually the two cred pointers in current
    point to the same set of creds. However, sys_faccessat() makes use of this
    facility to override the credentials of the calling process to make its test,
    without affecting the creds as seen from other processes.

    One of the things sys_faccessat() does is to make an adjustment to the
    effective capabilities mask, which cap_capable(), as it stands, then ignores.

    The affected capability check is in generic_permission():

    if (!(mask & MAY_EXEC) || execute_ok(inode))
    if (capable(CAP_DAC_OVERRIDE))
    return 0;

    This change splits capable() from has_capability() down into the commoncap and
    SELinux code. The capable() security op now only deals with the current
    process, and uses the current process's subjective creds. A new security op -
    task_capable() - is introduced that can check any task's objective creds.

    strictly the capable() security op is superfluous with the presence of the
    task_capable() op, however it should be faster to call the capable() op since
    two fewer arguments need be passed down through the various layers.

    This can be tested by compiling the following program from the XFS testsuite:

    /*
    * t_access_root.c - trivial test program to show permission bug.
    *
    * Written by Michael Kerrisk - copyright ownership not pursued.
    * Sourced from: http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/6030.html
    */
    #include
    #include
    #include
    #include
    #include
    #include

    #define UID 500
    #define GID 100
    #define PERM 0
    #define TESTPATH "/tmp/t_access"

    static void
    errExit(char *msg)
    {
    perror(msg);
    exit(EXIT_FAILURE);
    } /* errExit */

    static void
    accessTest(char *file, int mask, char *mstr)
    {
    printf("access(%s, %s) returns %d\n", file, mstr, access(file, mask));
    } /* accessTest */

    int
    main(int argc, char *argv[])
    {
    int fd, perm, uid, gid;
    char *testpath;
    char cmd[PATH_MAX + 20];

    testpath = (argc > 1) ? argv[1] : TESTPATH;
    perm = (argc > 2) ? strtoul(argv[2], NULL, 8) : PERM;
    uid = (argc > 3) ? atoi(argv[3]) : UID;
    gid = (argc > 4) ? atoi(argv[4]) : GID;

    unlink(testpath);

    fd = open(testpath, O_RDWR | O_CREAT, 0);
    if (fd == -1) errExit("open");

    if (fchown(fd, uid, gid) == -1) errExit("fchown");
    if (fchmod(fd, perm) == -1) errExit("fchmod");
    close(fd);

    snprintf(cmd, sizeof(cmd), "ls -l %s", testpath);
    system(cmd);

    if (seteuid(uid) == -1) errExit("seteuid");

    accessTest(testpath, 0, "0");
    accessTest(testpath, R_OK, "R_OK");
    accessTest(testpath, W_OK, "W_OK");
    accessTest(testpath, X_OK, "X_OK");
    accessTest(testpath, R_OK | W_OK, "R_OK | W_OK");
    accessTest(testpath, R_OK | X_OK, "R_OK | X_OK");
    accessTest(testpath, W_OK | X_OK, "W_OK | X_OK");
    accessTest(testpath, R_OK | W_OK | X_OK, "R_OK | W_OK | X_OK");

    exit(EXIT_SUCCESS);
    } /* main */

    This can be run against an Ext3 filesystem as well as against an XFS
    filesystem. If successful, it will show:

    [root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
    ---------- 1 dhowells dhowells 0 2008-12-31 03:00 /tmp/xxx
    access(/tmp/xxx, 0) returns 0
    access(/tmp/xxx, R_OK) returns 0
    access(/tmp/xxx, W_OK) returns 0
    access(/tmp/xxx, X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK) returns 0
    access(/tmp/xxx, R_OK | X_OK) returns -1
    access(/tmp/xxx, W_OK | X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1

    If unsuccessful, it will show:

    [root@andromeda src]# ./t_access_root /tmp/xxx 0 4043 4043
    ---------- 1 dhowells dhowells 0 2008-12-31 02:56 /tmp/xxx
    access(/tmp/xxx, 0) returns 0
    access(/tmp/xxx, R_OK) returns -1
    access(/tmp/xxx, W_OK) returns -1
    access(/tmp/xxx, X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK) returns -1
    access(/tmp/xxx, R_OK | X_OK) returns -1
    access(/tmp/xxx, W_OK | X_OK) returns -1
    access(/tmp/xxx, R_OK | W_OK | X_OK) returns -1

    I've also tested the fix with the SELinux and syscalls LTP testsuites.

    Signed-off-by: David Howells
    Signed-off-by: James Morris

    David Howells
     

15 Nov, 2008

1 commit


14 Nov, 2008

9 commits

  • Prettify commoncap.c.

    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Reviewed-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Make execve() take advantage of copy-on-write credentials, allowing it to set
    up the credentials in advance, and then commit the whole lot after the point
    of no return.

    This patch and the preceding patches have been tested with the LTP SELinux
    testsuite.

    This patch makes several logical sets of alteration:

    (1) execve().

    The credential bits from struct linux_binprm are, for the most part,
    replaced with a single credentials pointer (bprm->cred). This means that
    all the creds can be calculated in advance and then applied at the point
    of no return with no possibility of failure.

    I would like to replace bprm->cap_effective with:

    cap_isclear(bprm->cap_effective)

    but this seems impossible due to special behaviour for processes of pid 1
    (they always retain their parent's capability masks where normally they'd
    be changed - see cap_bprm_set_creds()).

    The following sequence of events now happens:

    (a) At the start of do_execve, the current task's cred_exec_mutex is
    locked to prevent PTRACE_ATTACH from obsoleting the calculation of
    creds that we make.

    (a) prepare_exec_creds() is then called to make a copy of the current
    task's credentials and prepare it. This copy is then assigned to
    bprm->cred.

    This renders security_bprm_alloc() and security_bprm_free()
    unnecessary, and so they've been removed.

    (b) The determination of unsafe execution is now performed immediately
    after (a) rather than later on in the code. The result is stored in
    bprm->unsafe for future reference.

    (c) prepare_binprm() is called, possibly multiple times.

    (i) This applies the result of set[ug]id binaries to the new creds
    attached to bprm->cred. Personality bit clearance is recorded,
    but now deferred on the basis that the exec procedure may yet
    fail.

    (ii) This then calls the new security_bprm_set_creds(). This should
    calculate the new LSM and capability credentials into *bprm->cred.

    This folds together security_bprm_set() and parts of
    security_bprm_apply_creds() (these two have been removed).
    Anything that might fail must be done at this point.

    (iii) bprm->cred_prepared is set to 1.

    bprm->cred_prepared is 0 on the first pass of the security
    calculations, and 1 on all subsequent passes. This allows SELinux
    in (ii) to base its calculations only on the initial script and
    not on the interpreter.

    (d) flush_old_exec() is called to commit the task to execution. This
    performs the following steps with regard to credentials:

    (i) Clear pdeath_signal and set dumpable on certain circumstances that
    may not be covered by commit_creds().

    (ii) Clear any bits in current->personality that were deferred from
    (c.i).

    (e) install_exec_creds() [compute_creds() as was] is called to install the
    new credentials. This performs the following steps with regard to
    credentials:

    (i) Calls security_bprm_committing_creds() to apply any security
    requirements, such as flushing unauthorised files in SELinux, that
    must be done before the credentials are changed.

    This is made up of bits of security_bprm_apply_creds() and
    security_bprm_post_apply_creds(), both of which have been removed.
    This function is not allowed to fail; anything that might fail
    must have been done in (c.ii).

    (ii) Calls commit_creds() to apply the new credentials in a single
    assignment (more or less). Possibly pdeath_signal and dumpable
    should be part of struct creds.

    (iii) Unlocks the task's cred_replace_mutex, thus allowing
    PTRACE_ATTACH to take place.

    (iv) Clears The bprm->cred pointer as the credentials it was holding
    are now immutable.

    (v) Calls security_bprm_committed_creds() to apply any security
    alterations that must be done after the creds have been changed.
    SELinux uses this to flush signals and signal handlers.

    (f) If an error occurs before (d.i), bprm_free() will call abort_creds()
    to destroy the proposed new credentials and will then unlock
    cred_replace_mutex. No changes to the credentials will have been
    made.

    (2) LSM interface.

    A number of functions have been changed, added or removed:

    (*) security_bprm_alloc(), ->bprm_alloc_security()
    (*) security_bprm_free(), ->bprm_free_security()

    Removed in favour of preparing new credentials and modifying those.

    (*) security_bprm_apply_creds(), ->bprm_apply_creds()
    (*) security_bprm_post_apply_creds(), ->bprm_post_apply_creds()

    Removed; split between security_bprm_set_creds(),
    security_bprm_committing_creds() and security_bprm_committed_creds().

    (*) security_bprm_set(), ->bprm_set_security()

    Removed; folded into security_bprm_set_creds().

    (*) security_bprm_set_creds(), ->bprm_set_creds()

    New. The new credentials in bprm->creds should be checked and set up
    as appropriate. bprm->cred_prepared is 0 on the first call, 1 on the
    second and subsequent calls.

    (*) security_bprm_committing_creds(), ->bprm_committing_creds()
    (*) security_bprm_committed_creds(), ->bprm_committed_creds()

    New. Apply the security effects of the new credentials. This
    includes closing unauthorised files in SELinux. This function may not
    fail. When the former is called, the creds haven't yet been applied
    to the process; when the latter is called, they have.

    The former may access bprm->cred, the latter may not.

    (3) SELinux.

    SELinux has a number of changes, in addition to those to support the LSM
    interface changes mentioned above:

    (a) The bprm_security_struct struct has been removed in favour of using
    the credentials-under-construction approach.

    (c) flush_unauthorized_files() now takes a cred pointer and passes it on
    to inode_has_perm(), file_has_perm() and dentry_open().

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Inaugurate copy-on-write credentials management. This uses RCU to manage the
    credentials pointer in the task_struct with respect to accesses by other tasks.
    A process may only modify its own credentials, and so does not need locking to
    access or modify its own credentials.

    A mutex (cred_replace_mutex) is added to the task_struct to control the effect
    of PTRACE_ATTACHED on credential calculations, particularly with respect to
    execve().

    With this patch, the contents of an active credentials struct may not be
    changed directly; rather a new set of credentials must be prepared, modified
    and committed using something like the following sequence of events:

    struct cred *new = prepare_creds();
    int ret = blah(new);
    if (ret < 0) {
    abort_creds(new);
    return ret;
    }
    return commit_creds(new);

    There are some exceptions to this rule: the keyrings pointed to by the active
    credentials may be instantiated - keyrings violate the COW rule as managing
    COW keyrings is tricky, given that it is possible for a task to directly alter
    the keys in a keyring in use by another task.

    To help enforce this, various pointers to sets of credentials, such as those in
    the task_struct, are declared const. The purpose of this is compile-time
    discouragement of altering credentials through those pointers. Once a set of
    credentials has been made public through one of these pointers, it may not be
    modified, except under special circumstances:

    (1) Its reference count may incremented and decremented.

    (2) The keyrings to which it points may be modified, but not replaced.

    The only safe way to modify anything else is to create a replacement and commit
    using the functions described in Documentation/credentials.txt (which will be
    added by a later patch).

    This patch and the preceding patches have been tested with the LTP SELinux
    testsuite.

    This patch makes several logical sets of alteration:

    (1) execve().

    This now prepares and commits credentials in various places in the
    security code rather than altering the current creds directly.

    (2) Temporary credential overrides.

    do_coredump() and sys_faccessat() now prepare their own credentials and
    temporarily override the ones currently on the acting thread, whilst
    preventing interference from other threads by holding cred_replace_mutex
    on the thread being dumped.

    This will be replaced in a future patch by something that hands down the
    credentials directly to the functions being called, rather than altering
    the task's objective credentials.

    (3) LSM interface.

    A number of functions have been changed, added or removed:

    (*) security_capset_check(), ->capset_check()
    (*) security_capset_set(), ->capset_set()

    Removed in favour of security_capset().

    (*) security_capset(), ->capset()

    New. This is passed a pointer to the new creds, a pointer to the old
    creds and the proposed capability sets. It should fill in the new
    creds or return an error. All pointers, barring the pointer to the
    new creds, are now const.

    (*) security_bprm_apply_creds(), ->bprm_apply_creds()

    Changed; now returns a value, which will cause the process to be
    killed if it's an error.

    (*) security_task_alloc(), ->task_alloc_security()

    Removed in favour of security_prepare_creds().

    (*) security_cred_free(), ->cred_free()

    New. Free security data attached to cred->security.

    (*) security_prepare_creds(), ->cred_prepare()

    New. Duplicate any security data attached to cred->security.

    (*) security_commit_creds(), ->cred_commit()

    New. Apply any security effects for the upcoming installation of new
    security by commit_creds().

    (*) security_task_post_setuid(), ->task_post_setuid()

    Removed in favour of security_task_fix_setuid().

    (*) security_task_fix_setuid(), ->task_fix_setuid()

    Fix up the proposed new credentials for setuid(). This is used by
    cap_set_fix_setuid() to implicitly adjust capabilities in line with
    setuid() changes. Changes are made to the new credentials, rather
    than the task itself as in security_task_post_setuid().

    (*) security_task_reparent_to_init(), ->task_reparent_to_init()

    Removed. Instead the task being reparented to init is referred
    directly to init's credentials.

    NOTE! This results in the loss of some state: SELinux's osid no
    longer records the sid of the thread that forked it.

    (*) security_key_alloc(), ->key_alloc()
    (*) security_key_permission(), ->key_permission()

    Changed. These now take cred pointers rather than task pointers to
    refer to the security context.

    (4) sys_capset().

    This has been simplified and uses less locking. The LSM functions it
    calls have been merged.

    (5) reparent_to_kthreadd().

    This gives the current thread the same credentials as init by simply using
    commit_thread() to point that way.

    (6) __sigqueue_alloc() and switch_uid()

    __sigqueue_alloc() can't stop the target task from changing its creds
    beneath it, so this function gets a reference to the currently applicable
    user_struct which it then passes into the sigqueue struct it returns if
    successful.

    switch_uid() is now called from commit_creds(), and possibly should be
    folded into that. commit_creds() should take care of protecting
    __sigqueue_alloc().

    (7) [sg]et[ug]id() and co and [sg]et_current_groups.

    The set functions now all use prepare_creds(), commit_creds() and
    abort_creds() to build and check a new set of credentials before applying
    it.

    security_task_set[ug]id() is called inside the prepared section. This
    guarantees that nothing else will affect the creds until we've finished.

    The calling of set_dumpable() has been moved into commit_creds().

    Much of the functionality of set_user() has been moved into
    commit_creds().

    The get functions all simply access the data directly.

    (8) security_task_prctl() and cap_task_prctl().

    security_task_prctl() has been modified to return -ENOSYS if it doesn't
    want to handle a function, or otherwise return the return value directly
    rather than through an argument.

    Additionally, cap_task_prctl() now prepares a new set of credentials, even
    if it doesn't end up using it.

    (9) Keyrings.

    A number of changes have been made to the keyrings code:

    (a) switch_uid_keyring(), copy_keys(), exit_keys() and suid_keys() have
    all been dropped and built in to the credentials functions directly.
    They may want separating out again later.

    (b) key_alloc() and search_process_keyrings() now take a cred pointer
    rather than a task pointer to specify the security context.

    (c) copy_creds() gives a new thread within the same thread group a new
    thread keyring if its parent had one, otherwise it discards the thread
    keyring.

    (d) The authorisation key now points directly to the credentials to extend
    the search into rather pointing to the task that carries them.

    (e) Installing thread, process or session keyrings causes a new set of
    credentials to be created, even though it's not strictly necessary for
    process or session keyrings (they're shared).

    (10) Usermode helper.

    The usermode helper code now carries a cred struct pointer in its
    subprocess_info struct instead of a new session keyring pointer. This set
    of credentials is derived from init_cred and installed on the new process
    after it has been cloned.

    call_usermodehelper_setup() allocates the new credentials and
    call_usermodehelper_freeinfo() discards them if they haven't been used. A
    special cred function (prepare_usermodeinfo_creds()) is provided
    specifically for call_usermodehelper_setup() to call.

    call_usermodehelper_setkeys() adjusts the credentials to sport the
    supplied keyring as the new session keyring.

    (11) SELinux.

    SELinux has a number of changes, in addition to those to support the LSM
    interface changes mentioned above:

    (a) selinux_setprocattr() no longer does its check for whether the
    current ptracer can access processes with the new SID inside the lock
    that covers getting the ptracer's SID. Whilst this lock ensures that
    the check is done with the ptracer pinned, the result is only valid
    until the lock is released, so there's no point doing it inside the
    lock.

    (12) is_single_threaded().

    This function has been extracted from selinux_setprocattr() and put into
    a file of its own in the lib/ directory as join_session_keyring() now
    wants to use it too.

    The code in SELinux just checked to see whether a task shared mm_structs
    with other tasks (CLONE_VM), but that isn't good enough. We really want
    to know if they're part of the same thread group (CLONE_THREAD).

    (13) nfsd.

    The NFS server daemon now has to use the COW credentials to set the
    credentials it is going to use. It really needs to pass the credentials
    down to the functions it calls, but it can't do that until other patches
    in this series have been applied.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Use RCU to access another task's creds and to release a task's own creds.
    This means that it will be possible for the credentials of a task to be
    replaced without another task (a) requiring a full lock to read them, and (b)
    seeing deallocated memory.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Wrap current->cred and a few other accessors to hide their actual
    implementation.

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Separate the task security context from task_struct. At this point, the
    security data is temporarily embedded in the task_struct with two pointers
    pointing to it.

    Note that the Alpha arch is altered as it refers to (E)UID and (E)GID in
    entry.S via asm-offsets.

    With comment fixes Signed-off-by: Marc Dionne

    Signed-off-by: David Howells
    Acked-by: James Morris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    David Howells
     
  • Constify the kernel_cap_t arguments to the capset LSM hooks.

    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Acked-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Take away the ability for sys_capset() to affect processes other than current.

    This means that current will not need to lock its own credentials when reading
    them against interference by other processes.

    This has effectively been the case for a while anyway, since:

    (1) Without LSM enabled, sys_capset() is disallowed.

    (2) With file-based capabilities, sys_capset() is neutered.

    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Acked-by: Andrew G. Morgan
    Acked-by: James Morris
    Signed-off-by: James Morris

    David Howells
     
  • Wrap access to task credentials so that they can be separated more easily from
    the task_struct during the introduction of COW creds.

    Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id().

    Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more
    sense to use RCU directly rather than a convenient wrapper; these will be
    addressed by later patches.

    Signed-off-by: David Howells
    Reviewed-by: James Morris
    Acked-by: Serge Hallyn
    Cc: Andrew G. Morgan
    Signed-off-by: James Morris

    David Howells
     

11 Nov, 2008

3 commits

  • make an A or B type decision instead of a security decision. Currently
    this is the case at least for filesystems when deciding if a process can use
    the reserved 'root' blocks and for the case of things like the oom
    algorithm determining if processes are root processes and should be less
    likely to be killed. These types of security system requests should not be
    audited or logged since they are not really security decisions. It would be
    possible to solve this problem like the vm_enough_memory security check did
    by creating a new LSM interface and moving all of the policy into that
    interface but proves the needlessly bloat the LSM and provide complex
    indirection.

    This merely allows those decisions to be made where they belong and to not
    flood logs or printk with denials for thing that are not security decisions.

    Signed-off-by: Eric Paris
    Acked-by: Stephen Smalley
    Signed-off-by: James Morris

    Eric Paris
     
  • non-zero pE we will crate a new audit record which contains the entire set
    of known information about the executable in question, fP, fI, fE, fversion
    and includes the process's pE, pI, pP. Before and after the bprm capability
    are applied. This record type will only be emitted from execve syscalls.

    an example of making ping use fcaps instead of setuid:

    setcap "cat_net_raw+pe" /bin/ping

    type=SYSCALL msg=audit(1225742021.015:236): arch=c000003e syscall=59 success=yes exit=0 a0=1457f30 a1=14606b0 a2=1463940 a3=321b770a70 items=2 ppid=2929 pid=2963 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=3 comm="ping" exe="/bin/ping" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
    type=UNKNOWN[1321] msg=audit(1225742021.015:236): fver=2 fp=0000000000002000 fi=0000000000000000 fe=1 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=0000000000002000 new_pi=0000000000000000 new_pe=0000000000002000
    type=EXECVE msg=audit(1225742021.015:236): argc=2 a0="ping" a1="127.0.0.1"
    type=CWD msg=audit(1225742021.015:236): cwd="/home/test"
    type=PATH msg=audit(1225742021.015:236): item=0 name="/bin/ping" inode=49256 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ping_exec_t:s0 cap_fp=0000000000002000 cap_fe=1 cap_fver=2
    type=PATH msg=audit(1225742021.015:236): item=1 name=(null) inode=507915 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0

    Signed-off-by: Eric Paris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Eric Paris
     
  • functions which retrieve fcaps information from disk. This information is
    necessary so fcaps information can be collected and recorded by the audit
    system.

    Signed-off-by: Eric Paris
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Eric Paris
     

06 Nov, 2008

1 commit

  • Add a no_file_caps boot option when file capabilities are
    compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y).

    This allows distributions to ship a kernel with file capabilities
    compiled in, without forcing users to use (and understand and
    trust) them.

    When no_file_caps is specified at boot, then when a process executes
    a file, any file capabilities stored with that file will not be
    used in the calculation of the process' new capability sets.

    This means that booting with the no_file_caps boot option will
    not be the same as booting a kernel with file capabilities
    compiled out - in particular a task with CAP_SETPCAP will not
    have any chance of passing capabilities to another task (which
    isn't "really" possible anyway, and which may soon by killed
    altogether by David Howells in any case), and it will instead
    be able to put new capabilities in its pI. However since fI
    will always be empty and pI is masked with fI, it gains the
    task nothing.

    We also support the extra prctl options, setting securebits and
    dropping capabilities from the per-process bounding set.

    The other remaining difference is that killpriv, task_setscheduler,
    setioprio, and setnice will continue to be hooked. That will
    be noticable in the case where a root task changed its uid
    while keeping some caps, and another task owned by the new uid
    tries to change settings for the more privileged task.

    Changelog:
    Nov 05 2008: (v4) trivial port on top of always-start-\
    with-clear-caps patch
    Sep 23 2008: nixed file_caps_enabled when file caps are
    not compiled in as it isn't used.
    Document no_file_caps in kernel-parameters.txt.

    Signed-off-by: Serge Hallyn
    Acked-by: Andrew G. Morgan
    Signed-off-by: James Morris

    Serge E. Hallyn
     

02 Nov, 2008

1 commit

  • While Linux doesn't honor setuid on scripts. However, it mistakenly
    behaves differently for file capabilities.

    This patch fixes that behavior by making sure that get_file_caps()
    begins with empty bprm->caps_*. That way when a script is loaded,
    its bprm->caps_* may be filled when binfmt_misc calls prepare_binprm(),
    but they will be cleared again when binfmt_elf calls prepare_binprm()
    next to read the interpreter's file capabilities.

    Signed-off-by: Serge Hallyn
    Acked-by: David Howells
    Acked-by: Andrew G. Morgan
    Signed-off-by: Linus Torvalds

    Serge Hallyn
     

27 Sep, 2008

1 commit


14 Aug, 2008

1 commit

  • Fix the setting of PF_SUPERPRIV by __capable() as it could corrupt the flags
    the target process if that is not the current process and it is trying to
    change its own flags in a different way at the same time.

    __capable() is using neither atomic ops nor locking to protect t->flags. This
    patch removes __capable() and introduces has_capability() that doesn't set
    PF_SUPERPRIV on the process being queried.

    This patch further splits security_ptrace() in two:

    (1) security_ptrace_may_access(). This passes judgement on whether one
    process may access another only (PTRACE_MODE_ATTACH for ptrace() and
    PTRACE_MODE_READ for /proc), and takes a pointer to the child process.
    current is the parent.

    (2) security_ptrace_traceme(). This passes judgement on PTRACE_TRACEME only,
    and takes only a pointer to the parent process. current is the child.

    In Smack and commoncap, this uses has_capability() to determine whether
    the parent will be permitted to use PTRACE_ATTACH if normal checks fail.
    This does not set PF_SUPERPRIV.

    Two of the instances of __capable() actually only act on current, and so have
    been changed to calls to capable().

    Of the places that were using __capable():

    (1) The OOM killer calls __capable() thrice when weighing the killability of a
    process. All of these now use has_capability().

    (2) cap_ptrace() and smack_ptrace() were using __capable() to check to see
    whether the parent was allowed to trace any process. As mentioned above,
    these have been split. For PTRACE_ATTACH and /proc, capable() is now
    used, and for PTRACE_TRACEME, has_capability() is used.

    (3) cap_safe_nice() only ever saw current, so now uses capable().

    (4) smack_setprocattr() rejected accesses to tasks other than current just
    after calling __capable(), so the order of these two tests have been
    switched and capable() is used instead.

    (5) In smack_file_send_sigiotask(), we need to allow privileged processes to
    receive SIGIO on files they're manipulating.

    (6) In smack_task_wait(), we let a process wait for a privileged process,
    whether or not the process doing the waiting is privileged.

    I've tested this with the LTP SELinux and syscalls testscripts.

    Signed-off-by: David Howells
    Acked-by: Serge Hallyn
    Acked-by: Casey Schaufler
    Acked-by: Andrew G. Morgan
    Acked-by: Al Viro
    Signed-off-by: James Morris

    David Howells
     

25 Jul, 2008

1 commit

  • When cap_bset suppresses some of the forced (fP) capabilities of a file,
    it is generally only safe to execute the program if it understands how to
    recognize it doesn't have enough privilege to work correctly. For legacy
    applications (fE!=0), which have no non-destructive way to determine that
    they are missing privilege, we fail to execute (EPERM) any executable that
    requires fP capabilities, but would otherwise get pP' < fP. This is a
    fail-safe permission check.

    For some discussion of why it is problematic for (legacy) privileged
    applications to run with less than the set of capabilities requested for
    them, see:

    http://userweb.kernel.org/~morgan/sendmail-capabilities-war-story.html

    With this iteration of this support, we do not include setuid-0 based
    privilege protection from the bounding set. That is, the admin can still
    (ab)use the bounding set to suppress the privileges of a setuid-0 program.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: cleanup]
    Signed-off-by: Andrew G. Morgan
    Acked-by: Serge Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew G. Morgan
     

14 Jul, 2008

1 commit

  • Enable security modules to distinguish reading of process state via
    proc from full ptrace access by renaming ptrace_may_attach to
    ptrace_may_access and adding a mode argument indicating whether only
    read access or full attach access is requested. This allows security
    modules to permit access to reading process state without granting
    full ptrace access. The base DAC/capability checking remains unchanged.

    Read access to /proc/pid/mem continues to apply a full ptrace attach
    check since check_mem_permission() already requires the current task
    to already be ptracing the target. The other ptrace checks within
    proc for elements like environ, maps, and fds are changed to pass the
    read mode instead of attach.

    In the SELinux case, we model such reading of process state as a
    reading of a proc file labeled with the target process' label. This
    enables SELinux policy to permit such reading of process state without
    permitting control or manipulation of the target process, as there are
    a number of cases where programs probe for such information via proc
    but do not need to be able to control the target (e.g. procps,
    lsof, PolicyKit, ConsoleKit). At present we have to choose between
    allowing full ptrace in policy (more permissive than required/desired)
    or breaking functionality (or in some cases just silencing the denials
    via dontaudit rules but this can hide genuine attacks).

    This version of the patch incorporates comments from Casey Schaufler
    (change/replace existing ptrace_may_attach interface, pass access
    mode), and Chris Wright (provide greater consistency in the checking).

    Note that like their predecessors __ptrace_may_attach and
    ptrace_may_attach, the __ptrace_may_access and ptrace_may_access
    interfaces use different return value conventions from each other (0
    or -errno vs. 1 or 0). I retained this difference to avoid any
    changes to the caller logic but made the difference clearer by
    changing the latter interface to return a bool rather than an int and
    by adding a comment about it to ptrace.h for any future callers.

    Signed-off-by: Stephen Smalley
    Acked-by: Chris Wright
    Signed-off-by: James Morris

    Stephen Smalley
     

05 Jul, 2008

1 commit

  • The filesystem capability support meaning for CAP_SETPCAP is less powerful
    than the non-filesystem capability support. As such, when filesystem
    capabilities are configured, we should not permit CAP_SETPCAP to 'enhance'
    the current process through strace manipulation of a child process.

    Signed-off-by: Andrew G. Morgan
    Acked-by: Serge Hallyn
    Cc: David Howells
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew G. Morgan
     

29 Apr, 2008

1 commit


28 Apr, 2008

1 commit

  • Filesystem capability support makes it possible to do away with (set)uid-0
    based privilege and use capabilities instead. That is, with filesystem
    support for capabilities but without this present patch, it is (conceptually)
    possible to manage a system with capabilities alone and never need to obtain
    privilege via (set)uid-0.

    Of course, conceptually isn't quite the same as currently possible since few
    user applications, certainly not enough to run a viable system, are currently
    prepared to leverage capabilities to exercise privilege. Further, many
    applications exist that may never get upgraded in this way, and the kernel
    will continue to want to support their setuid-0 base privilege needs.

    Where pure-capability applications evolve and replace setuid-0 binaries, it is
    desirable that there be a mechanisms by which they can contain their
    privilege. In addition to leveraging the per-process bounding and inheritable
    sets, this should include suppressing the privilege of the uid-0 superuser
    from the process' tree of children.

    The feature added by this patch can be leveraged to suppress the privilege
    associated with (set)uid-0. This suppression requires CAP_SETPCAP to
    initiate, and only immediately affects the 'current' process (it is inherited
    through fork()/exec()). This reimplementation differs significantly from the
    historical support for securebits which was system-wide, unwieldy and which
    has ultimately withered to a dead relic in the source of the modern kernel.

    With this patch applied a process, that is capable(CAP_SETPCAP), can now drop
    all legacy privilege (through uid=0) for itself and all subsequently
    fork()'d/exec()'d children with:

    prctl(PR_SET_SECUREBITS, 0x2f);

    This patch represents a no-op unless CONFIG_SECURITY_FILE_CAPABILITIES is
    enabled at configure time.

    [akpm@linux-foundation.org: fix uninitialised var warning]
    [serue@us.ibm.com: capabilities: use cap_task_prctl when !CONFIG_SECURITY]
    Signed-off-by: Andrew G. Morgan
    Acked-by: Serge Hallyn
    Reviewed-by: James Morris
    Cc: Stephen Smalley
    Cc: Paul Moore
    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew G. Morgan
     

18 Apr, 2008

1 commit


21 Mar, 2008

1 commit

  • The original justification for cap_task_kill() was as follows:

    check_kill_permission() does appropriate uid equivalence checks.
    However with file capabilities it becomes possible for an
    unprivileged user to execute a file with file capabilities
    resulting in a more privileged task with the same uid.

    However now that cap_task_kill() always returns 0 (permission
    granted) when p->uid==current->uid, the whole hook is worthless,
    and only likely to create more subtle problems in the corner cases
    where it might still be called but return -EPERM. Those cases
    are basically when uids are different but euid/suid is equivalent
    as per the check in check_kill_permission().

    One example of a still-broken application is 'at' for non-root users.

    This patch removes cap_task_kill().

    Signed-off-by: Serge Hallyn
    Acked-by: Andrew G. Morgan
    Earlier-version-tested-by: Luiz Fernando N. Capitulino
    Acked-by: Casey Schaufler
    Signed-off-by: Linus Torvalds

    Serge Hallyn
     

24 Feb, 2008

1 commit

  • Simplify the uid equivalence check in cap_task_kill(). Anyone can kill a
    process owned by the same uid.

    Without this patch wireshark is reported to fail.

    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Andrew G. Morgan
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

06 Feb, 2008

3 commits

  • The capability bounding set is a set beyond which capabilities cannot grow.
    Currently cap_bset is per-system. It can be manipulated through sysctl,
    but only init can add capabilities. Root can remove capabilities. By
    default it includes all caps except CAP_SETPCAP.

    This patch makes the bounding set per-process when file capabilities are
    enabled. It is inherited at fork from parent. Noone can add elements,
    CAP_SETPCAP is required to remove them.

    One example use of this is to start a safer container. For instance, until
    device namespaces or per-container device whitelists are introduced, it is
    best to take CAP_MKNOD away from a container.

    The bounding set will not affect pP and pE immediately. It will only
    affect pP' and pE' after subsequent exec()s. It also does not affect pI,
    and exec() does not constrain pI'. So to really start a shell with no way
    of regain CAP_MKNOD, you would do

    prctl(PR_CAPBSET_DROP, CAP_MKNOD);
    cap_t cap = cap_get_proc();
    cap_value_t caparray[1];
    caparray[0] = CAP_MKNOD;
    cap_set_flag(cap, CAP_INHERITABLE, 1, caparray, CAP_DROP);
    cap_set_proc(cap);
    cap_free(cap);

    The following test program will get and set the bounding
    set (but not pI). For instance

    ./bset get
    (lists capabilities in bset)
    ./bset drop cap_net_raw
    (starts shell with new bset)
    (use capset, setuid binary, or binary with
    file capabilities to try to increase caps)

    ************************************************************
    cap_bound.c
    ************************************************************
    #include
    #include
    #include
    #include
    #include
    #include
    #include

    #ifndef PR_CAPBSET_READ
    #define PR_CAPBSET_READ 23
    #endif

    #ifndef PR_CAPBSET_DROP
    #define PR_CAPBSET_DROP 24
    #endif

    int usage(char *me)
    {
    printf("Usage: %s get\n", me);
    printf(" %s drop \n", me);
    return 1;
    }

    #define numcaps 32
    char *captable[numcaps] = {
    "cap_chown",
    "cap_dac_override",
    "cap_dac_read_search",
    "cap_fowner",
    "cap_fsetid",
    "cap_kill",
    "cap_setgid",
    "cap_setuid",
    "cap_setpcap",
    "cap_linux_immutable",
    "cap_net_bind_service",
    "cap_net_broadcast",
    "cap_net_admin",
    "cap_net_raw",
    "cap_ipc_lock",
    "cap_ipc_owner",
    "cap_sys_module",
    "cap_sys_rawio",
    "cap_sys_chroot",
    "cap_sys_ptrace",
    "cap_sys_pacct",
    "cap_sys_admin",
    "cap_sys_boot",
    "cap_sys_nice",
    "cap_sys_resource",
    "cap_sys_time",
    "cap_sys_tty_config",
    "cap_mknod",
    "cap_lease",
    "cap_audit_write",
    "cap_audit_control",
    "cap_setfcap"
    };

    int getbcap(void)
    {
    int comma=0;
    unsigned long i;
    int ret;

    printf("i know of %d capabilities\n", numcaps);
    printf("capability bounding set:");
    for (i=0; i< 0)
    perror("prctl");
    else if (ret==1)
    printf("%s%s", (comma++) ? ", " : " ", captable[i]);
    }
    printf("\n");
    return 0;
    }

    int capdrop(char *str)
    {
    unsigned long i;

    int found=0;
    for (i=0; i
    Signed-off-by: Andrew G. Morgan
    Cc: Stephen Smalley
    Cc: James Morris
    Cc: Chris Wright
    Cc: Casey Schaufler a
    Signed-off-by: "Serge E. Hallyn"
    Tested-by: Jiri Slaby
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     
  • The patch supports legacy (32-bit) capability userspace, and where possible
    translates 32-bit capabilities to/from userspace and the VFS to 64-bit
    kernel space capabilities. If a capability set cannot be compressed into
    32-bits for consumption by user space, the system call fails, with -ERANGE.

    FWIW libcap-2.00 supports this change (and earlier capability formats)

    http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/

    [akpm@linux-foundation.org: coding-syle fixes]
    [akpm@linux-foundation.org: use get_task_comm()]
    [ezk@cs.sunysb.edu: build fix]
    [akpm@linux-foundation.org: do not initialise statics to 0 or NULL]
    [akpm@linux-foundation.org: unused var]
    [serue@us.ibm.com: export __cap_ symbols]
    Signed-off-by: Andrew G. Morgan
    Cc: Stephen Smalley
    Acked-by: Serge Hallyn
    Cc: Chris Wright
    Cc: James Morris
    Cc: Casey Schaufler
    Signed-off-by: Erez Zadok
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morgan
     
  • Revert b68680e4731abbd78863063aaa0dca2a6d8cc723 to make way for the next
    patch: "Add 64-bit capability support to the kernel".

    We want to keep the vfs_cap_data.data[] structure, using two 'data's for
    64-bit caps (and later three for 96-bit caps), whereas
    b68680e4731abbd78863063aaa0dca2a6d8cc723 had gotten rid of the 'data' struct
    made its members inline.

    The 64-bit caps patch keeps the stack abuse fix at get_file_caps(), which was
    the more important part of that patch.

    [akpm@linux-foundation.org: coding-style fixes]
    Cc: Stephen Smalley
    Cc: Serge Hallyn
    Cc: Chris Wright
    Cc: James Morris
    Cc: Casey Schaufler
    Cc: Andrew Morgan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

22 Jan, 2008

1 commit

  • In linux-2.6.24-rc1, security/commoncap.c:cap_inh_is_capped() was
    introduced. It has the exact reverse of its intended behavior. This
    led to an unintended privilege esculation involving a process'
    inheritable capability set.

    To be exposed to this bug, you need to have Filesystem Capabilities
    enabled and in use. That is:

    - CONFIG_SECURITY_FILE_CAPABILITIES must be defined for the buggy code
    to be compiled in.

    - You also need to have files on your system marked with fI bits raised.

    Signed-off-by: Andrew G. Morgan

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

    Andrew G. Morgan
     

30 Nov, 2007

1 commit

  • An unprivileged process must be able to kill a setuid root program started
    by the same user. This is legacy behavior needed for instance for xinit to
    kill X when the window manager exits.

    When an unprivileged user runs a setuid root program in !SECURE_NOROOT
    mode, fP, fI, and fE are set full on, so pP' and pE' are full on. Then
    cap_task_kill() prevents the user from signaling the setuid root task.
    This is a change in behavior compared to when
    !CONFIG_SECURITY_FILE_CAPABILITIES.

    This patch introduces a special check into cap_task_kill() just to check
    whether a non-root user is signaling a setuid root program started by the
    same user. If so, then signal is allowed.

    Signed-off-by: Serge E. Hallyn
    Cc: Andrew Morgan
    Cc: Stephen Smalley
    Cc: Chris Wright
    Cc: James Morris
    Cc: Casey Schaufler
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

15 Nov, 2007

1 commit

  • Fix http://bugzilla.kernel.org/show_bug.cgi?id=9247

    Allow sigcont to be sent to a process with greater capabilities if it is in
    the same session. Otherwise, a shell from which I've started a root shell
    and done 'suspend' can't be restarted by the parent shell.

    Also don't do file-capabilities signaling checks when uids for the
    processes don't match, since the standard check_kill_permission will have
    done those checks.

    [akpm@linux-foundation.org: coding-style cleanups]
    Signed-off-by: Serge E. Hallyn
    Acked-by: Andrew Morgan
    Cc: Chris Wright
    Tested-by: "Theodore Ts'o"
    Cc: Stephen Smalley
    Cc: "Rafael J. Wysocki"
    Cc: Chris Wright
    Cc: James Morris
    Cc: Stephen Smalley
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

22 Oct, 2007

1 commit

  • Simplify the vfs_cap_data structure.

    Also fix get_file_caps which was declaring
    __le32 v1caps[XATTR_CAPS_SZ] on the stack, but
    XATTR_CAPS_SZ is already * sizeof(__le32).

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Serge E. Hallyn
    Cc: Andrew Morgan
    Cc: Chris Wright
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

20 Oct, 2007

1 commit

  • is_init() is an ambiguous name for the pid==1 check. Split it into
    is_global_init() and is_container_init().

    A cgroup init has it's tsk->pid == 1.

    A global init also has it's tsk->pid == 1 and it's active pid namespace
    is the init_pid_ns. But rather than check the active pid namespace,
    compare the task structure with 'init_pid_ns.child_reaper', which is
    initialized during boot to the /sbin/init process and never changes.

    Changelog:

    2.6.22-rc4-mm2-pidns1:
    - Use 'init_pid_ns.child_reaper' to determine if a given task is the
    global init (/sbin/init) process. This would improve performance
    and remove dependence on the task_pid().

    2.6.21-mm2-pidns2:

    - [Sukadev Bhattiprolu] Changed is_container_init() calls in {powerpc,
    ppc,avr32}/traps.c for the _exception() call to is_global_init().
    This way, we kill only the cgroup if the cgroup's init has a
    bug rather than force a kernel panic.

    [akpm@linux-foundation.org: fix comment]
    [sukadev@us.ibm.com: Use is_global_init() in arch/m32r/mm/fault.c]
    [bunk@stusta.de: kernel/pid.c: remove unused exports]
    [sukadev@us.ibm.com: Fix capability.c to work with threaded init]
    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Sukadev Bhattiprolu
    Acked-by: Pavel Emelianov
    Cc: Eric W. Biederman
    Cc: Cedric Le Goater
    Cc: Dave Hansen
    Cc: Herbert Poetzel
    Cc: Kirill Korotaev
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

19 Oct, 2007

1 commit

  • The non-filesystem capability meaning of CAP_SETPCAP is that a process, p1,
    can change the capabilities of another process, p2. This is not the
    meaning that was intended for this capability at all, and this
    implementation came about purely because, without filesystem capabilities,
    there was no way to use capabilities without one process bestowing them on
    another.

    Since we now have a filesystem support for capabilities we can fix the
    implementation of CAP_SETPCAP.

    The most significant thing about this change is that, with it in effect, no
    process can set the capabilities of another process.

    The capabilities of a program are set via the capability convolution
    rules:

    pI(post-exec) = pI(pre-exec)
    pP(post-exec) = (X(aka cap_bset) & fP) | (pI(post-exec) & fI)
    pE(post-exec) = fE ? pP(post-exec) : 0

    at exec() time. As such, the only influence the pre-exec() program can
    have on the post-exec() program's capabilities are through the pI
    capability set.

    The correct implementation for CAP_SETPCAP (and that enabled by this patch)
    is that it can be used to add extra pI capabilities to the current process
    - to be picked up by subsequent exec()s when the above convolution rules
    are applied.

    Here is how it works:

    Let's say we have a process, p. It has capability sets, pE, pP and pI.
    Generally, p, can change the value of its own pI to pI' where

    (pI' & ~pI) & ~pP = 0.

    That is, the only new things in pI' that were not present in pI need to
    be present in pP.

    The role of CAP_SETPCAP is basically to permit changes to pI beyond
    the above:

    if (pE & CAP_SETPCAP) {
    pI' = anything; /* ie., even (pI' & ~pI) & ~pP != 0 */
    }

    This capability is useful for things like login, which (say, via
    pam_cap) might want to raise certain inheritable capabilities for use
    by the children of the logged-in user's shell, but those capabilities
    are not useful to or needed by the login program itself.

    One such use might be to limit who can run ping. You set the
    capabilities of the 'ping' program to be "= cap_net_raw+i", and then
    only shells that have (pI & CAP_NET_RAW) will be able to run
    it. Without CAP_SETPCAP implemented as described above, login(pam_cap)
    would have to also have (pP & CAP_NET_RAW) in order to raise this
    capability and pass it on through the inheritable set.

    Signed-off-by: Andrew Morgan
    Signed-off-by: Serge E. Hallyn
    Cc: Stephen Smalley
    Cc: James Morris
    Cc: Casey Schaufler
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morgan
     

17 Oct, 2007

1 commit

  • This patch contains the following cleanups that are now possible:
    - remove the unused security_operations->inode_xattr_getsuffix
    - remove the no longer used security_operations->unregister_security
    - remove some no longer required exit code
    - remove a bunch of no longer used exports

    Signed-off-by: Adrian Bunk
    Acked-by: James Morris
    Cc: Chris Wright
    Cc: Stephen Smalley
    Cc: Serge Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Bunk