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:	Mon, 11 Sep 2006 10:09:02 +0200
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!

> > > 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.
> 
> Per system defaults would also be good, but I believe it would also be
> a good idea for their to be per-filesystem defaults.  Yes, not all
> filesystems would support per-filesystem defaults, since this requires
> extensions in their superblock; for those, they would only have the
> per-system defaults.

Aha, okay... David, doing global defaults should be very easy, as
should be doing ext3 example conversion...

> > > 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...
> 
> But that means libc would need to know which bit positions were
> positive capabilities, and which were negative, and adding new
> capabilities would require a matching change with libc.  Not a good
> idea, I think....

Okay, I guess we could hardcode the mask (top 16 capabilities are
"normal") but yes, I see your point now. We probably want different
syscalls, even if underlying implementation shares the code...

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/