On 08/15/2016 04:10 PM, Andrew Lutomirski wrote: > On Mon, Aug 15, 2016 at 12:59 PM, Daniel J Walsh <dwa...@redhat.com> wrote: >> >> On 08/10/2016 03:42 PM, Andrew Lutomirski wrote: >>> 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? >> That was just an example. The idea would be to allow a user to build a >> service that he wants to run at boot time or login time from >> his homedir. But wants to lock it down and at least isolate it from his >> homedir. Running it with a container type for example. We are >> working on non-root service containers. > I thing doing this is very valuable, but it doesn't need selinux or > any other form of MAC, and what I'm saying is that I'd like to see > this type of isolation be implemented in a way that doesn't require > selinux or any other LSM. > >>> 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. >> I don't see seccomp as being a good deal easier, but the point being we >> want to take >> advantage of all isolation tecnigues available in Linux. Dropping Caps, >> Read Only file system >> labeled file isolation, dropped syscalls ... > Everything you've mentioned with the sole exception of labeled files > is something that naturally offers its full power and configurability > directly to the process doing to isolation without needing any > systemwide configuration. So a user systemd can isolate a user daemon > by itself without needing to ship privileged policy or to get a > privileged process to label files on the user's behalf. No privilege required for SELinux either. I just want types that the user can access and set labels. SELinux requires NO privs at all. Users can set types on files in their home directory and can switch to other types. runcom is a perfect example.
I don't want systemd --user to run as anything but the users UID and as the users context. I just want a way to be able to specify in a unit file that I want this process to run with this label type and this MCS label. > --Andy > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
