linux-kernel - Re: patch to make Linux capabilities into something useful (v 0.3.1)

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]

Date:	Sun, 10 Sep 2006 12:36:31 +0000
From:	Pavel Machek <pavel@....cz>
To:	Theodore Tso <tytso@....edu>, David Madore <david.madore@....fr>,
	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>
Subject: Re: patch to make Linux capabilities into something useful (v 0.3.1)

Hi!

> > I emphasize that the filesystem support patch described above, alone,
> > will *not* solve the inheritability problem (as my patch does), since
> > unmarked executables continue to inherit no caps at all.  With my
> > patch, they behave as though they had a full inheritable set,
> > something which is required if we want to make something useful of
> > capabilities on non-caps-aware programs.
> 
> This is what scares me about your proposal.  I consider it a *feature*
> that unmarked executables inherit no capabilities, since many programs
> were written without consideration about whether or not they might be
> safe to run without privileges.  So the default of not allowing an
> executable to inherit capabilities is in line of the the classic
> security principle of "least privileges".   
> 
> I agree it may be less convenient for a system administrator who is
> used root, cd'ing to a colleagues source tree, su'ing to root, and who
> then types "make" to compile a program, expecting it to work since
> root privileges imply the ability to override filesystem discretionary
> access control --- and then to be rudely surprised when this doesn't
> work in a capabilities-enabled system.  However, I would claim this is
> the correct behaviour!

But this is not how it behaves today, right? I do not think you could
push 'break-make-as-root' as a bugfix to -stable ;-).

> absence of an explicit capability record.  Both of these should be
> overrideable by a mount option, but for convenience's sake it would be
> convenient to be able to set these values in the superblock.

Would per-system default capability masks be enough? ... .... okay,
probably not, because nosuid is per-mount, and this is similar.

> As far as negative capabilities, I feel rather strongly these should
> not be separated into separate capability masks.  They can use the
> same framework, sure, but I think the system will be much safer if
> they use a different set of masks.  Otherwise, there can be a whole
> class of mistakes caused by people and applications getting confused

Can we simply split them at kernel interface layer? Libc could do it,
preventing confusion...

> The solution is to _extend_ the capabilities system: for example, by
> adding default inheritance masks to cater for system administrators
> who value convenience more than security, and to add new bitmasks for
> negative privileges/capabilities.

Agreed.
							Pavel
-- 
Thanks for all the (sleeping) penguins.
-
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/