1

This is a typical schroot.conf configuration I use:

[label]
description=whatever
type=directory
personality=linux
preserve-environment=true
directory=/wherever
users=UserForSchrootOnly
profile=desktop_no_tmp

No root-users directive.
Separate home directories for schroot env, not using host's /home.

I login with host OS's UserForSchrootOnly user to these schroot environments. I usually add this user to the /etc/sudoers.d/someConf file inside schroot, with a line,

UserForSchrootOnly ALL=(ALL:ALL) ALL

One of my goals of this setup is to have a quite isolated environment (not for audit kind of strict isolation, but efficient in practice), both through schroot and by using an OS user only for this purpose and nowhere else. On the other hand, for practical reasons it's much easier to have this dedicated user to be sudoer also, inside the schroot env of course.
A use case is to run an untrusted closed source app.

My concern is:
Since UserForSchrootOnly user is a sudoer inside the schroot env, is it possible to be any compromise of security for the host system due to this? Any way to use sudo elevation inside schroot env, to access something outside of schroot or outside UserForSchrootOnly's home dir on the host system?

Man page of schroot.conf mentions that root access to chroot is a serious risk; I'm not concerned about user's misbehaviour. My concern is about the untrusted, closed source app, taking advantage of the sudoer user it runs.

I'd like to point out that although this seems like an ideal scenario for a sandbox like firejail, I've failed to run some apps with it, even adding the --no-profile parametre. Also other scenarios include apps that need more recent libs, so I need to setup a Debian Testing or Ubuntu schroot env to run the untrusted app inside.

Krackout
  • 2,480
  • 9
  • 25
  • 1
    `schroot` is a very old way of doing things. You should probably think about updating your practices to use cgroups. Separate namespaces for users, pids, mounts, networking, etc are far more secure than just a chroot (e.g. `sudo kill` in a chroot can kill any PID, while `sudo kill` from within a pid namespace can only kill PIDs in its own ns). You could use something like `docker` (there are many pre-built containers for debian, ubuntu, etc as well as tiny distros like alpine, and it's easy enough to build your own), or if you want to DIY you could use `systemd-nspawn` with `debootstrap` – cas May 23 '21 at 15:46
  • Thanx for the `cgroups` proposal, I'll have a look on it. Regarding Docker, I prefer Linux containers, which I use in other use cases. As light they can be, it's much more immediate (for my tastes) to use schroot in comparison to LXC, Docker, or systemd-nspawn, that's why I prefer it on many occasions. – Krackout May 23 '21 at 22:25

0 Answers0