On Thu, 12 Feb 2015 03:19:46 +0530, noyb noybee said: > Well, any program which has root credentials is still allowed to call > chroot(it needs to get a new passphrase before) but not any program > with root credentials can exit it. Well see... now you have a problem. If you don't allow that chroot program to fork() or exec(), you now have the passphrase sitting in memory someplace (since you need to pass it back), and exploit code can find it in memory. If you allow fork/exec into other programs, it gets worse - now you need to pass that passphrase to children. And if you're using the passphrase for the chroot() call *itself*, you have an even bigger problem - whatever access that passphrase adds is now available *anywhere inside the chroot*. So all I need to do is find a way to exploit the chroot, and now I have access to resources outside the chroot. At which point your security scheme is *totally* broken. Instead of your original: > I am trying to prevent access to files outside the "jail" unless they specify > a specific passsphrase. You've just handed unfettered access to the files to the exploit. How about you concentrate on "how were they able to access files outside the chroot in the first place"? > Once a passphrase is used for a chroot system call, it is never > returned(pseudo-random) again. Or so you hope. :) It's easy to design security schemes that work if code follows the rules. The fun is designing code that withstands attempts to break the rules. Consider abuse of inherited file descriptors - say stderr is open to a logfile. My exploit code closes fd 2. What happens the next time somebody opens a file, and then something does fprintf(stderr,....)? What happens if code trawls the process image and finds the magic key? What happens if somebody forks? Or double/triple forks? What happens if somebody sets LD_PRELOAD and then causes an exec()? What happens if somebody manages to attach a child process to your process and then triggers an unexpected SIGCHLD? (Hint - it's *trivial* to actually do that - see if you can guess how before reading the link below...) Henry Spencer, a long time ago, wrote a good set of things to worry about when writing set-UID programs - most of which also apply to chroot code. Note that this is *not* a complete list, it's *just* the low-hanging fruit. http://www.daemon-systems.org/man/setuid.7.html Now, can you explain what problem you're trying to solve with this security scheme?
Attachment:
pgpPCOJWyHfgZ.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
