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?
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.
A process may, for example, be able to use this to stop a sensitive
process bypassing SELinux access control
And the point is if we have big benefits of this level of
isolation?
With access control the benefits often depend on the requirements. but
in general since selinux touts flexibility and one of the big benefits
here is that we can contain access of processes to units actions.
without this processes are potentially able to bypass selinux by telling
systemd --user to do stuff on their behalf
Do we have real examples how it prevents possible security
flaws?
No, and why should we? SELinux does not prevent possible security
flaws. SELinux is Linux access control extension
It enforces integrity and optional confidentiality or
comparmentalization.
Do we talk about confined desktop here?
No we are talking about a set of components that without SELinux access
control extension potentionally allows processes
to bypass SELinux access control restrictions in some cases
_______________________________________________
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.
_______________________________________________
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.
