On Wed, Aug 10, 2016 at 12:26 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Tue, Aug 09, 2016 at 01:32:10PM -0400, Daniel J Walsh wrote: >> >> >> On 08/09/2016 10:24 AM, Michal Sekletar wrote: >> > Hi all, >> > >> > Most of you are probably aware that systemd except running as PID 1 >> > also runs inside user sessions. This allow users to define their own >> > "user services" and start up various scripts and background processes >> > right after logging in. >> > >> > In default targeted policy PID 1 runs with init_t SELinux label and >> > --user instances of systemd are not confined by SELinux, i.e. running >> > with unconfined_t. >> > >> > During Flock I got asked whether we can change that and run systemd >> > --user instances in some confined domain. Fixing this on systemd side >> > should be trivial, i.e. we would have to add SELinuxContext= option >> > with appropriate value to /usr/lib/systemd/system/user@.service (unit >> > file used for spawning user instances of systemd). >> > >> > I am writing this email with a hope that we can discuss if above >> > proposal even makes sense (what are possible gains from system >> > security perspective) and if yes what is appropriate SELinux label to >> > use (I guess we would need new one and define policy for it). >> >> Yes we should allow for systemd to specify a label, but the label needs >> to be transitioned from the user domain. >> >> For example if I login as unconfined_t and want to run a service as >> httpd_t, then I need to be able to transition from >> unconfined_t to httpd_t. As long as systemd-user is running as the user >> domain, then SElinux will control this. > > That doesn't seem useful ;) Why would a user by able run anything as httpd_t? > The way I understand Michal's question is: in what ways specifying a > context for systemd --user that is different than current > unconfined_u:unconfined_r:unconfined_t > would be actually useful? What general rules for transitions could be > provided?
My intuition is that, especially for non-root processes, using the various sandboxing features available without MAC or any privileged configuration (ProtectXYZ, namespaces, seccomp, etc) is already a good deal easier to work with, more flexible, and less needing of centralized policy than SELinux. Maybe Fedora should focus on that type of isolation for systemd user instances rather than trying to make SELinux work for them. --Andy -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
