continuation of systemd/SELinux discussion from Github

continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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.

        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

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

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWXsVVAAoJENAR6kfG5xmcDvAMAMlHsXmvuSY3o9PTzoM51xek
TLlg8dGB6jtlj6Yz7bqVacObaHRf7OF6meO3+/58Khq1xLVx0dUxR9HrX+ZqbIpd
eI6NSJ+waSKm1dqRI6BFg4QOMNXoTXQcmijWNHoiduT2OXY0LpKuZtC1u0DJddx/
rl6auNwCD7+sqpQMXTYlnutNzBCJ9wVhq8p4rsP0gs5VoSMjTW+PphRkfpIkPGFA
cRO55BhTXXk2wp85ONhjJIvHjNP9Tky3tpH7ULPlqeyyG8BM+sKWtOdDdF1kqNjN
MmuvA9F+fBEl2sOvBxBKVgtfTEPzeaqFmn4o0Su/A9ckM90ic2VFNHHXXqIdQJ8e
Sqi30bG1G7avQf2ZbDCMhUBwE9uyigg99EXVyV/X6NDhYvURZa90vC9UizXhnbLz
6oBkELyk1wt7/Qhqh4XH7nUD7i+G0my4rcgslFE1Qa1aGy8Xrj19xBvD53Z0de3l
QFkDsKDQQelb5McEMPiGvpNIjgGTnt/H5opwqWMnKA==
=/yJI
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Dec 02, 2015 at 11:18:01AM +0100, Dominick Grift wrote:
> Let's continue the discussion here.
> 
> The last answered questionnaire is below, any further questions or
> comments?:
> 

I will start by adding a few comments.

I agree that the SELinux user space object manager support is a bit
fragile and rough edged. (I actually recently sent a message to this
list pointing this out)

Either something is wrong with that support or its documentation.

I noticed that many developer focus a lot on uid=0, and forget that
these day's you do not need access to uid=0 to ruin someones life.

To me, from an SELinux perspective at least, a process is just a process
regardless of the UID it is associated with.

The most common use of SELinux is arguably distributions using it to
enforce their policy on their customers hardware, This is fine but
please remember that some customers which to be able to keep that
discretion to them selves.

I think that means in practice that one should keep that in mind at all
times when something is implemented by not making any assumptions about
whether something is useful or not when that is not appropriate.

You may use access control for one this and I may use if for
another. Your threat model may not align with my threat model.

Let us not forget that SELinux is supposed to be a "flexible" MAC, this
is one of the reasons why we use SELinux and not, say SMACK

Thank you. That is all for now

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWXsh/AAoJENAR6kfG5xmcM5sL/2m5mL9S947+4yy82L6SzC1g
GV6vjG1D+FSwa0tMPXNTuYJcLC28TnHv8aYO6v6sadDW4nPsm1li4PxziScdGmzz
/F1WeCaJ8hFXlJYCvVc4brlREiOiz08BlZob1SOpvsVDrgeYIsvI1CTKsRDQP86u
5OsVDgLim5slcq5rFcYN1eAsDj7KpOw9ozyFg2qRWdACw/TageKu0FNnHr6GtCRG
pva3Y4Pp3cmH+vaSiffciypuzy+wKbZdUbEaUp7QIIqHJ5IICbZ8qFw3mLZUtziW
scglWAzrlfhsiwwVusPjPbhhZAcdRJtEPcve/dmfpQRFtImt2FeIWabjMa98QmnY
HPH/2jZJIr/tGz/PIkT4SLsFRc3fl3LdV5lqLO5GGpvWxw0Xq1ke3TV5J8WCSitt
lGnSdkzRqC9sasSOBS5cilUpYeOrq37LOwVLu12kamwxJpIYeBLnur/f6lcrQzSU
OZDlpU3u59i3oyFbFauHe2p7wLbDKGxOpCEsv95Now==
=5gZK
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Stephen Smalley]

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@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

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

If you can give me a really simple example to test some of the above
then i can try it out and report back.

One can obviously also just try my policy out as per

https://github.com/defensec/dssp/wiki

and see for ones self. Its not fedora policy but atleast my policy
supports systemd --user

