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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
