linux-kernel - Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Sep 2006 07:46:06 -0400
From:	Joshua Brindle <method@...too.org>
To:	David Madore <david.madore@....fr>
Cc:	Pavel Machek <pavel@....cz>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part
	3/4: introduce new capabilities

On Sun, 2006-09-17 at 23:16 +0200, David Madore wrote:
> On Sun, Sep 17, 2006 at 04:39:16PM -0400, Joshua Brindle wrote:
> > The benefits of this are so minuscule and the cost is so high if you are 
> > ever to use it that it simply won't happen..
> 
> I'm withdrawing that patch anyway, in favor of a LSM-style approach,
> the "cuppabilities" module (cf. the patch I posted a couple of hours
> ago with that word in the title, and I'll be posting a new version in
> a day or so, or cf. <URL:
> http://www.madore.org/~david/linux/cuppabilities/
>  >).  In this case, the relative cost will be lower since the
> security_ops->inode_permission() hook is called no matter what.
> 

You misunderstand. I don't mean the performance cost is high, I mean the
cost of an application to actually be able to run without open() (what I
was saying before, static built, no glibc, no conf files, no name
lookups, etc). I never see this being used in the real world because of
the extreme limitations.

And that is just practical stuff, there are still problems with
embedding policy into binaries all over the system in an entirely
non-analyzable way, and this extends to all capabilities, not just the
open() one.

> But I agree that the value of restricting open() is very dubious and
> it was intended mostly as a demonstration.  So if there is strong
> opposition to this sort of thing, I'll remove it.
> 
> Happy hacking,
> 

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