> >
> >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@tycho.nsa.gov
> >To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWX0q/AAoJENAR6kfG5xmco1AMAKAu6NJNZsTChlTAZsJ21VWF
gifU/8iCBwz4DBNsdzw7v9dysNl1rymtgV+516KgZe3liB8jYhAwKcFzIPMUo0uc
uRy9XDbYUO00O0z1qx6IDxixnKiXKHTCjsEBLiHQcS71eD31ry7sr49JBr9O0LA8
0RkgodYtAjh4xf2zw4SEPJudsPm3YJrxgp82FA2JnXLIO3352ecuvoaAGlBtsTG2
0IDx0RyxGu7HlXc8cc5d2lN5wpE9JM4gZucXWZI7ArLIQa0cuM/jlUxUvWPPFin/
OZFT6GDL+PGJz12M7AfwLAu/lVzUJDFPFFfrMEBZhxnDlHvHzwJAupR1ENzMIefn
L1JjS6BAXpv05yTOJZ2r8cHipCBG3ju6peG40At72tVQsv+oY2/pBAbYDlOnViNa
iFA8YshSwFte8W2V2nqAqOQu04DDKf9qAgsdqbRR7SihUj/taV5nmNWbtVMkQIo6
BbQOw7IERsJnMxVM0lQ1JYQzQGRTaPMrUk//iH4vmw==
=lQZD
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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?

I vaguely recall XACE logging its avc denials to xorg.log.N instead of
using the audit system, I might be wrong, and also since then xserver runs unprivileged so I am not sure if
anything has changed and whether that still works ( I would need to try
that out since i have XACE disabled ).

I suppose an option for systemd --user would be to log avc denials to journal
instead of audit

> 
> >
> >         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@tycho.nsa.gov
> >To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> >To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> >
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWX1XVAAoJENAR6kfG5xmcyDUL/ArLiJcoTl/mTJEr88xGE2yi
EmE5vWjHQ87DpRg7A/lgUynxfzZ/mETNtS58yvHY0J8x9SnqnQvAlg5xrtIj+V1w
FWCTGuqqaFw2EM0QY0FXruUHXWgg3eRiQRUgs9r7q5iOAvG4fM0DkVTOURc7XkgC
OVdUPRDnRbNH5cGJvUWwUkRRQ+9Ohr4lMSU+J0pp3NkZN+TswTpptGjbc1SI6tXU
4aRZ/CIEl22uTHNtI7/l67+cL6WnKaQ4iEcGmm2UMg33m0oH0FhRs5XspeEVq2ec
zNk80g58v6dinu3YdEPapIp3KjNU9IJVrmlRzFl5kcOmSYmdS/xuethG8w+TV+5q
Rs0bBT7dATOf06j0ZvcgQ+gaALTYwRXp94yK6V7e9AU+f6cFjhPMPyrQu8D1lUZO
LszlO9BNhmONO+bjG3vcuW315l1W/MjYZAu7ZCPM7cAYayO3sd/BLe1TJlknPLWd
/qv14mtfJPLK3TuABIiQW3LUjVbiQwwroW1wZjV/TA==
=HGnK
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Stephen Smalley]

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.

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Dec 02, 2015 at 08:47:15PM +0100, Dominick Grift wrote:
> 
> 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.
> 

The problem is that i sincerely do not know what to do, and i am worried
about this. I would like confirmation about whether or not systemd
- --user needs to be an object manager for consistency in selinux enabled
systems.

If someone can tell me with confidence that it does not then i will
accept that. If someone can tell me with confidence that systemd --user
needs to be an user space object manager because else it will "break
selinux" then I am worried that redhat will not acknowledge that simply
because its not on their agenda.

It is going to take a long time before redhat will be able to produce
any half useful support for systemd --user for confined users, and even
when they get to that point i am afraid they will still leave that gap
simply because i am afraid that its not an priority to them.

In the mean time we might be stuck with this inconsistency.

All Mr. Walsh had to do was tell Mr. Poettering. Hold that commit for
now while i double check whether its desired or not. Instead he gave the
go-ahead to remove code I rely on in a blink of an eye.

If he was right by determining that systemd --user does not need to be
an selinux object manager then i will apologize to him.

If it turns out that it really did not make sense for him to support the
removal of that code then i am sincerely disappointed.

