Unprivileged chroot() and Outrun

Posted Mar 16, 2021 7:52 UTC (Tue) by smurf (subscriber, #17840)
In reply to: Unprivileged chroot() and Outrun by mcon147
Parent article: Unprivileged chroot()

My program might want to open a sqlite database and a log file, *then* chroot to /run/user/UID/my-jail. When I restart the thing it might want to do the same thing and read the session files which the first program dumped there.

There's no way to do that without chroot.

Unprivileged chroot() and Outrun

Posted Mar 16, 2021 19:07 UTC (Tue) by floppus (guest, #137245) [Link] (7 responses)

That doesn't require an *unprivileged* chroot; you could do something like:

logfile = fopen("foo.log", "a");
sqlite3_open("foo.db", &db);
sprintf(rootdir, "/run/user/%d/my-jail", getuid());
chdir(rootdir);
unshare(CLONE_NEWUSER);
chroot(".");
caps = cap_get_proc();
cap_clear(caps);
cap_set_proc(caps);

Unprivileged chroot() and Outrun

Posted Mar 17, 2021 10:09 UTC (Wed) by smurf (subscriber, #17840) [Link] (5 responses)

I know that there are several options to do this with a privileged process. My point is that this task should not require any. That way, if the user does get hacked, at least there's no setuid executable for them to play with.

Unprivileged chroot() and Outrun

Posted Mar 17, 2021 17:39 UTC (Wed) by floppus (guest, #137245) [Link] (4 responses)

Right, but the point is that you *don't* need a setuid executable. Creating a user namespace (calling "unshare") normally doesn't require any special privileges.

Unprivileged chroot() and Outrun

Posted Mar 18, 2021 1:03 UTC (Thu) by pabs (subscriber, #43278) [Link] (3 responses)

It does if your distro or sysadmin has disabled unprivileged namespaces by default.

Unprivileged chroot() and Outrun

Posted Mar 18, 2021 12:54 UTC (Thu) by domenpk (guest, #12382) [Link] (2 responses)

That same distro or sysadmin will almost surely also disable unprivileged chroot (being a newer and less tested feature), so you won't gain anything.

Unprivileged chroot() and Outrun

Posted Mar 27, 2021 18:54 UTC (Sat) by l0kod (subscriber, #111864) [Link] (1 responses)

chroot(2) is much more simple (and limited) than namespaces, which is why there is no valid reason to be able to disable it (i.e. this unprivileged chroot is not, by design, a security risk).

Unprivileged chroot() and Outrun

Posted Apr 6, 2021 19:28 UTC (Tue) by immibis (subscriber, #105511) [Link]

is less of* a security risk

Unprivileged chroot() and Outrun

Posted Mar 17, 2021 22:39 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

Reading through user_namespaces(7), I can think of the following problems:

1. You have to set up uid_map and gid_map if you want to interact with the filesystem. Since you are using chroot(), you almost certainly do want to interact with the filesystem, so this is an obvious source of friction. Not impossible, just annoying.
2. Assuming you don't have CAP_SETUID/GID (in the parent user namespace), which is a safe assumption because otherwise you wouldn't be asking for "unprivileged chroot" in the first place, then the man page appears to say that you can only map your own UID/GID. That certainly makes logical sense (the whole point of this operation is to give you a "containerized" or unprivileged CAP_SETUID, so we need to constrain it somehow), but it also means that stat(2) will lie to you about the ownership of any file you don't own (the UID/GID is unmapped, so it gets converted to a generic "don't know" value in the child namespace).
3. SCM_CREDENTIALS will also produce unmapped garbage, as will plenty of other UID/GID-related interfaces. If you want to IPC with any process owned by a different user (e.g. a daemon running under a role account), you basically can't confirm its identity, although it can confirm yours (which may be sufficient in some cases).
4. Pervasively fixing all of the above, testing it, and maintaining everything, is likely harder than just granting CAP_SYS_CHROOT in the first place.