[...]
> > If the file just holds the capability-validation timestamp, I'd
> > just need to make that later than the time the system is booted.
> In which case, it would still FAIL the test - didn't you notice that I
> very specifically stated that the test was for EQUALITY with the time
> of last boot.
But what do you validate against? "Yes, this file contains a legal
capabilities header, so I'll stamp it with my boottime" isn't quite
enough...
[...]
> >> If true, then the idea of having information on how to load an
> >> executable in the file itself is also broken. After all, that's
> >> a capability in itself - the capability to execute the file. If
> >> the kernel doesn't recognise the header format of the file, it
> >> can't execute it...
> > Yep. That capability is called "x" bit in Unix.
>
> WRONG !!!
>
> The 'x' bit only says that the file should be regarded as executable,
> and provides ZERO information on how to load the executable when the
> user asks to run it.
Why "how to run it"? The _capability_ to be run is in the metadata, the
_how_ is (encoded into) the file.
> If you don't believe me, try the following:
>
> 1. Find a web page on your system. Any web page.
>
> 2. Set the 'x' bit on it.
>
> 3. Type in the path and name for the relevant file.
>
> 4. Watch Linux REFUSE to execute it because it doesn't know how to,
> despite the fact that it has the relevant 'x' bit set.
Format mismatch, not "can't be done because it isn't allowed". Two
quite different outcomes.
[...]
> >>> ...and works only for some types of files (how about a webserver
> >>> written in Perl?).
>
> >> That's up to the PERL interpreter to handle, not the kernel.
> >> After all, the kernel ignores s[gu]id on scripts already, and
> >> the only reason s[gu]id works on PERL scripts is because the
> >> PERL interpreter handles the relevant capabilities if it sees
> >> the s[gu]id flag set on the script it's running.
>
> > Great. "Any Perl script that states `I've got capability A' is
> > now capable?! You _seriously_ suggest to trust the Perl (and sh,
> > and ...) interpreters?
>
> I don't suggest anything, YOU are the one making that suggestion. Can
> I suggest you start by checking how s[gu]id perl scripts CURRENTLY
> work before you start accusing me of things I have neither done nor
> said...
How do you encode the capabilities in a perl script, so I (the writer) am
unable to forge them? How about the security of the requisite all-capable
perl interpreter that is going to run any random script (hint: the script
might crack the interpreter...)?
[...]
> > The idea of capabilities was designed to be able to build _more_
> > secure systems. To be able to do that in practice, you _have_ to
> > play by the capability rules, else the whole system is liable to
> > be the victim of as yet undiscovered attacks.
>
> Agreed, and that's what everybody except you appears to be trying to
> do. I'm curious why you aren't?
Secure systems aren't build by kludgeing on "security features", they have
to be concieved, designed and built that way from the ground up, using
simple, easy to check and tamperproof mechanisms. The schemes vented here
don't live up to that, IMVHO, and might stand in the way of doing it right
later to boot.
What I sorely miss in this whole discussion is the design of the userland
that goes with capabilities. It isn't enough to get capabilities working
any old way, the system has to use them wisely if you want security
advantages.
[...]
> > Other way around: If you can do something like that _without_
> > capability aware tools, the system is irrecoverably broken: This
> > allows faking and smuggling capabilities.
>
> Nope, that's entirely up to the tools that do the RESTORE stage of the
> procedure, and the BACK-UP stage should be completely transparent to
> them if it's to have any meaning whatsoever...
I don't want any old "backup tool" to be able to read, say, /etc/shadow or
the underlying disk without specific permission, i.e., capability. So this
has to go in anyway in some form. Why not make the tool aware then? It will
have to help check security.
> >>> Again: Where do we want to go?
> >> Preferably to a pure capabilities based system.
> > I'm not so sure... I _like_ Unix, and a pure caps system is
> > _not_ Unix in any reasonable meaning of the term.
> I like the Linux implementation of UNIX, but I do NOT like the version
> of UNIX that Tandy supplied under the name XENIX (not to be confused
> with IBM's XENIX, which worked differently again).
> As far as UNIX in general goes, I've yet to come across anything that
> can be even considered a standard when it comes to system security,
> other than the idea of having users log in and restrict what they can
> do depending on who they are. Every different dialect of UNIX that
> I've met does the restricting in a different way to all the others...
But all those ways fall far short of what you _could_ do with real
security. Again, a really secure system (via whatever means) is _not_
Unix-like at all.
[...]
> > Show me _one_ system run by a security concisious sysadmin that
> > runs 1.2.x and 2.0.x alternatively.
>
> Presumably so you can have a go at cracking them, and them blame it on
> me for publicising them. Sorry, I'm not that daft...
Weaseling out here?
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/