02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWX2SlAAoJENAR6kfG5xmcvd0L/1ZQP0uJoo931bXDIulR/xaY
eH6cPytluJVETS9gNiQTFYVTIIWUdegjaDbE0cW/sHJCHiBcksPc9fXlv30vC4CL
wad26KVMsRZLydxmM/K9IKak/AtRSu4tqmWK/UqXhBOGqMDWLYCJzcSebTC3w/wY
+GlxBMuSczN1a6iSYUSak1fyn47SC1hekGIcd7HE3KEzqI1e+lodC+npV/fn0a6D
9uefujVZZxGM8jxQcU1zaT0SoLNjC8UTMsGXRLc7BRkbE1OgJsE8xIkekPOGSw6k
dsGC4WUMbC+ExU0gLltprdgmpxJpIMsI9jy8yO6PqXaEwbk0MxTcA2OlafChhfJ9
yG0f5cfG6NW3CDQmVf/6WOYzqfE/KAaq8VomPpNRb2HXDPRnOIPbTuSLmMhSGBsB
FuSmuKasrdE+XzfWOE3PM+XkpsDg5QJVsuyP8+t+hcSuSE1oqZeoXflhe5CZtJL8
ma8tHOsZvWG2MzqY17NPgcEZMlqixWeebX+zQUVabA==
=uhHm
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Wed, Dec 02, 2015 at 04:23:51PM -0500, Stephen Smalley wrote:
> 
> 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.

Yes and my use case as well becuase like i suggested:

any process that needs to be able to start any system-wide systemd user
unit will be be able to start all of them

currently this might not sound applicable to much but in the future
there will be potentially many of those units and processes will then
start using systemctl --user to control these units. So then this will
be come an issue.

Also keep in mind that users can maintain user units in ~/.config/systemd

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWX2XAAAoJENAR6kfG5xmcrB0MAL8Lwgtm8qrSPpvsiqA/WF4T
J36dx9HFaiu6DSu4/F69TDynvJluiTGPLLZwUUUrJWxl65LxFDhKIXl4fO3MQogv
g5TlBI8dDxiMk0XYO8w32l6ucpGaMmc63ViP/QIfKv8jSXu1ZNZ7ozF1wPr/lahu
aW7bziyHD9FJMKGGHwnj7mnHkKBTqI/m6EI8pyHTzo2rDZXuyzc2jaEGfgKzkuUp
M6GPUGcPIewrMPw+/GduMORezZnmeWYVxl5cpEywf07Z11IYibVmLLPBPMkrt00Q
GgaOrJ3iyYsD9ecbejCqOrlKtna7MRioY/lX8XeMwYMdkZ2Hl4e6lpaC90SI0rMM
zzCGNhK/mXxfptpOhTQ7WqcF3HIDG4ipEQdvGXMrd1MYq3DzXkfbvrJOBsHybvJN
jRJEpjRRgKiweaWcWYa6wv5Eax/VOn64snD0us2nurGiBzr8O87ff6Egk+MitX/d
j3guYA/CfOyp1ZgP6LIHqJbU0eIQSbMSHqf/L5KCjQ==
=Y4Ct
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Laurent Bigonville]

Le 02/12/15 19:20, Stephen Smalley a écrit :
> 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?
That one I can reply.

The dbus-daemon check if the AUDIT_CAP is set on its process an then 
open the audit netlink and then start logging. The idea was to set the 
file capability on the executable, but Simon (dbus-daemon upstream) was 
not sure he wanted that as dbus-daemon has not been audited and was 
afraid of some security issues (If somebody has an opinion on whether 
the file capability should be set by default or not, please tell me).

These are the "recent" patches involved in the auditing:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=517c4685a8197498dea40918b308beea19155efd
http://cgit.freedesktop.org/dbus/dbus/commit/?id=992236f1c57a7a8930e4c8aeb21f30c2d8af21d3
http://cgit.freedesktop.org/dbus/dbus/commit/?id=983237258dc440419b863461fae15f31cce08639
http://cgit.freedesktop.org/dbus/dbus/commit/?id=a3a5935a0a038c3b44c61ce5719f0f7e647b96c6

Re: continuation of systemd/SELinux discussion from Github

[Miroslav Grepl]

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.

Re: continuation of systemd/SELinux discussion from Github

