On 12/03/2015 05:11 PM, Stephen Smalley wrote: > On 12/03/2015 11:02 AM, Miroslav Grepl wrote: >> On 12/02/2015 10:23 PM, Stephen Smalley wrote: >>> On 12/02/2015 02:47 PM, Dominick Grift wrote: >>>> On Wed, Dec 02, 2015 at 01:20:30PM -0500, Stephen Smalley wrote: >>>>> On 12/02/2015 05:18 AM, Dominick Grift wrote: >>>>>> Let's continue the discussion here. >>>>>> >>>>>> The last answered questionnaire is below, any further questions or >>>>>> comments?: >>>>>> >>>>>> ---------------------------------------- >>>>>> >>>>>> "systemd --user" concept is broken as we can see/read from >>>>>> this >>>>>> thread from SELinux point of view. >>>>>> >>>>>> It was working fine except that it was trying to log to the audit >>>>>> system >>>>>> which unprivileged processes arent allowed to do. >>>> >>>>> What's the dbus solution for this issue? >>>> >>>> Here is some chatter about the above i believe: >>>> >>>> https://bugs.freedesktop.org/show_bug.cgi?id=83856 >>> >>> The code is easier to follow. bus/audit.c:bus_audit_init() will only >>> open the audit socket if the process has CAP_AUDIT_WRITE. >>> bus/selinux.c:log_callback() will only try to send the message to audit >>> if the audit socket was opened, but will always send the message to >>> syslog regardless. Thus, if the dbus-daemon instance has >>> CAP_AUDIT_WRITE, you get the messages logged to audit and syslog; >>> otherwise, you only get them in syslog. This is the most general >>> approach, as it supports both privileged and unprivileged dbus-daemon >>> instances, including the case where the system-wide bus is running in a >>> container and does not have CAP_AUDIT_WRITE (even though it thinks it is >>> root / uid 0) and the case where the session bus has CAP_AUDIT_WRITE (if >>> one were to set cap_audit_write in the file capabilities on the >>> dbus-daemon executable, not recommended but possible), as well as the >>> more common cases of a system-wide bus with CAP_AUDIT_WRITE and a >>> session bus without it. systemd should likely do something similar, but >>> using the journal. >>> >>>> >>>> >>>>>> >>>>>> Are we able truly explain the enforcement here? >>>>>> >>>>>> I think i was able to at least identify some of it, but i probably >>>>>> have >>>>>> overlooked other compelling arguments: >>>>>> >>>>>> Any processes that needs to be able to "control" any system-wide >>>>>> systemd >>>>>> user unit, will be able to "control" all system-wide systemd user >>>>>> units. >>>>>> >>>>>> In practice that means that a process may be able to for example >>>>>> start a >>>>>> application even though it does not have access to execute that >>>>>> application by telling systemd --user do start that applications >>>>>> on its >>>>>> behalf >>>> >>>>> Can systemd-run --user be used to escape any of the following: >>>>> a) SELinux sandbox, >>>>> b) libvirt / svirt confinement, >>>>> c) newrole -r to a different, more restricted role or -l to a >>>>> different >>>>> level, >>>>> d) runcon to a more restricted domain. >>>> >>>>> If so, then there is a problem with systemd --user not applying its >>>>> own >>>>> access controls over its operations. >>>> >>>> >>>> I cannot answer above currently. I can tell you that obviously one >>>> needs >>>> to be able to talk to ones systemd --user instance to be able to >>>> tell it >>>> to do anything on ones behalf obviously. So by default all of the above >>>> will likely not work, since they most likely do not have the >>>> permissions >>>> to talk to systemd --user even if they were able to execute systemctl >>>> and/or systemd-run. >>>> >>>> But even then, things also depend on whether systemd --user runs in a >>>> private domain or the login user domain (in my policy it runs in a >>>> private domain except for unconfined users) >>>> >>>> Those are good questions but i do not see how they are directly related >>>> to the question whether systemd --user should be a selinux user space >>>> object >>>> manager or not (in my view it obviously should but i am not trusted by >>>> systemd maintainers, walsh is trusted and walsh gave systemd >>>> maintainers >>>> the impression that systemd --user does not have to be an selinux >>>> object >>>> manager) I strongly suspect that is wrong. >>> >>> I cited those examples because they were applicable to the stock Fedora >>> policy and, if valid, would provide a rationale for restoring the >>> controls regardless of what one might believe about confining desktop >>> applications because they would indicate vulnerabilities or regressions >>> in functionality provided by Fedora. That seemed more likely to be >>> convincing to the Fedora SELinux maintainers. >>> >>> For sandbox, they don't appear to allow it to connect in the first >>> place: >>> >>> $ sandbox /bin/bash >>> bash-4.3$ systemd-run --user id >>> Failed to create bus connection: Permission denied >>> >>> So there the systemd access controls wouldn't come into play. >>> >>> For confined user roles, systemd-run --user <command> failed on Fedora >>> 22 with: >>> >>> Failed to start transient service unit: Access denied >>> >>> and journalctl showed: >>> >>> systemd[15007]: Can't send to audit system: USER_AVC avc: denied { >>> start } for auid=N uid=N gid=N >>> path="/run/user/N/systemd/user/run-PID.service" cmdline="systemd-run >>> --user id" scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 >>> tcontext=system_u:object_r:user_tmp_t:s0 tclass=service >>> >>> So removing the systemd --user controls is a regression in the >>> protection being provided in Fedora, IIUC, although I'll let the Fedora >>> SELinux maintainers speak to that. >> >> First I would like to talk about non-working "systemd --user" because we >> lack a support of pam_selinux in F23. So if you allow confined users to >> start user services you will end up with unconfined_service_t. Which is >> wrong because of systemd --user is running as init_t. The object manager >> helps here indeed. >> >> We have pam_selinux support in F24 and theoretically you will end up >> with a correct user context. But without missing object manager you will >> be able to start user services under SELinux user context and under a >> user Linux identity. >> >> This is a reason why I told this is broken now. We have more regressions >> here. And I believe that first we would have systemd --user running with >> correct labeling. We have it working for unconfined users on the latest >> rawhide because we removed unconfined_domain attribute for init_t and >> added needed fixes. >> >> The second issue is missing object manager. It is strongly related to >> confined SELinux users who are defined by own restricted SELinux >> policies and still restricted by own Linux identity. >> >> If we have running 'systemd --user' with the correct user type >> pam_selinux support then we can experiment and make working SELinux >> object manager in systemd --user at all if it is used and requested >> widely. > > So, what is needed for correct systemd --user pam_selinux support still? > Has anything been done wrt eliminating usage of > security_compute_user()? Are you blocked on that? > > Two parts here. I believe we will need to have it working also without pam_selinux changes. It means to have init_t running as a confined domain which we have with the latest rawhide. The second part - eliminating usage of security_compute_user() is in our TODO and Petr will send a mail if we have something for a discussion or a patch. Thank you. -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
