Fwd: Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150211/0b3bf77f/attachment-0001.bin