Re: Modified version of jexec allows non-root access into jails

In response to Colin Percival <cperciva@xxxxxxxxxxx>:

Bill Moran wrote:
http://people.collaborativefusion.com/~wmoran/code/jailme.html

Feedback is appreciated.

Be very very careful. Both chroot(2) and jail(2) can only be called by
root, and for very good reasons. Unprivileged users can create hardlinks
to files which they don't own, including setuid root binaries; but these
binaries will probably not operate correctly inside a jail of an attacker's
construction (e.g., which contains a root password of "r00tmeplz"). The
attacker can thus obtain jailed root privileges, create all the setuid
root binaries he wants, and then run them from outside of the jail to
obtain root privileges in the host machine.

Interesting. I hadn't considered that possibility.

The fact that you're calling jail_attach(2) instead of jail(2) makes me
slightly less worried, but you'd still have to work very hard to convince
me that this should become part of the FreeBSD base system.

Well, my ultimate goal is to get it in _only_ if it makes sense as part
of the base system -- and I'm not even fully convinced of that yet.

The scenario you're describing (correct me if I misunderstand) would be a
user who has a normal account on the host system, but has root access inside
a pre-existing jail. Said user could create a setuid binary inside the
jail filesystem that would continue to be setuid in the host, and basically
leads to a privilege escalation. This is possible even without the addition
of the jailme program, however. Basically, any user who has root inside a
jail and a normal account on the host system can easily get root permissions
outside the jail. It's probably possible to prevent this by careful use
of nosetuid mounted filesystems within the jail.

You also describe a scenerio where a user can create a jail of his own
design and give himself root inside it, thus allowing him to use the
setuid trick to get root on the host as well. The place this falls down
is that the user would need to already have root to create the jail in the
first place.

I suppose I hadn't thought this through because our setup has users with
normal accounts both inside and outside the jail, and our ultimate goal
is to keep these users from ever having or needing root access in either
place.

I'll wrap it up and submit it as a port. It seems like most of the current
jail utilities start out as ports anyway, so that seems to be a good path
to determine whether or not it's a proper fit for the base system. If not,
it can just stay a port for anyone who finds it useful.

--
Bill Moran
Collaborative Fusion Inc.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: getaffinity/setaffinity and cpu sets.
    ... created in a jail such that you know whether they can be changed in a ... This anonymous set will also be inherited across fork/thread ... In this model presently there are nodes marked as root. ... One place I'd like to implement CPU affinity is in the Sun Grid Engine ...
    (freebsd-arch)
  • Re: getaffinity/setaffinity and cpu sets.
    ... The notion would be that you can create a new numbered cpuset with cpuset. ... You can modify or inspect its affinity with get/setaffinity above and the CPU_WHICH_SET argument. ... This set would not be modifiable by user processes or by processes in a jail. ... Another option would be to expel the offending thread from the set that is in violation and reparent it to the real system root along with a syslog message or similar. ...
    (freebsd-arch)
  • Re: getaffinity/setaffinity and cpu sets.
    ... created in a jail such that you know whether they can be changed in a ... This anonymous set will also be inherited across fork/thread ... In this model presently there are nodes marked as root. ... be allocated a set of cpus that they can't change, ...
    (freebsd-arch)
  • Re: chroot versus jail for the name daemon
    ... > assuming named is running as user and group bind (rather than as root)? ... > 3) What happens if named is broken while in a jail, ... That means an attacker can set things up so ...
    (freebsd-questions)
  • Re: jail() House Rock
    ... Think carefully about exactly what kind of privileges your clients get. ... normal user account on the main server, and root inside the jail. ...
    (FreeBSD-Security)