linux-kernel - Re: [RFC] Capabilities still can't be inherited by normal programs

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: <CALCETrWNboHVRm_aZ-Fvqri6PW3C4FPfuLLe3-8q7+-vgEP2nw@mail.gmail.com>
Date:	Mon, 10 Dec 2012 10:12:35 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	"Serge E. Hallyn" <serge@...lyn.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge@...onical.com>,
	Markku Savela <msa@...h.iki.fi>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs

On Mon, Dec 10, 2012 at 7:47 AM, Casey Schaufler <casey@...aufler-ca.com> wrote:
> Put an ACL on the program file.
> If you want different users to run with different privilege
> make two copies of the program and give them different
> ACLs and cap sets.
> If your program is so big that making a copy is a disk space issue
> it is too big to have privilege.
> If you can't deal with having the have different paths for different
> users write a shell script that redirects to the correct version
> based on user id.
>
> This is not rocket science. The kernel shouldn't be crammed
> with mechanism and complexity just because disto/"OS"/site
> developers can't be bothered with learning how the existing
> facilities work.

I agree.  But I think that the existing capability support is already
overcomplicated, and I'd rather make it simpler.  Sticking the
complexity in userspace is too difficult right now because it requires
fiddling with the file inheritable mask.

I think that the Windows approach is worth looking at.  See here:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa375202%28v=vs.85%29.aspx

In the Windows model, each capability ("privilege") can be in one of
three states: enabled (i.e working right now), permitted (i.e.
available upon request but not currently enabled), or removed
(disallowed to this process and all of its children).  Permitted
privileges are always inherited when a child process is created.

This is *way* simpler than Linux's model, and it works just fine*.

--Andy

* In fairness, MS apparently forgot to add the ability to drop
permitted privileges until XP SP 2 or thereabouts.  Adding it was a
no-brainer, though, because Windows has no concept of setuid, so
sendmail-style attacks are impossible even in principle.
--
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/