Hi!
> > No, you have no reason to care about that. Do you also scan
> > to code itself to see if it might try to delete your files?
> > An elfcap executable is inert without the setuid marking.
>
> Setuid doesn't tell me anything about the executable. It might have null
> capsets, it might just inherit caps, it might drop everything. Who knows
> unless you check.
>
> If i'm going to the trouble of searching my drive i want to see the
> capabilities. This involves 2 steps with elfcap (scan for setuid root, read
> and parse header) and only one with inode based. Memory based is O(1).
> We'll just have to agree to disagree in this category, it's a judgement
> call.
Right. It is slow; I told you that. But it is secure. Agreed?
> > > I would prefer the in-memory system (especially to the elfcap one),
> > > although I think it should use a memory mapped file instead of
> > > memory only.
> >
> > Such a file would be one more thing to protect. The only reason
> > to bother would be kernel memory limits, but one shouldn't have
> > hundreds or thousands of privileged executables anyway.
>
> The only problem with the in-memory model is the need to reboot to make
> changes. Some might consider that a feature, I do not. I never was a big
> fan of securelevels and that's very close to it.
Another big problem of in-memory model is that it takes your precious
kernel ram. And you potentially want _lots_ of files to carry
capabilities headers (even if just in order to drop unneeded
privileges from /bin/cat; dropping priviledges from cat is _not_
completely crazy).
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:34 EST