Eric Lee / smarc-fsl-linux-kernel

30 Oct, 2009

1 commit

  • 5975c725d   define convenient securebits masks for prctl users (v2) ... Browse Code »

    Hi James, would you mind taking the following into
    security-testing?

    The securebits are used by passing them to prctl with the
    PR_{S,G}ET_SECUREBITS commands. But the defines must be
    shifted to be used in prctl, which begs to be confused and
    misused by userspace. So define some more convenient
    values for userspace to specify. This way userspace does

    prctl(PR_SET_SECUREBITS, SECBIT_NOROOT);

    instead of

    prctl(PR_SET_SECUREBITS, 1 << SECURE_NOROOT);

    (Thanks to Michael for the idea)

    This patch also adds include/linux/securebits to the installed headers.
    Then perhaps it can be included by glibc's sys/prctl.h.

    Changelog:
    Oct 29: Stephen Rothwell points out that issecure can
    be under __KERNEL__.
    Oct 14: (Suggestions by Michael Kerrisk):
    1. spell out SETUID in SECBIT_NO_SETUID*
    2. SECBIT_X_LOCKED does not imply SECBIT_X
    3. add definitions for keepcaps
    Oct 14: As suggested by Michael Kerrisk, don't
    use SB_* as that convention is already in
    use. Use SECBIT_ prefix instead.

    Signed-off-by: Serge E. Hallyn
    Acked-by: Andrew G. Morgan
    Acked-by: Michael Kerrisk
    Cc: Ulrich Drepper
    Cc: James Morris
    Signed-off-by: James Morris

    Serge E. Hallyn
     

14 Nov, 2008

2 commits

  • 86a264abe   CRED: Wrap current->cred and a few other accessors ... Browse Code »

    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
     
  • b6dff3ec5   CRED: Separate task security context from task_struct ... Browse Code »

    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
     

05 Jul, 2008

1 commit

  • 086f7316f   security: filesystem capabilities: fix fragile setuid fixup code ... Browse Code »

    This commit includes a bugfix for the fragile setuid fixup code in the
    case that filesystem capabilities are supported (in access()). The effect
    of this fix is gated on filesystem capability support because changing
    securebits is only supported when filesystem capabilities support is
    configured.)

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

    Andrew G. Morgan
     

28 Apr, 2008

1 commit

  • 3898b1b4e   capabilities: implement per-process securebits ... Browse Code »

    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
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds