* Russell Coker said: > >> } > >You can prevent that easily. Just deny read access on libc.so.6, leaving the > >executable bit set. > > I doubt that. See the following strace. NB I don't have a spare system to > test this on at the moment. If you're sure it'll work then try it. ;) Try to set a shell scripts permissions to 711 and then exec it. You will be allowed to exec it, but the shell interpreter won't be allowed to OPEN it for reading. > >> Of course you could pre-load a library that replaces the dlopen call, but > >> your system probably won't work in such a fashion. > >It would. You could add CAP ability to the dl* family of functions to test > >for the credentials of the user that invokes the library. Much easier and > >cleaner IMO. > > That will probably work. It's a lot of work though, and if they can get a Hmm... not that much, IMO, it just adds one test to the dlopen() function - whether the user has certain caps raised or not. > statically linked program installed then they get access anyway... That's true unless they don't use the standard library. > Or they can write a program that calls the open() system call directly by > number (I've worked with code that does this with clone(), I'm sure I could > write code for open() in a few hours. Not if capabilities are used. You can set file system capabilities and one would need the same caps as above to read the file. > >> Mounting /home, /tmp, and /var/tmp in a noexec fashion is probably a better > >> idea. > >I agree. That's what I do with users I don't really trust. noexec, nosuid, > >nodev. Pity that /tmp has to be executable, but the OpenWall patch makes it > >possible to secure it anyway, besides mode 03777 makes it quite secure. > > Why does /tmp have to be mounted with execute permission? mc uses it to, e.g. read archive files - it creates an executable script in /tmp. Probably some other programs use it as well for this same purpose (gcc?) > Why mode 03777 not 01777 as everyone else uses? The sticky bit allows the user to delete a file only when he owns it, and SGID bit makes sure that any file created by some user will have the same group as the directory, with appropriately set umask I can run the /tmp purging script not as root, but as a user which is a member of the group that owns /tmp. Call me paranoid :)), but I don't trust the purging scripts to work flawlessly ever and always :)) marek
Attachment:
pgp6wE4MIpMn5.pgp
Description: PGP signature