lkml.org 
[lkml]   [1999]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: capabilities in elf headers, (my) final (and shortest) iteration
Date
From
Riley Williams <rhw@BigFoot.Com> said:
> >>>> 4) Include in the capabilities header a field holding the
> >>>> timestamp of the last capabilities validation.

[...]

> > 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.

If the file just holds the capability-validation timestamp, I'd just need
to make that later than the time the system is booted. The kernel won't be
any wiser. And it also means that my executable checked yesterday won't run
today because the system rebooted. Or the system checks _all_ files for
capability timestamps on boot.

If you want to validate, you have to have a _trusted_ source for the data
against which to check. The file itself might forge whatever you check
somehow, so it's out. Only possibility remaining is a fully
kernel-controlled data structure: Either the filesystem or a
kernel-internal structure holding the capabilities and the open files in
the VMS manner.

[...]

> >>> 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.

e3fsck(8), validation in mount(8).

> > 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...

Yep. That capability is called "x" bit in Unix.

> 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.

No. You need to check it _each_ time the system boots with your scheme. For
_all_ files. Or keep a list of capable files around (i.e., VMS).

[...]

> > ...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?

> 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.

An idealistic pessimist: 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. This means capabilities in
filesystem or centrally in the kernel a la VMS. Building a
halfway-capability system just invites disaster when the true and the faked
get mixed later on.

Any capability system means a lot of rework in the userland, no way around
it. Any kludge that promises to "fix" that is broken by its very objectives.

> 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.

But you have to keep your goal in mind, and be careful not to go down a
road that doesn't allow you to reach it.

> > 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.

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.

[...]

> > 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.


> > And then, How do we get there?

> Eitheer via a hybrid system or not at all. Take your pick.

A hybrid scheme that _allows_ us to get there. Or a complete rewrite of the
userland.

> > 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...

Show me _one_ system run by a security concisious sysadmin that runs 1.2.x
and 2.0.x alternatively. Note that there are _no_ huge security risks
involved there!
--
Horst von Brand vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Viña del Mar, Chile +56 32 672616

-
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.296 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site