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