[...]
> > But what do you validate against?
>
> I very specifically didn't address that point as I don't have anything
> constructive to say there. All I said about that was that the
> capabilities were validated against some trusted source, which they
> have to be for the idea of capabilities to make any sense.
That's what I have been saying all along. If you don't elaborate on this
central point, you aren't saying how to do it at all. Case closed.
[...]
> For reference, I recently had to make use of the 2.0.27 kernel that
> came with RedHat 4.1 on one of my systems to deal with a problem that
> had occurred, as neither the 2.2.4 kernel that machine normally uses,
> nor the 2.0.36 kernel used prior to that and still on the system,
> could handle the new network card I installed to replace a failed one,
> and I had no other means of getting an updated 2.2.4 kernel on the
> machine in question.
That is your personal machine, I presume. If it was a production, security
sensitive machine, you would have had to find another, trusted way to get a
new kernel onto it.
[...]
> > Why "how to run it"? The _capability_ to be run is in the
> > metadata, the _how_ is (encoded into) the file.
>
> That _how_ is ALSO a capability in any meaningful interpretation of
> the word, and that capability is stored in the file itself.
"Capability to run this perl script as an ELF executable" makes a lot of
sense, agreed.
[...]
> For example, where would you find the following capabilities?
>
> 1. Permission to execute the file [metadata]
>
> Linux and all versions of MS-DOS both put this in the metadata,
> Linux in the file's mode, MS-DOS in the file's extension.
This is not part of the file itself, it is data about the file, i.e.,
metadata. Nothing wrong there.
> 2. How to load a file for execution [either]
>
> Linux puts it in the file header, MS-DOS 2.xx put it in the
> metadata (specifically whether the file's extension was BAT (a
> shell script), COM (a memory image) or EXE (a loadable image),
> and MS-DOS 3.xx and later used a combination where files with
> a BAT extension were shell scripts, and files with either COM
> or EXE extensions had their contents checked for whether they
> were memory images or loadable images.
DOS is broken in this regard. And putting information on the file _format_
elsewhere than in the file itself just invites errors, better make the
format self-describing if at all practical: I.e., magic numbers et al in
the Unix way.
> 3. How to display a web page [file]
This kind of stuff is usually handled by some sort of filemanager, the
variety of different file formats is just too big to be handled by the
kernel in any halfway sane way. And new formats are invented every day...
[...]
> > Format mismatch, not "can't be done because it isn't allowed". Two
> > quite different outcomes.
>
> Same difference - it refuses to execute it either way. I could equally
> well have created a binary data file with the 'x' bit set to make the
> same point...
"Sorry, I'd be glad to obligue but I don't know how to do that" and "You
aren't allowed to ask me do that" are quite different outcomes for me.
[...]
> > 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...)?
> Precicely my point: PERL scripts (any scripts, come to that) can't be
> written to encode securrity capabilities within them in a secure way.
And binary executables can't either, for exactly the same reasons.
> The same is true of s[gu]id scripts, and I regard the fact that PERL
> scripts can meaningfully gain s[gu]id priviledges as a MIS-FEATURE -
> in fact, I'd go so far as to call it a BUG !!!
An executable is an executable (that's the Unix tradition), it should be
able to do the same things no matter how it is implemented (another
cherished part of the Unix tradition: Uniformity, even at some cost).
[...]
> > 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.
> Whilst that's basically true, it's also true that they are rarely
> correct the first time round, and for that reason, whatever method is
> used to implement them MUST work in PARALLEL with the existing system
> until it has been proven to be better than the existing system, and
> only then can the existing system be dropped...
That doesn't mean that the secure and the legacy system have to run on the
same machine at the same time. Someday you _will_ have to switch over. And
at that moment (at the very latest) the "legacy compatibility" becomes a
major burden.
> > The schemes vented here don't live up to that, IMVHO, and might
> > stand in the way of doing it right later to boot.
> So far, there haven't been any schemes vented here, only suggestions
> as to how various aspects of the finished design could be implemented.
OK, make the above "The various suggestions on how to implement aspects of
the finished design" then. But these suggestions don't really consider a
finished design, they want to kludge their way in the rough direction of
the final goal, and they do not consider seriously how to really achieve
that final goal, so they are fatally flawed, IMO.
> I've designed enough things in my time to know that a brainstorming
> session like that is an ESSENTIAL prerequisite for a solid design, and
> for that reason, I believe that ALL suggestions should be WELCOMED, as
> should CONSTRUCTIVE criticism of the suggestions made. However,
> DESTRUCTIVE criticism (such as yours) of the suggestions made is to be
> AVOIDED as it only ever results in a flawed design due to necessary
> points not being raised during the brainstorming session.
Perhaps I am mistaken, and my worries are unfounded, but you really haven't
done much to allay them so far. And I sicerely think that worries such as
mine _have_ to be laid to rest for good before _any_ scheme is adopted as
the final design.
Perhaps I'm being overcautious, but where security is involved "Better safe
than sorry".
> > 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.
>
> So far, there isn't even a full list of the capabilities that need to
> be present,
OK, let's work on that then.
> >>> 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.
>
> Who's suggested that it should be able to? Not me, for sure.
Then how do you handle it with your 100% backward compatible tools that
don't need to be even recompiled?
> My claim is that the backup tools do not need to have any special
> capabilities to do their job on the files they have permission to
> access, and I stand by that claim. If you've any sense, so will you.
The backup tool runs with the UID of the backup operator, who doesn't have
permission to read most of the files in the system. It might have to backup
raw disk partitions, which the backup operator can't touch under any
circumstances. Please forget about the copout "allmighty root does all",
that is the essence of what capabilities are all about.
> > So this has to go in anyway in some form. Why not make the tool
> > aware then? It will have to help check security.
>
> What on earth for? It's the kernel's job to check security, not the
> backup tool's job.
Ok, there you have a (partial) point.
-- 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/