Re: [RFC PATCH 0/8] systemd: improve SELinux support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Dec 19, 2019 at 03:24:34PM -0500, Chris PeBenito wrote:
> On 12/18/19 9:28 AM, Christian Göttsche wrote:
> > Improve the SELinux support in systemd, especially re-adding checks for
> > unit file operations, like enable, mask...
> > 
> > The original pull request can be found at https://github.com/systemd/systemd/pull/10023
> > 
> > Patch 1 and 2 improve logging on failures in permissive mode.
> > 
> > Patch 3 adds the ability to obtain the context for a masked unit.
> > 
> > Patch 4 and 5 change several system und service checks. For better
> > distinction two new permissions are introduced: modify and listdynusers.
> > 
> > Patch 6 and 7 re-introduce checking unit file install operations.
> > They were dropped in 8faae625dc9b6322db452937f54176e56e65265a .
> > For consistency in the unexpected case while perforimg a service access
> > check no path can be gathered, now the check will still be executed on
> > the service security class (currently it switches to the system security
> > class).
> > 
> > Patch 8 adds some notes for adding future D-Bus interfaces.
> 
> Thanks for working on this.  Just to make sure I didn't miss anything while
> reading the patches, there are no new permissions being added to the system
> class, correct?

This is what i understand:

Systemd first wants the regression fixed (re-add enable disable permission checks)
This phase should not add anything to the system class. It merely addresses a previous regression.
When that is done, then either the whole thing can be redone properly using policy capabilities, or we can add new permissions and in that scenario i guess the new permissions would be added to the existing system class (?).
If we redo the whole thing without interfering with the existing implementation then we can get rid of the system class usage for systemd.
One can opt in for the proper implementation by enabling the policy capability or otherwise one can stick with the current implementation.

> 
> -- 
> Chris PeBenito

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux