20 Nov, 2014

1 commit


24 Jul, 2014

2 commits

  • This is effectively a revert of 7b9a7ec565505699f503b4fcf61500dceb36e744
    plus fixing it a different way...

    We found, when trying to run an application from an application which
    had dropped privs that the kernel does security checks on undefined
    capability bits. This was ESPECIALLY difficult to debug as those
    undefined bits are hidden from /proc/$PID/status.

    Consider a root application which drops all capabilities from ALL 4
    capability sets. We assume, since the application is going to set
    eff/perm/inh from an array that it will clear not only the defined caps
    less than CAP_LAST_CAP, but also the higher 28ish bits which are
    undefined future capabilities.

    The BSET gets cleared differently. Instead it is cleared one bit at a
    time. The problem here is that in security/commoncap.c::cap_task_prctl()
    we actually check the validity of a capability being read. So any task
    which attempts to 'read all things set in bset' followed by 'unset all
    things set in bset' will not even attempt to unset the undefined bits
    higher than CAP_LAST_CAP.

    So the 'parent' will look something like:
    CapInh: 0000000000000000
    CapPrm: 0000000000000000
    CapEff: 0000000000000000
    CapBnd: ffffffc000000000

    All of this 'should' be fine. Given that these are undefined bits that
    aren't supposed to have anything to do with permissions. But they do...

    So lets now consider a task which cleared the eff/perm/inh completely
    and cleared all of the valid caps in the bset (but not the invalid caps
    it couldn't read out of the kernel). We know that this is exactly what
    the libcap-ng library does and what the go capabilities library does.
    They both leave you in that above situation if you try to clear all of
    you capapabilities from all 4 sets. If that root task calls execve()
    the child task will pick up all caps not blocked by the bset. The bset
    however does not block bits higher than CAP_LAST_CAP. So now the child
    task has bits in eff which are not in the parent. These are
    'meaningless' undefined bits, but still bits which the parent doesn't
    have.

    The problem is now in cred_cap_issubset() (or any operation which does a
    subset test) as the child, while a subset for valid cap bits, is not a
    subset for invalid cap bits! So now we set durring commit creds that
    the child is not dumpable. Given it is 'more priv' than its parent. It
    also means the parent cannot ptrace the child and other stupidity.

    The solution here:
    1) stop hiding capability bits in status
    This makes debugging easier!

    2) stop giving any task undefined capability bits. it's simple, it you
    don't put those invalid bits in CAP_FULL_SET you won't get them in init
    and you won't get them in any other task either.
    This fixes the cap_issubset() tests and resulting fallout (which
    made the init task in a docker container untraceable among other
    things)

    3) mask out undefined bits when sys_capset() is called as it might use
    ~0, ~0 to denote 'all capabilities' for backward/forward compatibility.
    This lets 'capsh --caps="all=eip" -- -c /bin/bash' run.

    4) mask out undefined bit when we read a file capability off of disk as
    again likely all bits are set in the xattr for forward/backward
    compatibility.
    This lets 'setcap all+pe /bin/bash; /bin/bash' run

    Signed-off-by: Eric Paris
    Reviewed-by: Kees Cook
    Cc: Andrew Vagin
    Cc: Andrew G. Morgan
    Cc: Serge E. Hallyn
    Cc: Kees Cook
    Cc: Steve Grubb
    Cc: Dan Walsh
    Cc: stable@vger.kernel.org
    Signed-off-by: James Morris

    Eric Paris
     
  • In function cap_task_prctl(), we would allocate a credential
    unconditionally and then check if we support the requested function.
    If not we would release this credential with abort_creds() by using
    RCU method. But on some archs such as powerpc, the sys_prctl is heavily
    used to get/set the floating point exception mode. So the unnecessary
    allocating/releasing of credential not only introduce runtime overhead
    but also do cause OOM due to the RCU implementation.

    This patch removes abort_creds() from cap_task_prctl() by calling
    prepare_creds() only when we need to modify it.

    Reported-by: Kevin Hao
    Signed-off-by: Tetsuo Handa
    Reviewed-by: Paul Moore
    Acked-by: Serge E. Hallyn
    Reviewed-by: Kees Cook
    Signed-off-by: James Morris

    Tetsuo Handa
     

31 Aug, 2013

2 commits

  • We allow task A to change B's nice level if it has a supserset of
    B's privileges, or of it has CAP_SYS_NICE. Also allow it if A has
    CAP_SYS_NICE with respect to B - meaning it is root in the same
    namespace, or it created B's namespace.

    Signed-off-by: Serge Hallyn
    Reviewed-by: "Eric W. Biederman"
    Signed-off-by: Eric W. Biederman

    Serge Hallyn
     
  • As the capabilites and capability bounding set are per user namespace
    properties it is safe to allow changing them with just CAP_SETPCAP
    permission in the user namespace.

    Acked-by: Serge Hallyn
    Tested-by: Richard Weinberger
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

26 Feb, 2013

1 commit


15 Dec, 2012

1 commit

  • Andy Lutomirski pointed out that the current behavior of allowing the
    owner of a user namespace to have all caps when that owner is not in a
    parent user namespace is wrong. Add a test to ensure the owner of a user
    namespace is in the parent of the user namespace to fix this bug.

    Thankfully this bug did not apply to the initial user namespace, keeping
    the mischief that can be caused by this bug quite small.

    This is bug was introduced in v3.5 by commit 783291e6900
    "Simplify the user_namespace by making userns->creator a kuid."
    But did not matter until the permisions required to create
    a user namespace were relaxed allowing a user namespace to be created
    inside of a user namespace.

    The bug made it possible for the owner of a user namespace to be
    present in a child user namespace. Since the owner of a user nameapce
    is granted all capabilities it became possible for users in a
    grandchild user namespace to have all privilges over their parent user
    namspace.

    Reorder the checks in cap_capable. This should make the common case
    faster and make it clear that nothing magic happens in the initial
    user namespace. The reordering is safe because cred->user_ns
    can only be in targ_ns or targ_ns->parent but not both.

    Add a comment a the top of the loop to make the logic of
    the code clear.

    Add a distinct variable ns that changes as we walk up
    the user namespace hierarchy to make it clear which variable
    is changing.

    Acked-by: Serge Hallyn
    Signed-off-by: "Eric W. Biederman"

    Eric W. Biederman
     

01 Jun, 2012

2 commits


24 May, 2012

1 commit

  • Pull user namespace enhancements from Eric Biederman:
    "This is a course correction for the user namespace, so that we can
    reach an inexpensive, maintainable, and reasonably complete
    implementation.

    Highlights:
    - Config guards make it impossible to enable the user namespace and
    code that has not been converted to be user namespace safe.

    - Use of the new kuid_t type ensures the if you somehow get past the
    config guards the kernel will encounter type errors if you enable
    user namespaces and attempt to compile in code whose permission
    checks have not been updated to be user namespace safe.

    - All uids from child user namespaces are mapped into the initial
    user namespace before they are processed. Removing the need to add
    an additional check to see if the user namespace of the compared
    uids remains the same.

    - With the user namespaces compiled out the performance is as good or
    better than it is today.

    - For most operations absolutely nothing changes performance or
    operationally with the user namespace enabled.

    - The worst case performance I could come up with was timing 1
    billion cache cold stat operations with the user namespace code
    enabled. This went from 156s to 164s on my laptop (or 156ns to
    164ns per stat operation).

    - (uid_t)-1 and (gid_t)-1 are reserved as an internal error value.
    Most uid/gid setting system calls treat these value specially
    anyway so attempting to use -1 as a uid would likely cause
    entertaining failures in userspace.

    - If setuid is called with a uid that can not be mapped setuid fails.
    I have looked at sendmail, login, ssh and every other program I
    could think of that would call setuid and they all check for and
    handle the case where setuid fails.

    - If stat or a similar system call is called from a context in which
    we can not map a uid we lie and return overflowuid. The LFS
    experience suggests not lying and returning an error code might be
    better, but the historical precedent with uids is different and I
    can not think of anything that would break by lying about a uid we
    can't map.

    - Capabilities are localized to the current user namespace making it
    safe to give the initial user in a user namespace all capabilities.

    My git tree covers all of the modifications needed to convert the core
    kernel and enough changes to make a system bootable to runlevel 1."

    Fix up trivial conflicts due to nearby independent changes in fs/stat.c

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (46 commits)
    userns: Silence silly gcc warning.
    cred: use correct cred accessor with regards to rcu read lock
    userns: Convert the move_pages, and migrate_pages permission checks to use uid_eq
    userns: Convert cgroup permission checks to use uid_eq
    userns: Convert tmpfs to use kuid and kgid where appropriate
    userns: Convert sysfs to use kgid/kuid where appropriate
    userns: Convert sysctl permission checks to use kuid and kgids.
    userns: Convert proc to use kuid/kgid where appropriate
    userns: Convert ext4 to user kuid/kgid where appropriate
    userns: Convert ext3 to use kuid/kgid where appropriate
    userns: Convert ext2 to use kuid/kgid where appropriate.
    userns: Convert devpts to use kuid/kgid where appropriate
    userns: Convert binary formats to use kuid/kgid where appropriate
    userns: Add negative depends on entries to avoid building code that is userns unsafe
    userns: signal remove unnecessary map_cred_ns
    userns: Teach inode_capable to understand inodes whose uids map to other namespaces.
    userns: Fail exec for suid and sgid binaries with ids outside our user namespace.
    userns: Convert stat to return values mapped from kuids and kgids
    userns: Convert user specfied uids and gids in chown into kuids and kgid
    userns: Use uid_eq gid_eq helpers when comparing kuids and kgids in the vfs
    ...

    Linus Torvalds
     

04 May, 2012

1 commit


03 May, 2012

2 commits


26 Apr, 2012

1 commit

  • - Transform userns->creator from a user_struct reference to a simple
    kuid_t, kgid_t pair.

    In cap_capable this allows the check to see if we are the creator of
    a namespace to become the classic suser style euid permission check.

    This allows us to remove the need for a struct cred in the mapping
    functions and still be able to dispaly the user namespace creators
    uid and gid as 0.

    - Remove the now unnecessary delayed_work in free_user_ns.

    All that is left for free_user_ns to do is to call kmem_cache_free
    and put_user_ns. Those functions can be called in any context
    so call them directly from free_user_ns removing the need for delayed work.

    Acked-by: Serge Hallyn
    Signed-off-by: Eric W. Biederman

    Eric W. Biederman
     

19 Apr, 2012

1 commit

  • Add missing "personality.h"
    security/commoncap.c: In function 'cap_bprm_set_creds':
    security/commoncap.c:510: error: 'PER_CLEAR_ON_SETID' undeclared (first use in this function)
    security/commoncap.c:510: error: (Each undeclared identifier is reported only once
    security/commoncap.c:510: error: for each function it appears in.)

    Signed-off-by: Jonghwan Choi
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Jonghwan Choi
     

18 Apr, 2012

1 commit

  • If a process increases permissions using fcaps all of the dangerous
    personality flags which are cleared for suid apps should also be cleared.
    Thus programs given priviledge with fcaps will continue to have address space
    randomization enabled even if the parent tried to disable it to make it
    easier to attack.

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

    Eric Paris
     

14 Apr, 2012

1 commit

  • 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
     

08 Apr, 2012

2 commits


14 Feb, 2012

1 commit


15 Jan, 2012

