linux-kernel - Re: [PATCH 0/3] Taming execve, setuid, and LSMs

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: <g2xcb0375e11004191502h7ab186d2nc692ff749a4a2c99@mail.gmail.com>
Date:	Mon, 19 Apr 2010 18:02:22 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Eric Biederman <ebiederm@...ssion.com>,
	"Andrew G. Morgan" <morgan@...nel.org>
Subject: Re: [PATCH 0/3] Taming execve, setuid, and LSMs

On Mon, Apr 19, 2010 at 5:39 PM, Serge E. Hallyn <serge@...lyn.com> wrote:
> Quoting Andrew Lutomirski (luto@....edu):
>> >
>> > ( I did like using new securebits as in [2], but I prefer the
>> > automatic not-raising-privs of [1] to simply -EPERM on uid/gid
>> > change and lack kof checking for privs raising of [2]. )
>> >
>> > Really the trick will be finding a balance to satisfy those wanting
>> > this as a separate LSM, without traipsing into LSM stacking territory.
>>
>> I think that making this an LSM is absurd.  Containers (and anything
>> else people want to do with namespaces or with other new features that
>> interact badly with setuid) are features that people should be able to
>
> Yes, but that's a reason to aim for targeted caps.  Exec_nopriv or
> whatever is more a sandbox than a namespace feature.
>
>> use easily, and system's choice of LSM shouldn't have anything to do
>> with them.  Not to mention that we're trying to *add* rights (e.g.
>> unprivileged unshare), and LSM is about *removing* rights.

Is a targeted cap something like "process A can call setdomainname,
but only on one particular UTS namespace?"

>>
>> >
>> > I myself think this feature fits very nicely with established semantics,
>> > but not everyone agrees, so chances are my view is a bit tainted, and
>> > we should defer to those wanting this to be an LSM.
>> >
>> > Of course, another alternative is to skip this feature altogether and
>> > push toward targeted capabilties. ?The problem is that path amounts
>> > to playing whack-a-mole to catch all the places where privilege might
>> > leak to a parent namespace, whereas [1] simply, cleanly cuts them all
>> > off at the source.
>>
>> Agreed, that sounds painful.  My secret goal is real
>> userspace-controlled (by unprivileged users, no less) sandboxes, in
>> which case in-kernel target capabilities are probably impossible.
>
> Not sure what you mean by that last part - inside the sandbox, you won't
> get capabilities, targeted or otherwise, but certainly targeted capabilities
> and a sandbox are not mutually exclusive.

Agreed.

What I want is a syscall that says "make me a sandbox" and then for
that program to be able to intercept and modify most (all?) syscalls
issued from inside the sandbox.  But programs in the sandbox probably
need to call exec, and if the sandbox's owner can muck around with
exec'd programs, then exec had better have no security effect.  Hence
a need for  some kind of restricted exec.  The sandbox owner would
then make up own targeted capabilities if needed.

But yes, targeted capabilities for kernel containers are probably
orthogonal to sandboxes.

>
> Thanks for responding, I'll take another look at your patchset in detail.

Thanks!

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