Arbitrary applications and limiting PATH

Discussion in 'all things UNIX' started by Gullible Jones, Feb 12, 2013.

Thread Status:
Not open for further replies.
  1. Just a weird random thought inspired by rbash...

    Normally a restricted shell session would limit a user to their home directory. There'd probably be a ~/bin directory with a bunch of symlinks in it, comprising a highly restricted subset of commands; and the user's PATH would be limited to that, to keep them from breaking out. The rest of the work is done by the restricted shell itself, which prevents the user from running anything with / in its name, or resetting PATH.

    Now, what if you could do something similiar with arbitrary applications?

    Code:
    $ mkdir ~/bin
    $ ln -s /usr/bin/firefox ~/bin
    $ PATH=~/bin firefox
    
    Hurray, Firefox's PATH is now reduced to include only Firefox. What happens now if someone exploits a hole in Firefox, and can execute arbitrary commands?

    Code:
    system("bash");
    
    Oops, bash isn't in PATH, can't do that.

    Code:
    system("env PATH=blah blah blah... bash");
    
    Oops, env isn't in PATH, can't do that.

    Code:
    system("/usr/bin/bash");
    Ouch, pwned.

    Thus the question here: is there a way to prevent arbitrary applications from launching things with absolute paths, as with a shell in restricted mode?

    P.S. I realize this is pure userspace stuff, like SRP; a local privilege escalation exploit, run within the compromised program, would tear it to pieces. OTOH, that would mean an attacker would need one more exploit - or, at least, a lot more work - to get at my user account. In my book, anything that raises the difficulty bar for an attacker is probably good.
     
  2. Mrkvonic

    Mrkvonic Linux Systems Expert

    Joined:
    May 9, 2005
    Posts:
    10,223
    What are you trying to resolve?
    What is the start state?

    You can use chroot, for example.

    Mrk
     
  3. ... chroot. Right. I am basically talking about chroot here. N/M.

    Edit: the problem is that chroots are kind of a pain to set up, and entering them requires root privileges.
     
    Last edited by a moderator: Feb 13, 2013
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.