Re: Non-root chroot

Important point is that the user is not obliged to hand in any particular
"su" program. The user may hand in any "su"-like code suitable for escaping
the chroot.

вс, 3 авг. 2025 г. в 03:11, Jason Bacon <bacon4000@gmail.com>:

>
> After a little more thought, I realized that this example begs the
> question:
>
> Does "su" actually accept an /etc/[master.]passwd that isn't owned by root?
>
> Any time I write a utility intended to be run by root, let alone suid, I
> code in a check that any files affecting its behavior are
>
> 1. owned by root
> 2. not writable by any other user
>
> On 8/1/25 07:38, Dmitry Mikushin wrote:
> > The fundamental security concern with allowing unprivileged chroot() is
> > *privilege escalation through file system manipulation*:
> >
> >  1. A regular user creates their own directory structure in their home
> >     directory (where they have full write permissions)
> >  2. The user creates a fake |/etc/passwd| file within this structure,
> >     containing a password hash for root that they know
> >  3. The user then chroots into this fake filesystem
> >  4. Inside the chroot, when the user runs |su| (or similar
> >     authentication utilities), these programs read what they believe is
> >     the system's |/etc/passwd| file - but it's actually the attacker's
> >     crafted version
> >  5. The |su| command validates the password against the fake password
> >     file and grants root privileges
> >
> >
> > пт, 1 авг. 2025 г. в 14:20, Jason Bacon <bacon4000@gmail.com
> > <mailto:bacon4000@gmail.com>>:
> >
> >
> >     I'm wondering if there is any way to perform a simple chroot without
> >     having root privileges.  The goal is to test software builds with
> >     access
> >     to a limited set of dependencies, as poudriere does, but outside the
> >     FreeBSD ports system, and in some cases on hosts where the user has
> no
> >     root access.  This will prevent configure scripts with hard-coded
> >     search
> >     paths from finding things we don't want them to find.  Portability to
> >     other POSIX platforms would be desirable as well, but is not
> essential.
> >
> >     It's not clear to me why chroot() wasn't designed to support this use
> >     case.  There's lots of documentation stating that it's a security
> risk,
> >     but I don't see why it couldn't have been designed to be run by a
> >     regular user without escalating privileges inside the chroot.  I.e.
> if
> >     user "joe" does such a user-level chroot call, then all chrooted
> >     processes run as "joe", but with the path of the chroot dir
> >     prepended to
> >     every open() call (after $CWD is prepended to relative paths, of
> >     course), so that processes can only access files in the chroot dir.
> >     User "joe" would have the same privileges inside the chroot that he
> has
> >     on the host. One of the other security concerns mentioned is jail
> >     breaks, but if joe managed to escape the chroot, he'd only be hurting
> >     himself by borking the test build, so that's not a concern here.
> >
> >     It might be possible to port fakechroot
> >     (https://github.com/dex4er/fakechroot <https://github.com/dex4er/
> >     fakechroot>), proot
> >     (https://github.com/proot-me/proot <https://github.com/proot-me/
> >     proot>), or something similar, but is there
> >     anything else on FreeBSD that can do this?
> >
> >     Thanks,
> >
> >              Jason
> >
> >     --
> >     Life is a game.  Play hard.  Play fair.  Have fun.
> >
> >
>
>
> --
> Life is a game.  Play hard.  Play fair.  Have fun.
>