linux-kernel - Re: [PATCH] System Wide Capability Bounding Set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110127140255.GB2935@localhost>
Date:	Thu, 27 Jan 2011 08:02:55 -0600
From:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	"Serge E. Hallyn" <serge@...onical.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, sgrubb@...hat.com
Subject: Re: [PATCH] System Wide Capability Bounding Set

Quoting Eric Paris (eparis@...hat.com):
> At this point it seems to me like what I must do is add a way for a task
> with enough priv to force caps out of the bset and pI of the kthread
> which upcalls to run userspace programs.  Thus when the kthread runs a
> program it cannot give those privs....

Exactly, that's what I was envisioning.

How about adding an optional kthread-wrapper program which, when
specified on the boot cmdline, will be the program to wrap any
userspace programs which the kernel executes?  Then that program
can do the work it needs to remove capabilities from pI and X,
set selinux context, etc.  Just a thought, seems somewhat more
elegant thatn hard-coding the behavior in the kernel, but not sure
it's practical.

> Does this seem reasonable?  What would such an interface look like?
> (This is scarily like the old meaning of CAP_SETPCAP....)

I'm not sure it's unreasonable, but in one sense it seems like just
walking one more step toward the end of the plank:  next, you're
going to have to worry about a kernel-spawned thread, from which you've
denied cap_sys_module, writing to /boot/initrd* the malicious steps
it wanted to take, to be executed at next boot when it still has
cap_sys_module.  (Fine, enter TPM :)

What is the attack vector you're actually envisioning?  Does some
trojan come in and overwrite a program which which it hopes the
kernel will execute?  Or is there just an existing vuln in such
a program?  Are there other ways we can address these?  Can we find
a way to classify the kernel-spawned userspace programs?  Perhaps
based on the selinux context assigned to the program, we can assign
some level of trust that noone could have modified the source?

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/