Messages in this thread |  | | | From | alex.buell@tahallah ... | | Date | Wed, 14 Apr 1999 16:56:11 +0100 (BST) | | Subject | Re: caps in elf, next itteration (the hack get's bigger) |
| |
On Wed, 14 Apr 1999, Ingo Molnar wrote:
> no. This is a misconception. The point is to reduce the power of > actually executing security-relevant code, thus reduce the chance of a > system compromise. Having some sort of (mostly inactive!) super-user > around in the migration period is not at all broken. The point is to > get rid of random setuid root binaries (ping, traceroute, etc.) and > system daemons (klogd, syslogd, lpd, etc.) executing with full system > priviledges. A considerable percentage of those binaries needs only a > small subset of system priviledges. We do _not_ want to remove the > administrator, that is a different task.
Thoughts for the day:
What capabilities will we want? Will they be defined by the admin themselves, or will it be a full set of capabilities available to the admin?
What I'm concerned about is that if we go ahead and build a capability enabled system, and then those POSIX boys go and define their own idea of a capability system, these two could prove to be incompatible. That would be a disaster. Have the POSIX people actually defined the capability standards yet? If not (or if they are in the middle of deciding that), there's NO point in doing anything UNTIL we have a STANDARD that all UNIXes will conform to. And then there's the question of capabilities over shared networked filesystems (especially on a network populated by different UNIX systems). Looking over the discussions on this subject for the past week or so, it looks like we're trying to kludge capabilities into Linux. I especially don't like the suggestions that capabilities be built into the filesystems - this has the potential to make it completely unportable to different filesystems (i.e trying to run Linux off NTFS for example 8)
One potential answer might be *firstly* define a newer ELF standard that is completely incompatible with the current ELF standard which will ensure that older kernels booted on a capability-enhanced system will NOT be able to run ANYTHING, thus closing that security hole, and *secondly* capability-ehanced kernels SHOULD not be able to run older ELF binaries. Then we can properly encode capabilities into the binaries, yet enforce security.
I like this idea. A lot. Hey, if we're gonna break free from the past, let's go the whole hog and add in ACLs too. We do want that A1/B1 security rating, don't we? 8) We all know Microsoft has lost to us, but we haven't really won against certified operating systems such as VAX/VMS.
Ah, this thought just hit me just now. What we're trying to do is clone VAX/VMS!! 8)
Cheers, Alex -- /\_/\ Legalise cannabis now! ( o.o ) Grow some cannabis today! > ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - Now back in the United Kingdom!
- 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/
|  |