Hide Forgot
In order to drop capabilities system wide we need to reduce the capability set of all userspace tasks. This includes /sbin/init. The problem is that the kernel has special logic when setting pE for /sbin/init. Hopefully the upstream maintainers will agree this logic is unnecessary and we can drop it. If not this whole effort might be in vain... Upstream posting to discuss issue: http://marc.info/?l=linux-security-module&m=129979322027008&w=2 text of original upstream posting: As most of you know by now I'm trying to limit/drop capabilities system wide and running into problems. I finally have a nearly working implementation but I still have problems with the init task. My basic premise is that I'm dropping capabilities from pI pE pP and pB(set) inside an initrd before I launch the real /sbin/init. The assumption was that all userspace tasks would thus not be able to attain the dropped capabilities. (We all know the problems usermodehelper caused with this situation.) I have, however, hit a problem with the global init task itself. We have special case logic, which I don't understand, inside security/commoncap.c::cap_bprm_set_creds() which looks like so: /* For init, we want to retain the capabilities set in the initial * task. Thus we skip the usual capability rules */ if (!is_global_init(current)) { if (effective) new->cap_effective = new->cap_permitted; else cap_clear(new->cap_effective); } Which causes my init task to end up with caps like: Name: init Pid: 1 PPid: 0 CapInh: 0000000000000000 CapPrm: fffffffffffcffff CapEff: fffffffffffffeff CapBnd: fffffffffffcffff What you notice is that although pP, pI, and pB are being handled properly pE is not. pE is getting the CAP_INIT_EFF_SET (unrelated, why do we still drop CAP_SETPCAP from this task?) and I don't have a way to drop it. Why do we have/need this logic? If init wants to drop capabilities across exec why shouldn't it be allowed to? I commented out the corner case and it seemed to work just fine with CapEff: fffffffffffcffff. What's the logic here? Can I drop it? -Eric
upstream didn't believe the logic made any sense either. I posted a patch to remove the logic for 6.1 BUT I included a new command line options caps_bound_init to enable the new change just to be safe....
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Patch(es) available on kernel-2.6.32-130.el6
I can't verified it. I tried kernel 2.6.32-125 and -130. I did 3 drops(cap_chown, cap_kill, both) for each kernel. In every case I see "fffffffffffffeff" in CapEff. I used dracut 004-50. Any ideas?
Did you use the correct command line including caps_bound_init ?
I used: dracut -i /etc/caps.conf /etc/cmdline -a caps --add-drivers "`cat lsmod`" -f /boot/init_drop_kill_125.img "2.6.32-125.el6.x86_64" where: cat /etc/caps.conf rd.caps=1 rd.caps.initdrop=cap_kill #cap_chown, or both rd.caps.disablemodules=1 rd.caps.disablekexec=1 rdloaddriver=autofs4,sunrpc,ipv6,dm_mirror,dm_region_hash,dm_log,uinput,power_meter,ses,enclosure,sg,dcdbas,microcode,serio_raw,ghes,hed,k10temp,hwmon,amd64_edac_mod,edac_core,edac_mce_amd,i2c_piix4,i2c_core,ext4,mbcache,jbd2,sr_mod,cdrom,sd_mod,crc_t10dif,ahci,megaraid_sas,dm_mod /etc/cmdline doesn't exist in "lsmod" file I have got list of modules. Last parameter I changed for every kernel(-130,-125) I uised configuration based on https://bugzilla.redhat.com/show_bug.cgi?id=677340#c12
Inside grub add "caps_bound_init" to the kernel line. This patch is only activated when that is added to the cmdline.
succesfully verified on -130 kernel for drop kill+chown I can see: CapPrm: ffffffffffffffde CapEff: ffffffffffffffde CapBnd: ffffffffffffffde
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0542.html