[Stephen Smalley]

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?

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Dec 03, 2015 at 05:02:31PM +0100, Miroslav Grepl wrote:

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

Common, who are we kidding here? We hardly get any feedback on confined
users. Very little Fedora users use it. how long since the inception for
systemd did it take Fedora to get to this point?

I already did what you intent to do. I think i kind of know what is in
store for you. I predict that it is going to take a loooong time before
Fedora gets it into any semi serious state. I am not trying to be pessimistic
here.

Also this requires a bit of vision, anticipation if you will. If you can
see where systemd is going, and if you see what is already happening on
the system side with services running systemctl --system all over the
place controlling units, then you can easily determine the use case (or
at least some of the more easier ones)

I have been relying on the functionality for I can't remember how
long. I am going to have to live with a certain amount uncertainty for a long time
now. Where will this go?

Also, again let us be frank here. Confined users in Fedora is not what it
should be. Pretty much everything runs in a the "confined" user
domain, and that domain has all kinds of permissions a shell does not
need.

The level of confinement is determined by the boundaries. theres almost
no boundaries because there is no least privilege. E.g. most is just
allowed to run in the user domain. It just not unconfined (but it kind
of might as well be)

The proof is in the bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=1269072

SSH was running a lot of stuff in the wrong domain. but Fedora never
noticed it. Why? because the confined domain are so broad. (theres
little boundaries)

Even guest_t was allowed to "setexec"....

Sorry, but I have no faith in this couse of action. I am just
disappointed by the lack of vision.

> -- 
> Miroslav Grepl
> Senior Software Engineer, SELinux Solutions
> Red Hat, Inc.
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWYG41AAoJENAR6kfG5xmcrg0L/1zBmT9dwuVElvDbdFKlsqQ0
L3uhDKNWJwX/sHvmGKYI/fplzxP5kT+ME4/wmaeKnzNRszKpFkJkPeba2W6lxtYU
aPsKMxU48HpvEpKzMjr1Kb2eGaoQza955cn4Erppx7EHwLUzVXXR6rRyPIkLWfKI
gMwumRneWL72StzcX+lnANaoxwH6F+73OPbq2SmpKfwkkBJNENBbDzK+w1ZjNIpy
E18V0L2t2krwevn6Z0/p/idjnqoRukTLPAm/Zs1wLwQts0Cxcx0zKy7VoDXeozlo
GcMsL3IW6pyHDtJOvQ9gp1kRHx64B/6vdsgI2A994MEklWp7zPI6Fjxh3Vv9v/41
YGNOK8BvIdxgglcviFAu1b9Yp7hnatlRKdJM46eWovTQKmDk6IbwcafRMQw2wjyD
yr1mFap6I/5SzMfLBj1lcVSGIKvjM6gc5QAJh4YWSWQb5jq6MHlc0kdzXyj/EF/1
kusj4aIxy8k5FlmDzFJl6rQli+Hjf7B/JR4C5Yj4UQ==
=Fkf6
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Dec 03, 2015 at 05:30:49PM +0100, Dominick Grift wrote:
> On Thu, Dec 03, 2015 at 05:02:31PM +0100, Miroslav Grepl wrote:
> 

> no boundaries because there is no least privilege. E.g. most is just
> allowed to run in the user domain. It just not unconfined (but it kind
> of might as well be)
> 

Fedoras' confined domain are only there to protect the system from the
user, and the user from the system. It does not provide integrity in the
desktop, in the sense that applications are confined to any significant
extend.

if all applications run the in same user domain then, yes there will not
be any widely requirement for systemd --session access control becuase
theres nothing to control is everything runs in the same domain

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWYHnvAAoJENAR6kfG5xmcDscMAJA3evR/KWoVwaD2eZKFV2Mt
gNw31zE0Hdl6terZyyWqJmDMDH8Lyrzj2SbgTK+h4kXpu5lmxSLgU56KwIB024AE
28ObjOjnQNe/TdCifAG5vvSf4NRW4MnTO0zed9oGIHcQdjbWouWfODZP8aAgxc00
3MAH7Z9/sES3XjcIsBm+q4BI0TYi2mDCiM0HQskJMY7r71ldn5myUZOawme2rMPo
RquoMRwnPTa5iTzsjoK8ssISxwDJeX7WIMfQHz+oORi5Y0PLXrZE3I56Sr1b2JUm
Rj95mxvHpQM8WcSUSveOjVd29iNyAYD9EhAlVBrxrvMVNz/LHpgUyY+p3jm3FV+B
QFKtY42jqxTEwjuzoA3ZO3jJz6sZqrFMqYnKR7M04p7t1vFWu+uMWHL39yVc6mYp
mOMDH1vd/vif3omIpE6Ii6Fq5aGnXxWLtHi6GIldBh0a9FKVruGQC3Q/YMhXZQm2
gkJEeyAGQNv7j1V4yRs/w8laRwSTQE62MGvWKFvaGQ==
=Ixgi
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Dec 03, 2015 at 11:11:18AM -0500, 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?
> 

I think it is still (kind of) an issue. Here is some chatter about it:

https://github.com/fedora-selinux/selinux-policy/commit/7516138078d9c9048e49fe1abfa2a7dd85e3d14b#commitcomment-14376880

> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWYHwuAAoJENAR6kfG5xmcfLYL/jz36K9xpLqTKD8JgM/hYocD
hfxGq9wd89tLFX5Eg+bJrT1WAq9m0q2MMNT+JoEgPJWQw1eLGCEDd3ZejuSOrU8w
Mc2L3zZhbfxgQmIv8lsxsyN/a5miM9q5A2bdbmwIlbLPgW2Mwz/vTl1hTJm9bMqT
8+0tbwVz3+DAQHyY3G2jyMs9c2Q2U0yut2kAWzmkn0Z2W78PJwpdwUNNENqFUaxD
o3EKuO8XUP6aUuyrOWkH+WC5Z2TcvxQHYAq/8KheyjM+q9uqajpWmf30YRFDseSf
PjMVvnPuCtyaIHWHfOwFaedRQnqsvn7NmvpLfH+PNw4hvi0uBoocp3GB1O2wxnng
Om2hua1iWi3e7HizhP94bjU4AYsQJlgeWQKUW6Sak6Pmi/tCSbA1QPI/KkWhcftC
qeHFaZtzfLOwik4bcwkcvh0KdJjImTOlpsSLduBbmTIqUe8DohXCKJ+4S+STZtSI
62kW7RMi1fTlJf+brtlIiMVpB2E8fmuhanFM6T3cmg==
=0aRS
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 7678 bytes --]

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@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: continuation of systemd/SELinux discussion from Github

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Alright, as far as i am concerned this issue is resolved.

I think i kind of understand a bit now the rationale. Looks like i was
the one without vision.

What i want does not exist today. Because compatibility is a must. Looks
like there is some consensus that containers are going to be our
saviour. I suppose i will be migrating to Gnome so that i can enjoy the
privilege of xdg-app.

Maybe tomorrow we will have some security ... until then here's hoping

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWYbdgAAoJENAR6kfG5xmcjEEL/1/+xf9afAxYrijN9yVxXcPz
meTJm/GoJi9k4irqoBGS5rEyw7c9rp7VpQxD03WdaNh0t/dtPw2+Zalo2t7S7xkp
wT5DF6gZ/cjV+MivLJTHJ1E3mwDFqp2JAiL0pyKzF3aLOp0D5bwtEjneKqDg0hd3
xzQdJyrOi39zKcNCq4V1DT5xAs2zgALIlAD1EuAHp+nUSR5ZkRKQe6cMgR3fojAk
IEdNatnxHGmqZtxN4AM73rFQmQOBgA/EgP8FuuFQJBzaGcSfrZKAw+m3PEAqZ52a
jjMMgWobo/Vgu1iK7zGjv0fBQZ4cBVVn++zHWtVTIZz0rx5+RM5UeD1soOyit4tJ
SXu985RdmWFnnwGHccUYBSn3FJgPOZb+sBOaZtIvF0MVb+m+PM/nnXP1GPRRjaMH
jtTg4MXhnJeYKxrGVTrv29QfuRIPQnmgT9NsWf3BQRJt7kuNTkNRmxu8Ci8R4iQF
USseomXb/4hTQwRJ3IX999a/ntaDzWLxq1OzpbTEDg==
=wlp+
-----END PGP SIGNATURE-----

Re: continuation of systemd/SELinux discussion from Github

[Miroslav Grepl]

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.