cap_brpm_set_creds() question
Seth Arnold
seth.arnold at gmail.com
Tue Jun 22 12:25:23 BST 2010
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?)
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?
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?)
Thanks
More information about the AppArmor
mailing list