[PATCH 0/4] Audit support for file capabilities - Kernel

This is a discussion on [PATCH 0/4] Audit support for file capabilities - Kernel ; The following series implements audit support for file capabilities. Audit emits relevant fcaps infor for all path records, any time fcaps actually escalate permissions, and we now print the arguments to sys_capset for when a process tries to modify cap ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: [PATCH 0/4] Audit support for file capabilities

  1. [PATCH 0/4] Audit support for file capabilities

    The following series implements audit support for file capabilities. Audit
    emits relevant fcaps infor for all path records, any time fcaps actually
    escalate permissions, and we now print the arguments to sys_capset for when a
    process tries to modify cap info.

    ---

    Eric Paris (4):
    AUDIT: emit new record type showing all capset information
    AUDIT: audit when fcaps increase the permitted or inheritable capabilities
    AUDIT: output permitted and inheritable fcaps in PATH records
    CAPABILITIES: add cpu endian vfs caps structure


    include/linux/audit.h | 22 +++++
    include/linux/capability.h | 12 +++
    kernel/auditsc.c | 201 +++++++++++++++++++++++++++++++++++++++++++-
    kernel/capability.c | 3 +
    security/commoncap.c | 131 ++++++++++++++++-------------
    5 files changed, 308 insertions(+), 61 deletions(-)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. [PATCH 2/4] AUDIT: output permitted and inheritable fcaps in PATH records

    This patch will print cap_permitted and cap_inheritable data in the PATH
    records of any file that has file capabilities set. Files which do not
    have fcaps set will not have different PATH records.

    An example audit record if you run:
    setcap "cap_net_admin+pie" /bin/bash
    /bin/bash

    type=SYSCALL msg=audit(1224539233.882:54): arch=c000003e syscall=59 success=yes exit=0 a0=207fc80 a1=2083cb0 a2=2083c70 a3=7fffb32dff60 items=2 ppid=2326 pid=2328 auid=0 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="bash" exe="/bin/bash" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
    type=EXECVE msg=audit(1224539233.882:54): argc=1 a0="-bash"
    type=CWD msg=audit(1224539233.882:54): cwd="/home/test"
    type=PATH msg=audit(1224539233.882:54): item=0 name="/bin/bash" inode=49161 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_ubject_r:shell_exec_t:s0 cap_fP=0000000000001000 cap_fI=0000000000001000 cap_fE=1 cap_fVer=2
    type=PATH msg=audit(1224539233.882:54): item=1 name=(null) inode=507963 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_ubject_r:ld_so_t:s0

    Signed-off-by: Eric Paris
    ---

    include/linux/capability.h | 5 +++
    kernel/auditsc.c | 82 +++++++++++++++++++++++++++++++++++++++++---
    2 files changed, 82 insertions(+), 5 deletions(-)

    diff --git a/include/linux/capability.h b/include/linux/capability.h
    index 9d64a9c..3f7920b 100644
    --- a/include/linux/capability.h
    +++ b/include/linux/capability.h
    @@ -53,6 +53,7 @@ typedef struct __user_cap_data_struct {
    #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

    #define VFS_CAP_REVISION_MASK 0xFF000000
    +#define VFS_CAP_REVISION_SHIFT 24
    #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
    #define VFS_CAP_FLAGS_EFFECTIVE 0x000001

    @@ -524,6 +525,10 @@ kernel_cap_t cap_set_effective(const kernel_cap_t pE_new);

    extern int capable(int cap);

    +/* audit system wants to get cap info from files as well */
    +struct dentry;
    +extern int get_vfs_caps_from_disk(const struct dentry *dentry, struct cpu_vfs_cap_data *cpu_caps);
    +
    #endif /* __KERNEL__ */

    #endif /* !_LINUX_CAPABILITY_H */
    diff --git a/kernel/auditsc.c b/kernel/auditsc.c
    index cf5bc2f..bf1f11a 100644
    --- a/kernel/auditsc.c
    +++ b/kernel/auditsc.c
    @@ -65,6 +65,7 @@
    #include
    #include
    #include
    +#include

    #include "audit.h"

    @@ -84,6 +85,15 @@ int audit_n_rules;
    /* determines whether we collect data for signals sent */
    int audit_signals;

    +struct audit_cap_data {
    + kernel_cap_t permitted;
    + kernel_cap_t inheritable;
    + union {
    + unsigned int fE;
    + kernel_cap_t effective;
    + };
    +};
    +
    /* When fs/namei.c:getname() is called, we store the pointer in name and
    * we don't let putname() free it (instead we free all of the saved
    * pointers at syscall exit time).
    @@ -100,6 +110,8 @@ struct audit_names {
    gid_t gid;
    dev_t rdev;
    u32 osid;
    + struct audit_cap_data fcap;
    + unsigned int fcap_ver;
    };

    struct audit_aux_data {
    @@ -1171,6 +1183,35 @@ static void audit_log_execve_info(struct audit_context *context,
    kfree(buf);
    }

    +static void audit_log_cap(struct audit_buffer *ab, char *prefix, kernel_cap_t *cap)
    +{
    + int i;
    +
    + audit_log_format(ab, " %s=", prefix);
    + CAP_FOR_EACH_U32(i) {
    + audit_log_format(ab, "%08x", cap->cap[(_KERNEL_CAPABILITY_U32S-1) - i]);
    + }
    +}
    +
    +static void audit_log_fcaps(struct audit_buffer *ab, struct audit_names *name)
    +{
    + kernel_cap_t *perm = &name->fcap.permitted;
    + kernel_cap_t *inh = &name->fcap.inheritable;
    + int log = 0;
    +
    + if (!cap_isclear(*perm)) {
    + audit_log_cap(ab, "cap_fP", perm);
    + log = 1;
    + }
    + if (!cap_isclear(*inh)) {
    + audit_log_cap(ab, "cap_fI", inh);
    + log = 1;
    + }
    +
    + if (log)
    + audit_log_format(ab, " cap_fE=%d cap_fVer=%x", name->fcap.fE, name->fcap_ver);
    +}
    +
    static void audit_log_exit(struct audit_context *context, struct task_struct *tsk)
    {
    int i, call_panic = 0;
    @@ -1421,6 +1462,8 @@ static void audit_log_exit(struct audit_context *context, struct task_struct *ts
    }
    }

    + audit_log_fcaps(ab, n);
    +
    audit_log_end(ab);
    }

    @@ -1787,8 +1830,36 @@ static int audit_inc_name_count(struct audit_context *context,
    return 0;
    }

    +
    +static inline int audit_copy_fcaps(struct audit_names *name, const struct dentry *dentry)
    +{
    + struct cpu_vfs_cap_data caps;
    + int rc;
    +
    + memset(&name->fcap.permitted, 0, sizeof(kernel_cap_t));
    + memset(&name->fcap.inheritable, 0, sizeof(kernel_cap_t));
    + name->fcap.fE = 0;
    + name->fcap_ver = 0;
    +
    + if (!dentry)
    + return 0;
    +
    + rc = get_vfs_caps_from_disk(dentry, &caps);
    + if (rc)
    + return rc;
    +
    + name->fcap.permitted = caps.permitted;
    + name->fcap.inheritable = caps.inheritable;
    + name->fcap.fE = !!(caps.magic_etc & VFS_CAP_FLAGS_EFFECTIVE);
    + name->fcap_ver = (caps.magic_etc & VFS_CAP_REVISION_MASK) >> VFS_CAP_REVISION_SHIFT;
    +
    + return 0;
    +}
    +
    +
    /* Copy inode data into an audit_names. */
    -static void audit_copy_inode(struct audit_names *name, const struct inode *inode)
    +static void audit_copy_inode(struct audit_names *name, const struct dentry *dentry,
    + const struct inode *inode)
    {
    name->ino = inode->i_ino;
    name->dev = inode->i_sb->s_dev;
    @@ -1797,6 +1868,7 @@ static void audit_copy_inode(struct audit_names *name, const struct inode *inode
    name->gid = inode->i_gid;
    name->rdev = inode->i_rdev;
    security_inode_getsecid(inode, &name->osid);
    + audit_copy_fcaps(name, dentry);
    }

    /**
    @@ -1831,7 +1903,7 @@ void __audit_inode(const char *name, const struct dentry *dentry)
    context->names[idx].name = NULL;
    }
    handle_path(dentry);
    - audit_copy_inode(&context->names[idx], inode);
    + audit_copy_inode(&context->names[idx], dentry, inode);
    }

    /**
    @@ -1892,7 +1964,7 @@ void __audit_inode_child(const char *dname, const struct dentry *dentry,
    if (!strcmp(dname, n->name) ||
    !audit_compare_dname_path(dname, n->name, &dirlen)) {
    if (inode)
    - audit_copy_inode(n, inode);
    + audit_copy_inode(n, NULL, inode);
    else
    n->ino = (unsigned long)-1;
    found_child = n->name;
    @@ -1906,7 +1978,7 @@ add_names:
    return;
    idx = context->name_count - 1;
    context->names[idx].name = NULL;
    - audit_copy_inode(&context->names[idx], parent);
    + audit_copy_inode(&context->names[idx], NULL, parent);
    }

    if (!found_child) {
    @@ -1927,7 +1999,7 @@ add_names:
    }

    if (inode)
    - audit_copy_inode(&context->names[idx], inode);
    + audit_copy_inode(&context->names[idx], NULL, inode);
    else
    context->names[idx].ino = (unsigned long)-1;
    }

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 1/4] CAPABILITIES: add cpu endian vfs caps structure

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Eric Paris wrote:
    > This patch add a generic cpu endian caps structure and enternally available
    > functions which retrieve fcaps information from disk. This information is
    > necessary so fcaps information can be collected and recorded by the audit
    > system.
    >

    [...]
    > CAP_FOR_EACH_U32(i) {
    > - __u32 value_cpu;
    > -
    > - if (i >= tocopy) {
    > - /*
    > - * Legacy capability sets have no upper bits
    > - */
    > - bprm->cap_post_exec_permitted.cap[i] = 0;
    > + if (i > tocopy) {


    Shouldn't the above still be (i >= tocopy) ?

    Cheers

    Andrew
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFI/W2e+bHCR3gb8jsRAtDBAJ94XoCVXRDDycns4KEmLLBlYODiqAC fUD7W
    wx996Hso7mGH9lcc8Eiq89k=
    =gx3P
    -----END PGP SIGNATURE-----
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Eric Paris wrote:
    > Any time fcaps are used to increase a processes pP or pE we will crate a new
    > audit record which contains the entire set of known information about the
    > executable in question, fP, fI, fE, version and includes the parent processes
    > pE, pI, pP. This record type will only be emitted from execve syscalls.


    I'm confused by the choice of when to log this event.

    File capabilities are required to give a process 'any' active
    capabilities. That is they don't affect pI -> pI', but without fI or fP,
    the post-execve() process is guaranteed to have no pP or pE capabilities.

    Logging execve()s where there is only an increase in capabilities seems
    wrong to me. To me it seems equally important to log any event where an
    execve() yields pP != 0.

    > diff --git a/security/commoncap.c b/security/commoncap.c
    > index 888b292..9bb285d 100644
    > --- a/security/commoncap.c
    > +++ b/security/commoncap.c
    > @@ -8,6 +8,7 @@
    > */
    >
    > #include
    > +#include
    > #include
    > #include
    > #include
    > @@ -320,6 +321,8 @@ static int get_file_caps(struct linux_binprm *bprm)
    >
    > rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    >
    > + audit_log_bprm_fcaps(bprm, &vcaps);
    > +


    When rc != 0, the execve() will fail. Is it appropriate to log in this case?

    Cheers

    Andrew
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFI/W5F+bHCR3gb8jsRAhM9AJ9oJL4PmdtMwHEkN0Xh0ZTHBlJPzgC fVT/8
    1Rq4wgGWftqpaVXBmeAsEi8=
    =W8R9
    -----END PGP SIGNATURE-----
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 1/4] CAPABILITIES: add cpu endian vfs caps structure

    On Mon, 2008-10-20 at 22:50 -0700, Andrew G. Morgan wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Eric Paris wrote:
    > > This patch add a generic cpu endian caps structure and enternally available
    > > functions which retrieve fcaps information from disk. This information is
    > > necessary so fcaps information can be collected and recorded by the audit
    > > system.
    > >

    > [...]
    > > CAP_FOR_EACH_U32(i) {
    > > - __u32 value_cpu;
    > > -
    > > - if (i >= tocopy) {
    > > - /*
    > > - * Legacy capability sets have no upper bits
    > > - */
    > > - bprm->cap_post_exec_permitted.cap[i] = 0;
    > > + if (i > tocopy) {

    >
    > Shouldn't the above still be (i >= tocopy) ?


    just replaced this with

    if (i >= tocopy)
    break;

    I'm already zero'ing out the cap data at the beginning so there isn't
    really a need for me to zero the upper bits if they aren't set.

    -Eric

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    Quoting Andrew G. Morgan (morgan@kernel.org):
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Eric Paris wrote:
    > > Any time fcaps are used to increase a processes pP or pE we will crate a new
    > > audit record which contains the entire set of known information about the
    > > executable in question, fP, fI, fE, version and includes the parent processes
    > > pE, pI, pP. This record type will only be emitted from execve syscalls.

    >
    > I'm confused by the choice of when to log this event.
    >
    > File capabilities are required to give a process 'any' active
    > capabilities. That is they don't affect pI -> pI', but without fI or fP,
    > the post-execve() process is guaranteed to have no pP or pE capabilities.
    >
    > Logging execve()s where there is only an increase in capabilities seems
    > wrong to me. To me it seems equally important to log any event where an
    > execve() yields pP != 0.


    True.

    .... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?

    And then it also might be interesting in the case where
    (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.

    > > diff --git a/security/commoncap.c b/security/commoncap.c
    > > index 888b292..9bb285d 100644
    > > --- a/security/commoncap.c
    > > +++ b/security/commoncap.c
    > > @@ -8,6 +8,7 @@
    > > */
    > >
    > > #include
    > > +#include
    > > #include
    > > #include
    > > #include
    > > @@ -320,6 +321,8 @@ static int get_file_caps(struct linux_binprm *bprm)
    > >
    > > rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    > >
    > > + audit_log_bprm_fcaps(bprm, &vcaps);
    > > +

    >
    > When rc != 0, the execve() will fail. Is it appropriate to log in this case?


    It might fail because fP contains bits not in pP', right? That's
    probably interesting to auditors.

    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    [s/viro@...ok/viro@...uk/]

    Serge E. Hallyn wrote:
    >> Logging execve()s where there is only an increase in capabilities seems
    >> wrong to me. To me it seems equally important to log any event where an
    >> execve() yields pP != 0.

    >
    > True.
    >
    > ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
    >
    > And then it also might be interesting in the case where
    > (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.


    I guess so, although this seems like a case of being interested in a
    (unusual) non-privileged execve().

    >>> rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    >>>
    >>> + audit_log_bprm_fcaps(bprm, &vcaps);
    >>> +

    >> When rc != 0, the execve() will fail. Is it appropriate to log in this case?

    >
    > It might fail because fP contains bits not in pP', right? That's
    > probably interesting to auditors.


    In which case, how is the fact it didn't execute captured in the audit log?

    Cheers

    Andrew
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFI/yG9+bHCR3gb8jsRAii1AKCDluqUSVyAKP67/9bhEgqdlx3xdACg0dn4
    81bi/3eMaP1FqfdVK2u/BpM=
    =QBli
    -----END PGP SIGNATURE-----
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    Quoting Andrew G. Morgan (morgan@kernel.org):
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > [s/viro@...ok/viro@...uk/]
    >
    > Serge E. Hallyn wrote:
    > >> Logging execve()s where there is only an increase in capabilities seems
    > >> wrong to me. To me it seems equally important to log any event where an
    > >> execve() yields pP != 0.

    > >
    > > True.
    > >
    > > ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
    > >
    > > And then it also might be interesting in the case where
    > > (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.

    >
    > I guess so, although this seems like a case of being interested in a
    > (unusual) non-privileged execve().


    I'm not sure what you mean - but this can only happen if bits are taken
    out of the capability bounding set, right?

    > >>> rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    > >>>
    > >>> + audit_log_bprm_fcaps(bprm, &vcaps);
    > >>> +
    > >> When rc != 0, the execve() will fail. Is it appropriate to log in this case?

    > >
    > > It might fail because fP contains bits not in pP', right? That's
    > > probably interesting to auditors.

    >
    > In which case, how is the fact it didn't execute captured in the audit log?


    I assume as a FAIL? (Not sure of the exact wording in the logs)

    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Serge E. Hallyn wrote:
    >>> ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
    >>>
    >>> And then it also might be interesting in the case where
    >>> (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.

    >> I guess so, although this seems like a case of being interested in a
    >> (unusual) non-privileged execve().

    >
    > I'm not sure what you mean - but this can only happen if bits are taken
    > out of the capability bounding set, right?


    Yes, it can happen as you say.

    This is a case of an unprivileged uid==0 execution. Since we don't
    appear to want to audit other non-privileged execve()s, its not clear to
    me that this one deserves attention.

    >>>>> rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    >>>>>
    >>>>> + audit_log_bprm_fcaps(bprm, &vcaps);
    >>>>> +
    >>>> When rc != 0, the execve() will fail. Is it appropriate to log in this case?
    >>> It might fail because fP contains bits not in pP', right? That's
    >>> probably interesting to auditors.

    >> In which case, how is the fact it didn't execute captured in the audit log?

    >
    > I assume as a FAIL? (Not sure of the exact wording in the logs)


    OK. As long as its clearly identified as a failure and the logs are not
    misleading - making it look like the execve() succeeded with privilege -
    then I'm not as concerned.

    Cheers

    Andrew
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (Darwin)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFI//oF+bHCR3gb8jsRAjZxAKCoSXL7CwTfQJt7Wn55nT8MwHbiEgCc D+Qm
    VVHHZ9QiInaVb2faUt9Q77E=
    =gJU0
    -----END PGP SIGNATURE-----
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    On Wed, 2008-10-22 at 21:13 -0700, Andrew G. Morgan wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Serge E. Hallyn wrote:
    > >>> ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
    > >>>
    > >>> And then it also might be interesting in the case where
    > >>> (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
    > >> I guess so, although this seems like a case of being interested in a
    > >> (unusual) non-privileged execve().

    > >
    > > I'm not sure what you mean - but this can only happen if bits are taken
    > > out of the capability bounding set, right?

    >
    > Yes, it can happen as you say.
    >
    > This is a case of an unprivileged uid==0 execution. Since we don't
    > appear to want to audit other non-privileged execve()s, its not clear to
    > me that this one deserves attention.


    So what did you two agree on for when to collect fcaps type information?
    Any time bprm->cap_post_exec_permitted is non-zero?

    > >>>>> rc = bprm_caps_from_vfs_caps(&vcaps, bprm);
    > >>>>>
    > >>>>> + audit_log_bprm_fcaps(bprm, &vcaps);
    > >>>>> +
    > >>>> When rc != 0, the execve() will fail. Is it appropriate to log in this case?
    > >>> It might fail because fP contains bits not in pP', right? That's
    > >>> probably interesting to auditors.
    > >> In which case, how is the fact it didn't execute captured in the audit log?

    > >
    > > I assume as a FAIL? (Not sure of the exact wording in the logs)

    >
    > OK. As long as its clearly identified as a failure and the logs are not
    > misleading - making it look like the execve() succeeded with privilege -
    > then I'm not as concerned.


    The syscall record (rather than this auxilary fcaps record) will
    indicate that the syscall failed. it says something like success=no.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 3/4] AUDIT: audit when fcaps increase the permitted or inheritable capabilities

    Quoting Eric Paris (eparis@redhat.com):
    > On Wed, 2008-10-22 at 21:13 -0700, Andrew G. Morgan wrote:
    > > -----BEGIN PGP SIGNED MESSAGE-----
    > > Hash: SHA1
    > >
    > > Serge E. Hallyn wrote:
    > > >>> ... except if (!issecure(SECURE_NOROOT) && uid==0) I guess?
    > > >>>
    > > >>> And then it also might be interesting in the case where
    > > >>> (!issecure(SECURE_NOROOT) && uid==0) and pP is not full.
    > > >> I guess so, although this seems like a case of being interested in a
    > > >> (unusual) non-privileged execve().
    > > >
    > > > I'm not sure what you mean - but this can only happen if bits are taken
    > > > out of the capability bounding set, right?

    > >
    > > Yes, it can happen as you say.
    > >
    > > This is a case of an unprivileged uid==0 execution. Since we don't
    > > appear to want to audit other non-privileged execve()s, its not clear to
    > > me that this one deserves attention.

    >
    > So what did you two agree on for when to collect fcaps type information?
    > Any time bprm->cap_post_exec_permitted is non-zero?


    And (bprm->e_uid!=0 && current->uid!=0 && !issecure(SECURE_NOROOT)) -
    otherwise you'll get a hit for every file executed by root. If you're
    ok with that noise, then it's fine with me. (I assume it can be
    filtered out using an audit rule by userspace anyway?)

    The inverse case that I suggested is interesting because root was
    prevented from running with full capabilities - which could be
    indicative of a sendmail-capabilities-bug style of attack.

    -serge
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread