lkml.org 
[lkml]   [1999]   [Apr]   [15]   [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:
> 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. If this something resides in
the same file, it can be doctored if the file can be somehow modified. And
you explained how above.

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

The whole idea of capabilities in the file itself is broken: It smears out
the privileges over the filesystem and the file itself, and works only for
some types of files (how about a webserver written in Perl?). 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.

Again: Where do we want to go? And then, How do we get there? Broken
systems (where old and new kernels run concurrently) will last a very short
time, or none at all. So this is not a serious problem. Ssytems that import
filesystems from elsewhere (via NFS, CD-ROM, diskette, ...) will be around
for a long time. 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.

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

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