684008 – pE for /sbin/init has special logic that makes it unboundable

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.

Bug 684008 - pE for /sbin/init has special logic that makes it unboundable

Summary: pE for /sbin/init has special logic that makes it unboundable

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	kernel
Sub Component:
Version:	6.1
Hardware:	Unspecified
OS:	Unspecified
Priority:	high
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	Eric Paris
QA Contact:	Jan Malanik
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2011-03-10 21:46 UTC by Eric Paris
Modified:	2011-05-23 20:43 UTC (History)
CC List:	3 users (show)
Fixed In Version:	kernel-2.6.32-130.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2011-05-23 20:43:41 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2011:0542	0	normal	SHIPPED_LIVE	Important: Red Hat Enterprise Linux 6.1 kernel security, bug fix and enhancement update	2011-05-19 11:58:07 UTC

Description Eric Paris 2011-03-10 21:46:46 UTC

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

Comment 2 Eric Paris 2011-03-12 00:20:15 UTC

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 3 RHEL 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.

Comment 8 Aristeu Rozanski 2011-04-07 14:14:35 UTC

Patch(es) available on kernel-2.6.32-130.el6

Comment 11 Jan Malanik 2011-04-27 08:04:08 UTC

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?

Comment 13 Eric Paris 2011-04-27 12:58:24 UTC

Did you use the correct command line including caps_bound_init ?

Comment 14 Jan Malanik 2011-04-29 06:22:54 UTC

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

Comment 15 Eric Paris 2011-04-29 13:36:50 UTC

Inside grub add "caps_bound_init" to the kernel line.  This patch is only activated when that is added to the cmdline.

Comment 16 Jan Malanik 2011-05-02 14:44:37 UTC

succesfully verified on -130 kernel for drop kill+chown I can see:
CapPrm: ffffffffffffffde
CapEff: ffffffffffffffde
CapBnd: ffffffffffffffde

Comment 17 errata-xmlrpc 2011-05-23 20:43:41 UTC

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

Note You need to log in before you can comment on or make changes to this bug.