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.
_______________________________________________
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.
