cap_brpm_set_creds() question

[John Johansen]

On 06/22/2010 04:25 AM, Seth Arnold wrote:
> I'm trying to track down the cause of
> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/581525
> (is there a common convention for referring to launchpad bug numbers?
> lp:581525 or something?)

you can use the canonical form which is used in kernel checkins
http://launchpad.net/bugs/#####

or
lp:###### will work just fine

> 
> While following my most recent stack trace, I ran into some code that I don't
> understand:
> 
> cap_bprm_set_creds():
> 
>         /* Don't let someone trace a set[ug]id/setpcap binary with the revised
>          * credentials unless they have the appropriate permit
>          */
>         if ((new->euid != old->uid ||
>              new->egid != old->gid ||
>              !cap_issubset(new->cap_permitted, old->cap_permitted)) &&
>             bprm->unsafe & ~LSM_UNSAFE_PTRACE_CAP) {
>                 /* downgrade; they get no more than they had, and maybe less */
>                 if (!capable(CAP_SETUID)) {
>                         new->euid = new->uid;
>                         new->egid = new->gid;
>                 }
>                 new->cap_permitted = cap_intersect(new->cap_permitted,
>                                                    old->cap_permitted);
>         }
> 
> First, there's a CAP_SETGID in addition to CAP_SETUID, should it be checked
> for the new->egid = new->gid?  Second, there's no clearing of supplementary
> groups. Were they forgotten? Or can they safely be skipped, because there's no
> way for setgid bits on an executable to grant new supplementary groups?
> 
sorry to say I am not sure on either of these but the missing CAP_SETGID does
look suspicious.

> Later:
> 
>         /*
>          * Audit candidate if current->cap_effective is set
>          *
>          * We do not bother to audit if 3 things are true:
>          *   1) cap_effective has all caps
>          *   2) we are root
>          *   3) root is supposed to have all caps (SECURE_NOROOT)
>          * Since this is just a normal root execing a process.
>          *
>          * Number 1 above might fail if you don't have a full bset, but I think
>          * that is interesting information to audit.
>          */
> 
> Number 1 will be true on systems without file capabilities: CAP_SETPCAP is
> removed from all processes. (Incidentally, how does one determine if file
> capabilities are available on a given machine?)
> 
well you can look in the configs for
CONFIG_SECURITY_FILE_CAPABILITIES=y