12 May, 2013

1 commit


28 Apr, 2013

20 commits


23 Feb, 2013

1 commit


24 Oct, 2012

1 commit

  • BugLink: http://bugs.launchpad.net/bugs/1056078

    Profile replacement can cause long chains of profiles to build up when
    the profile being replaced is pinned. When the pinned profile is finally
    freed, it puts the reference to its replacement, which may in turn nest
    another call to free_profile on the stack. Because this may happen for
    each profile in the replacedby chain this can result in a recusion that
    causes the stack to overflow.

    Break this nesting by directly walking the chain of replacedby profiles
    (ie. use iteration instead of recursion to free the list). This results
    in at most 2 levels of free_profile being called, while freeing a
    replacedby chain.

    Signed-off-by: John Johansen
    Signed-off-by: James Morris

    John Johansen
     

18 Oct, 2012

1 commit

  • The capability defines have moved causing the auto generated names
    of capabilities that apparmor uses in logging to be incorrect.

    Fix the autogenerated table source to uapi/linux/capability.h

    Reported-by: YanHong
    Reported-by: Krzysztof Kolasa
    Analyzed-by: Al Viro
    Signed-off-by: John Johansen
    Acked-by: David Howells
    Acked-by: James Morris
    Signed-off-by: Linus Torvalds

    John Johansen
     

05 Oct, 2012

1 commit


03 Oct, 2012

1 commit

  • Pull user namespace changes from Eric Biederman:
    "This is a mostly modest set of changes to enable basic user namespace
    support. This allows the code to code to compile with user namespaces
    enabled and removes the assumption there is only the initial user
    namespace. Everything is converted except for the most complex of the
    filesystems: autofs4, 9p, afs, ceph, cifs, coda, fuse, gfs2, ncpfs,
    nfs, ocfs2 and xfs as those patches need a bit more review.

    The strategy is to push kuid_t and kgid_t values are far down into
    subsystems and filesystems as reasonable. Leaving the make_kuid and
    from_kuid operations to happen at the edge of userspace, as the values
    come off the disk, and as the values come in from the network.
    Letting compile type incompatible compile errors (present when user
    namespaces are enabled) guide me to find the issues.

    The most tricky areas have been the places where we had an implicit
    union of uid and gid values and were storing them in an unsigned int.
    Those places were converted into explicit unions. I made certain to
    handle those places with simple trivial patches.

    Out of that work I discovered we have generic interfaces for storing
    quota by projid. I had never heard of the project identifiers before.
    Adding full user namespace support for project identifiers accounts
    for most of the code size growth in my git tree.

    Ultimately there will be work to relax privlige checks from
    "capable(FOO)" to "ns_capable(user_ns, FOO)" where it is safe allowing
    root in a user names to do those things that today we only forbid to
    non-root users because it will confuse suid root applications.

    While I was pushing kuid_t and kgid_t changes deep into the audit code
    I made a few other cleanups. I capitalized on the fact we process
    netlink messages in the context of the message sender. I removed
    usage of NETLINK_CRED, and started directly using current->tty.

    Some of these patches have also made it into maintainer trees, with no
    problems from identical code from different trees showing up in
    linux-next.

    After reading through all of this code I feel like I might be able to
    win a game of kernel trivial pursuit."

    Fix up some fairly trivial conflicts in netfilter uid/git logging code.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (107 commits)
    userns: Convert the ufs filesystem to use kuid/kgid where appropriate
    userns: Convert the udf filesystem to use kuid/kgid where appropriate
    userns: Convert ubifs to use kuid/kgid
    userns: Convert squashfs to use kuid/kgid where appropriate
    userns: Convert reiserfs to use kuid and kgid where appropriate
    userns: Convert jfs to use kuid/kgid where appropriate
    userns: Convert jffs2 to use kuid and kgid where appropriate
    userns: Convert hpfs to use kuid and kgid where appropriate
    userns: Convert btrfs to use kuid/kgid where appropriate
    userns: Convert bfs to use kuid/kgid where appropriate
    userns: Convert affs to use kuid/kgid wherwe appropriate
    userns: On alpha modify linux_to_osf_stat to use convert from kuids and kgids
    userns: On ia64 deal with current_uid and current_gid being kuid and kgid
    userns: On ppc convert current_uid from a kuid before printing.
    userns: Convert s390 getting uid and gid system calls to use kuid and kgid
    userns: Convert s390 hypfs to use kuid and kgid where appropriate
    userns: Convert binder ipc to use kuids
    userns: Teach security_path_chown to take kuids and kgids
    userns: Add user namespace support to IMA
    userns: Convert EVM to deal with kuids and kgids in it's hmac computation
    ...

    Linus Torvalds
     

