lkml.org 
[lkml]   [1999]   [Apr]   [12]   [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.

>> Whilst that appears to be a difficult scenario to follow, it is
>> most definately a valid one to watch for, and I would suggest
>> the following addition to your prosal to help deal with it.

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

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

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

Please advise where I have misunderstood the situation?

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