Messages in this thread | | | Date | Mon, 12 Apr 1999 08:24:06 +0100 (GMT) | From | Riley Williams <> | Subject | Re: 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/
| |