Re: Non-root chroot

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.