21 Sep, 2012

2 commits


01 Sep, 2012

1 commit

  • Commit 4fdef2183e6598cc977a9bb9321ef99a44125da3 ("AppArmor: Cleanup make
    file to remove cruft and make it easier to read") removed all traces of
    af_names.h from the tree. Remove its entry in AppArmor's .gitignore file
    too.

    Signed-off-by: Paul Bolle
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

01 Jun, 2012

2 commits


22 May, 2012

1 commit


19 May, 2012

2 commits

  • BugLink: http://bugs.launchpad.net/bugs/955892

    All failures from __d_path where being treated as disconnected paths,
    however __d_path can also fail when the generated pathname is too long.

    The initial ENAMETOOLONG error was being lost, and ENAMETOOLONG was only
    returned if the subsequent dentry_path call resulted in that error. Other
    wise if the path was split across a mount point such that the dentry_path
    fit within the buffer when the __d_path did not the failure was treated
    as a disconnected path.

    Signed-off-by: John Johansen

    John Johansen
     
  • BugLink: http://bugs.launchpad.net/bugs/978038

    also affects apparmor portion of
    BugLink: http://bugs.launchpad.net/bugs/987371

    The unconfined profile is not stored in the regular profile list, but
    change_profile and exec transitions may want access to it when setting
    up specialized transitions like switch to the unconfined profile of a
    new policy namespace.

    Signed-off-by: John Johansen

    John Johansen
     

14 Apr, 2012

2 commits

  • Add support for AppArmor to explicitly fail requested domain transitions
    if NO_NEW_PRIVS is set and the task is not unconfined.

    Transitions from unconfined are still allowed because this always results
    in a reduction of privileges.

    Acked-by: Eric Paris
    Signed-off-by: Will Drewry
    Signed-off-by: John Johansen
    Signed-off-by: Andy Lutomirski

    v18: new acked-by, new description
    Signed-off-by: James Morris

    John Johansen
     
  • With this change, calling
    prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)
    disables privilege granting operations at execve-time. For example, a
    process will not be able to execute a setuid binary to change their uid
    or gid if this bit is set. The same is true for file capabilities.

    Additionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that
    LSMs respect the requested behavior.

    To determine if the NO_NEW_PRIVS bit is set, a task may call
    prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);
    It returns 1 if set and 0 if it is not set. If any of the arguments are
    non-zero, it will return -1 and set errno to -EINVAL.
    (PR_SET_NO_NEW_PRIVS behaves similarly.)

    This functionality is desired for the proposed seccomp filter patch
    series. By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the
    system call behavior for itself and its child tasks without being
    able to impact the behavior of a more privileged task.

    Another potential use is making certain privileged operations
    unprivileged. For example, chroot may be considered "safe" if it cannot
    affect privileged tasks.

    Note, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is
    set and AppArmor is in use. It is fixed in a subsequent patch.

    Signed-off-by: Andy Lutomirski
    Signed-off-by: Will Drewry
    Acked-by: Eric Paris
    Acked-by: Kees Cook

    v18: updated change desc
    v17: using new define values as per 3.4
    Signed-off-by: James Morris

    Andy Lutomirski
     

10 Apr, 2012

4 commits