Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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....
Comment 3RHEL Program Management
2011-03-12 00:39:18 UTC
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.
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?
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
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