On Thu, Dec 03, 2015 at 05:02:31PM +0100, Miroslav Grepl wrote: Walsh was the person okaying the removal of this code. Can he not just come out and defend his decision for himself, instead of sending you out to do his ditry work? > 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. > > -- > 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. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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.