1 commit

  • * 'for-linus' of git://selinuxproject.org/~jmorris/linux-security:
    capabilities: remove __cap_full_set definition
    security: remove the security_netlink_recv hook as it is equivalent to capable()
    ptrace: do not audit capability check when outputing /proc/pid/stat
    capabilities: remove task_ns_* functions
    capabitlies: ns_capable can use the cap helpers rather than lsm call
    capabilities: style only - move capable below ns_capable
    capabilites: introduce new has_ns_capabilities_noaudit
    capabilities: call has_ns_capability from has_capability
    capabilities: remove all _real_ interfaces
    capabilities: introduce security_capable_noaudit
    capabilities: reverse arguments to security_capable
    capabilities: remove the task from capable LSM hook entirely
    selinux: sparse fix: fix several warnings in the security server cod
    selinux: sparse fix: fix warnings in netlink code
    selinux: sparse fix: eliminate warnings for selinuxfs
    selinux: sparse fix: declare selinux_disable() in security.h
    selinux: sparse fix: move selinux_complete_init
    selinux: sparse fix: make selinux_secmark_refcount static
    SELinux: Fix RCU deref check warning in sel_netport_insert()

    Manually fix up a semantic mis-merge wrt security_netlink_recv():

    - the interface was removed in commit fd7784615248 ("security: remove
    the security_netlink_recv hook as it is equivalent to capable()")

    - a new user of it appeared in commit a38f7907b926 ("crypto: Add
    userspace configuration API")

    causing no automatic merge conflict, but Eric Paris pointed out the
    issue.

    Linus Torvalds
     

06 Jan, 2012

2 commits

  • Once upon a time netlink was not sync and we had to get the effective
    capabilities from the skb that was being received. Today we instead get
    the capabilities from the current task. This has rendered the entire
    purpose of the hook moot as it is now functionally equivalent to the
    capable() call.

    Signed-off-by: Eric Paris

    Eric Paris
     
  • The capabilities framework is based around credentials, not necessarily the
    current task. Yet we still passed the current task down into LSMs from the
    security_capable() LSM hook as if it was a meaningful portion of the security
    decision. This patch removes the 'generic' passing of current and instead
    forces individual LSMs to use current explicitly if they think it is
    appropriate. In our case those LSMs are SELinux and AppArmor.

    I believe the AppArmor use of current is incorrect, but that is wholely
    unrelated to this patch. This patch does not change what AppArmor does, it
    just makes it clear in the AppArmor code that it is doing it.

    The SELinux code still uses current in it's audit message, which may also be
    wrong and needs further investigation. Again this is NOT a change, it may
    have always been wrong, this patch just makes it clear what is happening.

    Signed-off-by: Eric Paris

    Eric Paris
     

16 Aug, 2011

1 commit


12 Aug, 2011

1 commit

  • A task (when !SECURE_NOROOT) which executes a setuid-root binary will
    obtain root privileges while executing that binary. If the binary also
    has effective capabilities set, then only those capabilities will be
    granted. The rationale is that the same binary can carry both setuid-root
    and the minimal file capability set, so that on a filesystem not
    supporting file caps the binary can still be executed with privilege,
    while on a filesystem supporting file caps it will run with minimal
    privilege.

    This special case currently does NOT happen if there are file capabilities
    but no effective capabilities. Since capability-aware programs can very
    well start with empty pE but populated pP and move those caps to pE when
    needed. In other words, if the file has file capabilities but NOT
    effective capabilities, then we should do the same thing as if there
    were file capabilities, and not grant full root privileges.

    This patchset does that.

    (Changelog by Serge Hallyn).

    Signed-off-by: Zhi Li
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Zhi Li
     

04 Apr, 2011

1 commit

  • When the global init task is exec'd we have special case logic to make sure
    the pE is not reduced. There is no reason for this. If init wants to drop
    it's pE is should be allowed to do so. Remove this special logic.

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

    Eric Paris
     

24 Mar, 2011

2 commits

  • ptrace is allowed to tasks in the same user namespace according to the
    usual rules (i.e. the same rules as for two tasks in the init user
    namespace). ptrace is also allowed to a user namespace to which the
    current task the has CAP_SYS_PTRACE capability.

    Changelog:
    Dec 31: Address feedback by Eric:
    . Correct ptrace uid check
    . Rename may_ptrace_ns to ptrace_capable
    . Also fix the cap_ptrace checks.
    Jan 1: Use const cred struct
    Jan 11: use task_ns_capable() in place of ptrace_capable().
    Feb 23: same_or_ancestore_user_ns() was not an appropriate
    check to constrain cap_issubset. Rather, cap_issubset()
    only is meaningful when both capsets are in the same
    user_ns.

    Signed-off-by: Serge E. Hallyn
    Cc: "Eric W. Biederman"
    Acked-by: Daniel Lezcano
    Acked-by: David Howells
    Cc: James Morris
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     
  • - Introduce ns_capable to test for a capability in a non-default
    user namespace.
    - Teach cap_capable to handle capabilities in a non-default
    user namespace.

    The motivation is to get to the unprivileged creation of new
    namespaces. It looks like this gets us 90% of the way there, with
    only potential uid confusion issues left.

    I still need to handle getting all caps after creation but otherwise I
    think I have a good starter patch that achieves all of your goals.

    Changelog:
    11/05/2010: [serge] add apparmor
    12/14/2010: [serge] fix capabilities to created user namespaces
    Without this, if user serge creates a user_ns, he won't have
    capabilities to the user_ns he created. THis is because we
    were first checking whether his effective caps had the caps
    he needed and returning -EPERM if not, and THEN checking whether
    he was the creator. Reverse those checks.
    12/16/2010: [serge] security_real_capable needs ns argument in !security case
    01/11/2011: [serge] add task_ns_capable helper
    01/11/2011: [serge] add nsown_capable() helper per Bastian Blank suggestion
    02/16/2011: [serge] fix a logic bug: the root user is always creator of
    init_user_ns, but should not always have capabilities to
    it! Fix the check in cap_capable().
    02/21/2011: Add the required user_ns parameter to security_capable,
    fixing a compile failure.
    02/23/2011: Convert some macros to functions as per akpm comments. Some
    couldn't be converted because we can't easily forward-declare
    them (they are inline if !SECURITY, extern if SECURITY). Add
    a current_user_ns function so we can use it in capability.h
    without #including cred.h. Move all forward declarations
    together to the top of the #ifdef __KERNEL__ section, and use
    kernel-doc format.
    02/23/2011: Per dhowells, clean up comment in cap_capable().
    02/23/2011: Per akpm, remove unreachable 'return -EPERM' in cap_capable.

    (Original written and signed off by Eric; latest, modified version
    acked by him)

    [akpm@linux-foundation.org: fix build]
    [akpm@linux-foundation.org: export current_user_ns() for ecryptfs]
    [serge.hallyn@canonical.com: remove unneeded extra argument in selinux's task_has_capability]
    Signed-off-by: Eric W. Biederman
    Signed-off-by: Serge E. Hallyn
    Acked-by: "Eric W. Biederman"
    Acked-by: Daniel Lezcano
    Acked-by: David Howells
    Cc: James Morris
    Signed-off-by: Serge E. Hallyn
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Serge E. Hallyn
     

17 Mar, 2011

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1480 commits)
    bonding: enable netpoll without checking link status
    xfrm: Refcount destination entry on xfrm_lookup
    net: introduce rx_handler results and logic around that
    bonding: get rid of IFF_SLAVE_INACTIVE netdev->priv_flag
    bonding: wrap slave state work
    net: get rid of multiple bond-related netdevice->priv_flags
    bonding: register slave pointer for rx_handler
    be2net: Bump up the version number
    be2net: Copyright notice change. Update to Emulex instead of ServerEngines
    e1000e: fix kconfig for crc32 dependency
    netfilter ebtables: fix xt_AUDIT to work with ebtables
    xen network backend driver
    bonding: Improve syslog message at device creation time
    bonding: Call netif_carrier_off after register_netdevice
    bonding: Incorrect TX queue offset
    net_sched: fix ip_tos2prio
    xfrm: fix __xfrm_route_forward()
    be2net: Fix UDP packet detected status in RX compl
    Phonet: fix aligned-mode pipe socket buffer header reserve
    netxen: support for GbE port settings
    ...

    Fix up conflicts in drivers/staging/brcm80211/brcmsmac/wl_mac80211.c
    with the staging updates.

    Linus Torvalds
     

04 Mar, 2011

1 commit

  • Netlink message processing in the kernel is synchronous these days,
    capabilities can be checked directly in security_netlink_recv() from
    the current process.

    Signed-off-by: Patrick McHardy
    Reviewed-by: James Morris
    [chrisw: update to include pohmelfs and uvesafb]
    Signed-off-by: Chris Wright
    Signed-off-by: David S. Miller

    Patrick McHardy
     

02 Feb, 2011

1 commit

  • Both settimeofday() and clock_settime() promise with a 'const'
    attribute not to alter the arguments passed in. This patch adds the
    missing 'const' attribute into the various kernel functions
    implementing these calls.

    Signed-off-by: Richard Cochran
    Acked-by: John Stultz
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Richard Cochran
     

16 Nov, 2010

1 commit

  • The addition of CONFIG_SECURITY_DMESG_RESTRICT resulted in a build
    failure when CONFIG_PRINTK=n. This is because the capabilities code
    which used the new option was built even though the variable in question
    didn't exist.

    The patch here fixes this by moving the capabilities checks out of the
    LSM and into the caller. All (known) LSMs should have been calling the
    capabilities hook already so it actually makes the code organization
    better to eliminate the hook altogether.

    Signed-off-by: Eric Paris
    Acked-by: James Morris
    Signed-off-by: Linus Torvalds

    Eric Paris
     

12 Nov, 2010

1 commit

  • The kernel syslog contains debugging information that is often useful
    during exploitation of other vulnerabilities, such as kernel heap
    addresses. Rather than futilely attempt to sanitize hundreds (or
    thousands) of printk statements and simultaneously cripple useful
    debugging functionality, it is far simpler to create an option that
    prevents unprivileged users from reading the syslog.

    This patch, loosely based on grsecurity's GRKERNSEC_DMESG, creates the
    dmesg_restrict sysctl. When set to "0", the default, no restrictions are
    enforced. When set to "1", only users with CAP_SYS_ADMIN can read the
    kernel syslog via dmesg(8) or other mechanisms.

    [akpm@linux-foundation.org: explain the config option in kernel.txt]
    Signed-off-by: Dan Rosenberg
    Acked-by: Ingo Molnar
    Acked-by: Eugene Teo
    Acked-by: Kees Cook
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dan Rosenberg
     

21 Oct, 2010

1 commit

  • All security modules shouldn't change sched_param parameter of
    security_task_setscheduler(). This is not only meaningless, but also
    make a harmful result if caller pass a static variable.

    This patch remove policy and sched_param parameter from
    security_task_setscheduler() becuase none of security module is
    using it.

    Cc: James Morris
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: James Morris

    KOSAKI Motohiro
     

18 Aug, 2010

1 commit

  • Make do_execve() take a const filename pointer so that kernel_execve() compiles
    correctly on ARM:

    arch/arm/kernel/sys_arm.c:88: warning: passing argument 1 of 'do_execve' discards qualifiers from pointer target type

    This also requires the argv and envp arguments to be consted twice, once for
    the pointer array and once for the strings the array points to. This is
    because do_execve() passes a pointer to the filename (now const) to
    copy_strings_kernel(). A simpler alternative would be to cast the filename
    pointer in do_execve() when it's passed to copy_strings_kernel().

    do_execve() may not change any of the strings it is passed as part of the argv
    or envp lists as they are some of them in .rodata, so marking these strings as
    const should be fine.

    Further kernel_execve() and sys_execve() need to be changed to match.

    This has been test built on x86_64, frv, arm and mips.

    Signed-off-by: David Howells
    Tested-by: Ralf Baechle
    Acked-by: Russell King
    Signed-off-by: Linus Torvalds

    David Howells
     

23 Apr, 2010

1 commit


20 Apr, 2010

1 commit


05 Feb, 2010

1 commit


04 Feb, 2010

2 commits

  • Right now the syslog "type" action are just raw numbers which makes
    the source difficult to follow. This patch replaces the raw numbers
    with defined constants for some level of sanity.

    Signed-off-by: Kees Cook
    Acked-by: John Johansen
    Acked-by: Serge Hallyn
    Signed-off-by: James Morris

    Kees Cook
     
  • This allows the LSM to distinguish between syslog functions originating
    from /proc/kmsg access and direct syscalls. By default, the commoncaps
    will now no longer require CAP_SYS_ADMIN to read an opened /proc/kmsg
    file descriptor. For example the kernel syslog reader can now drop
    privileges after opening /proc/kmsg, instead of staying privileged with
    CAP_SYS_ADMIN. MAC systems that implement security_syslog have unchanged
    behavior.

    Signed-off-by: Kees Cook
    Acked-by: Serge Hallyn
    Acked-by: John Johansen
    Signed-off-by: James Morris

    Kees Cook