Messages in this thread | | | Date | Thu, 25 Jun 1998 05:13:44 +0000 | From | Eric Warnke <> | Subject | Re: Secure-linux and standard kernel |
| |
MOLNAR Ingo wrote: > > On Wed, 24 Jun 1998, Mitchell Blank Jr wrote: > > > Andi Kleen wrote: > > > If you want to make this secure you hooks in the startup code to drop priviledges even > > > earlier I think. > > > > Yuk. > > > > The real fix will come in 2.3 when ext2 can interface with the capabilities > > stuff. Until then, this will help things. Coming up with an ugly kludge > > (different startup code, different ld.so, etc) is just a distraction from > > real goals like: > > > > 1. Making sure the startup code and ld.so are bullet-proof. If this isn't > > the case the system isn't going to be secure worth a damn anyway. > > Avoiding the problem for a few binaries by writing an alternate loader > > only results in there being more of this code around to audit. > > > > 2. Working towards the filesystem set-capability stuff as mentioned above. > > the point is, we dont even need the filesystem set-capability stuff. By > including this feature in the ELF loading mechanizm somehow, _all_ > filesystems (that support setuid root) will benefit from this, not only > ext2fs. Theoretically, we only need a single bit in the inode to indicate > that a binary is trusted. The rest can be done in ELF-land.
This may sound over the top, but follow the logic here.
Here is a crazy Idea, what about having all suid / dangerous programs be split into client /server through unix domain sockets. You could then chroot an envoronment for users that would have access to the unix domain files, and never have a user execute suid ever agian. I know that getting programs to work under this environment would be a hassle, but for truly secure systems, it would be nice to be sure that users cannot execute privledged code ever, execpt through a set protocol. Any devience could be logged, and the system could also track users if neccessary.
Any takers?
-Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |