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: <1295645135.3403.31.camel@localhost.localdomain>
Date:	Fri, 21 Jan 2011 16:25:34 -0500
From:	Eric Paris <eparis@...hat.com>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	"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

On Sun, 2011-01-16 at 19:16 -0800, Andrew G. Morgan wrote:

> I'm not a supporter of system-wide security contexts changing under
> running programs. Previous experience has taught me that tricking a
> program into thinking it has one sort of privilege and then
> withdrawing it without notice can be dangerous.

But a bounding set doesn't affect a running program's abilities, the
bset is only applied at exec().  So if it's fcaps based you have all
that wacky kill logic.

>  Since privileged
> programs include shells that invoke privileged commands to perform
> system admin tasks, I consider a global bounding set to be trouble in
> the making. 

No question, but then again, if you have CAP_SYS_MODULE there are a lot
easier ways to make trouble   :)

> If we were to delete that special code what I think is missing from
> the current kernel model, is not a global bounding set, but a 'kernel
> auto-exec' securebits value. One that can be set by an admin at
> runtime to suppress the root-is-all-capable behavior of the auto-exec
> process, and defer the privilege escalation to carefully audited file
> capabilities on the relevant helper binaries.

But how can that leave us with an impotent root?  Root would be easily
able to craft a file with any caps it wants in fI and fP on any of the
plethora of helper programs the kernel calls and escalate away it's
impotence.

I'd really like to drop a cap from an entire system never to return.
Maybe I can get there by exposing the bset of the kthread which launches
the helpers (makes me feel very dirty).  But that is smaller than the
global bset....

-Eric

--
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/