lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.219 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site