Date: Fri, 30 May 2014 23:10:00 GMT From: Jilles Tjoelker <jilles@stack.nl> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/121073: [kernel] [patch] run chroot as an unprivileged user Message-ID: <201405302310.s4UNA0oc071079@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/121073; it has been noted by GNATS. From: Jilles Tjoelker <jilles@stack.nl> To: bug-followup@FreeBSD.org, jille@quis.cx Cc: Subject: Re: kern/121073: [kernel] [patch] run chroot as an unprivileged user Date: Sat, 31 May 2014 01:02:46 +0200 In FreeBSD PR kern/121073, you wrote: > We (Ed and I) thought it should be possible to chroot as non-root, > This should (hopefully) increase the security, because no setuid-root > and privilege dropping after the chroot(2) call is longer needed. This change may be useful for package building without root. The disable setuid/setgid part looks similar to Linux's prctl(PR_SET_NO_NEW_PRIVS). In Linux, this is a separate operation that is a precondition for certain operations if unprivileged. I found two possible security risks with this: Firstly, unprivileged chroot might be used to break out of a chroot. For example, a directory file descriptor may be put onto a unix socket (to defeat kern.chroot_allow_open_directories), chroot to a subdirectory, get the file descriptor back, fchdir and abuse "..". If this is the first chroot, fd_jdir will stop it but other chroots (but not nested jails) can be escaped from. This can be fixed by only allowing a first or second chroot (fdp->fd_jdir == NULL || fdp->fd_jdir == fdp->fd_rdir). Due to locking this check must be in change_root(). Secondly, a mac_vnode_execve_will_transition could lower as well as increase privilege; it may be better to reject the exec entirely if a MAC transition is denied. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405302310.s4UNA0oc071079>