Considering the current case, without the file capabilites, I note
- if the caller of /bin/sh is ROOT, the capabities are inherited. Thus
my request has no relevance in that case.
- if the caller does first setuid to non-root, the capabilities are
cleared, unless KEEP_CAPS is explicitly set. Thus, my requested
change would not cause problems with your buggy mail program.
- if the caller goes through all the trouble of setting KEEP_CAPS and
changing to non-root, I would expect it to be sensible that the
caller also intends the execve code to inherit capabilities.
As an experiment and example, I made a small patch to Ubuntu 2.6.24
kernel, to make it work like I think it should: if KEEP_CAPS is set,
they are inherited (see at end).
I'm ok with the current kernel code, which seems to clear the
KEEP_CAPS on execve. Thus, each executable must again re-enable it, if
it needs capabilities inherited further...
I'm looking at network oriented devices, where executables or
interpreted content from network sources is executed by helper
applications or directly as executables. Depending on the source of
the "code", the helper application or the downloaded exectuable may be
allowed to run with different permissions (capabilities, uid/gid
etc). [For example, look at android security model with manifests of
requested and declared permissions, but applied to everything
downloaded or installed].
File capabilities (nor selinux) won't work, because the "helper
applications" need to be executed with different capabilities and
permissions, depending on the "manifests" of the downloaded
"code". Obviously, serious permissions are granted only to properly
verified "code" (signed).
[Any ideas how selinux would help to enforce a permission which is
dynamically defined by installing application?]
I'm using "code" in quotes, because in my mind, it can include HTML,
word documents, spreadsheets, images. Data formats are getting so
complex, that they start to look more like interpreted code, than
plain passive data.
File capabilities (and setuid/setgid bits, selinux attributes) have
another problem: they only work properly on internal disk. No sane
person would allow them to be effective from removable media or NFS.
-------------------
This only handles the case where file capabilities are not enabled. If
enabled, I would need to remove the bprm_clear_caps call from the
branch that gets executed when the file does not have any special
capabilities defined.
-------------------
--- fs/exec.c.orig 2008-08-21 00:51:46.000000000 +0300
+++ fs/exec.c 2008-08-28 11:18:13.000000000 +0300
@@ -1072,6 +1072,12 @@
bprm->e_uid = current->euid;
bprm->e_gid = current->egid;
+ if (current->keep_capabilities) {
+ bprm->cap_inheritable = current->cap_inheritable;
+ bprm->cap_permitted = current->cap_permitted;
+ bprm->cap_effective = 1;
+ }
+
if(!(bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)) {
/* Set-uid? */
if (mode & S_ISUID) {
--- security/commoncap.c.orig 2008-08-21 00:51:47.000000000 +0300
+++ security/commoncap.c 2008-08-28 16:20:34.000000000 +0300
@@ -282,7 +282,7 @@
static inline int get_file_caps(struct linux_binprm *bprm)
{
- bprm_clear_caps(bprm);
+ /*bprm_clear_caps(bprm); */
return 0;
}
#endif
--
