Messages in this thread | | | Date | Thu, 15 Apr 1999 08:28:00 +0100 (GMT) | From | Riley Williams <> | Subject | Re: capabilities in elf headers, (my) final (and shortest) iteration |
| |
Hi Horst.
>>>> 4) Include in the capabilities header a field holding the >>>> timestamp of the last capabilities validation.
>>> Against what? I might very legitimately hold a binary with all >>> caps, and in the above scenario I could doctor your header to >>> my entire satisfaction anyway.
>> I've obviously overlooked something serious if you can freely >> doctor a read-only file that can't be made writable without >> dropping the cap flag, so perhaps you could explain what that >> is...
> Validation means checking against something.
Nodz...
> If this something resides in the same file, it can be doctored > if the file can be somehow modified. And you explained how > above.
Since that something (the time the system was last booted) does not live in that file, or in any other file for that matter, your agrument fails miserably.
True, if you can predict the precice second at which the next booting kernel will grab the time, you could edit the file successfully, but even an error of ONE SECOND will mean that your edit would fail...and that error could easily be reduced to TEN MILLISECONDS on am ix86 based system...
>>> You'd need some central repository of legitimate capabilities... >>> and then the capabilities-in-(header|filesystem) are pointless
>>>> 6) In addition, modify point 1 to also set the validation >>>> timestamp to the current kernel boot timestamp if it >>>> successfully set the cap flag.
>>> OK, so capabilities are useful only between reboots now, and >>> have to be set again each time?
>> Can you suggest a better way?
> The above way just won't work, and no similar strategy will.
Any method that does NOT include some form of validation after each boot is inherently insecure, and you can argue all you like against including security, but you stand little chance of having your arguments accepted.
> The whole idea of capabilities in the file itself is broken.
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...
Remember, the ONLY time ANY capability information needs to be checked is when the system has just been asked to execute the file in question as otherwise it's irrelevant. As a result, any argument against reading the contents of the file are non-starters as the file will be read as part of executing it, just to find out what format it's in.
As a result, that argument is a non-starter, best described as FUD.
> It smears out the privileges over the filesystem and the file > itself...
The only serious alternative offered so far was to have a file somewhere that listed the name and path of all capable binaries together with their capabilities, and your comment above doesn't even differentiate between the two systems...
> ...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.
Out of curiosity, are you an idealist, a pragmatist or a realist? Based on the above and your earlier posts, I'd have to assume you're an idealist who's unwilling to accept anything other than a perfect world.
As a pragmatist myself, I see the move from s[gu]id to capabilities being of necessity an evolutionary one, starting from the current position of pure s[gu]id and moving through a hybrid scheme such as the above towards a pure capabilities scheme.
> It looks very fragile and complex to me. And all to be able to > continue using current tools that know nothing whatsoever about > special privileges, and so are sure to get it wrong.
If one needs SPECIAL tools to handle the BACK-UP of binaries with capabilities, then the capability implementation is by definition broken.
Granted, theere will need to be special provision to RESTORE such binaries if they get corrupted, but nobody's said otherwise.
> Again: Where do we want to go?
Preferably to a pure capabilities based system.
> And then, How do we get there?
Eitheer via a hybrid system or not at all. Take your pick.
> Broken systems (where old and new kernels run concurrently) will > last a very short time, or none at all.
That is an extremely unlikely scenario, considering there are still systems in use running kernels prior to 2.0.0. I suggest you adopt a more realistic stance...
> So this is not a serious problem.
Really?
> Systems that import filesystems from elsewhere (via NFS, CD-ROM, > diskette, ...) will be around for a long time.
So will hybrid networks, with different systems running diffeerent kernels. I run one myself, with systems running various kernels from the 2.0.27 to 2.0.36 range, and other systems running the 2.2.4 and 2.2.5 kernels. Those running the 2.0 series kernels are unlikely to be changed in the near future.
> That is where compatibility and checks are warranted. And the > simplest way to get this right is for the affected filesystem > writers to be aware of capabilities, or just not handle them at > all. Same goes for file managing tools.
The simplest way to get it right is to devise a SECURE system that can be handled by the existing tools with MINIMAL modification.
> How do other systems do this? It was said that VMS essentially > holds the privileged files open all the time and modification of > them is not allowed. This could be fine, as long as there are > few such files. But I suspect this will not be true for long...
In my opinion, there are ALREADY too many s[gu]id files to make that an option...
>>> Please, let's concentrate on where we are going. If your system >>> can be rebooted into an older kernel that doesn't know of >>> capabilities, you are almost sure to get screwed anyway.
>> Let's start by defining where were going, as you and I appear to >> have different ideas of where the goalposts are. Here's my >> understanding of what is required:
>> Q> A system for implementing capabilities under Linux that is not >> Q> susceptible to security problems either under a caps-aware >> Q> kernel or under a caps-ignorant one.
> Not really needed: If I want a secure system, I won't get into > that scenario; or my previous system was secured, and subverting > it for the new setup is very hard. And it won't last anyway.
If we don't go through that scenario, then we will never get to a pure caps-based system in my opinion.
Best wishes from Riley.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * ftp://ftp.MemAlpha.cx/pub/rhw/Linux * http://www.MemAlpha.cx/kernel.versions.html
- 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/
| |