The reference policy is getting an increasing number of domains and types with
an O(N^2) level of complexity for writing policy and an O(N^2) size of the
binary policy. In 2012 the binary policy on my machines was 560k, now it's
over 2M.
In recent policy we have 6 different domains for systemd-generators. What
benefit are we expecting to get from this? Are we anticipating that one
generator will attack another? How would having separate domains for
generators do any good when there's no restriction on the contents of the
files they generate and nothing to prevent one generator from creating a file
of the name that another generator is expected to create? Is it even
reasonable to expect that a program that can create a systemd unit file with
arbitrary content (IE being able to start any daemon with arbitrary
configuration and command-line parameters) would be unable to exploit that for
unrestricted root access?
We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for?
Is someone using the X controls and in need of a privileged window manager
domain to manage the clipboard etc? Why is staff_wm_t needed when we no
longer have staff_gpg_t? Does staff_r even make sense when you could just use
different MCS categories for different users?
We have one games_t domain for games which were packaged by the distribution.
Is this possible to give a useful benefit given that they some games the same
XDG config directories as more important things. If a game has the file
access needed to grab passwords from your MUA and network access to send them
out then is there a real benefit in having a separate domain for it? As an
aside I think that the ideal thing to do would be to have a SETGID program to
manage passwords for email etc that prevents the user from accessing them, it
could then proxy IMAP/SMTP connections so the MUA never knows the real
passwords.
We have special *_cronjob_t domains which in systems that use them (IE not
Debian) seem to give the potential for nothing but confusion. The general
expectation is that anything which can run as a user login session can also
run as a cron job. What benefit is this expected to provide?
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On 12.6.2020 3.03, Russell Coker wrote:
> The reference policy is getting an increasing number of domains and types with
> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
> binary policy. In 2012 the binary policy on my machines was 560k, now it's
> over 2M.
The policy can be shrunk by disabling unused modules, mine is 760k
because only 166 modules are enabled out of 506. Some of the modules are
for more or less obsolete software (e.g. hal, rlogin, uucp), or they may
target proprietary software, which may be of unknown relevance today.
Perhaps they should be disabled by default, removed from refpolicy or
moved aside to directory "extra" or "Attic"?
The package installer could also propose groups like "all", "most",
"recommended", "distro-only" (disable all 3rd party stuff), "minimal" to
enable/disable modules.
-Topi
On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <[email protected]> wrote:
>
> The reference policy is getting an increasing number of domains and types with
> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
> binary policy. In 2012 the binary policy on my machines was 560k, now it's
> over 2M.
The number of domains available by default should not be a problem if
you can easily select which modules you want to use.
with module policy this is not as easy as with CIL as the modular
nature of module policy makes it harder to resolve dependencies
(almost impractical). The human readable nature of CIL and iits "feels
like modular but is really just monolithic" nature makes dependency
resolving at runtime with CIL generall much easier (but there are
still limitations).
>
> In recent policy we have 6 different domains for systemd-generators. What
> benefit are we expecting to get from this? Are we anticipating that one
> generator will attack another? How would having separate domains for
> generators do any good when there's no restriction on the contents of the
> files they generate and nothing to prevent one generator from creating a file
> of the name that another generator is expected to create? Is it even
> reasonable to expect that a program that can create a systemd unit file with
> arbitrary content (IE being able to start any daemon with arbitrary
> configuration and command-line parameters) would be unable to exploit that for
> unrestricted root access?
>
When push comes to shove, generators are just short-running services
(ie its code run by systemd) generally (unit) generators do some
enumeration and then create a runtime unit accordingly.but there have
already been instances where this functionality has been "abused" (the
dbus -> dbus-broker migration in fedora). In the end though, it might
not be worth the trouble to target them. If you're allowed to write to
the systemd runtime generator dir then you can drop a script , run
systemd daemon-reload, and systemd will run that code.
> We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for?
> Is someone using the X controls and in need of a privileged window manager
> domain to manage the clipboard etc? Why is staff_wm_t needed when we no
> longer have staff_gpg_t? Does staff_r even make sense when you could just use
> different MCS categories for different users?
I suppose it's a generic domain for window managers. It originates
from the metacity day's Things changed quite a bit since then (think
wayland compositors)
The derived types concept, originallly, i think, tackled the scenario
where something needs to run either a shell or a cmmand on behalf of
the caller and still run with private rules. This was quite an isssue
in the recent past (for example pulseaudio clients would run
pulseaudio on demand, pulse audio would run dbus on demand (i believe)
and dbus would run potentially anything on demand (dbus activated
services). So there was a dependency chain there to ensure some
consistency.
Nowaday/s thats all gone, pulseaudio is systemd socket activated, dbus
is system socket activated, and dbus activation is really just dbus
telling systemd to start something (rather than dbus running the dbus
activated command itself)
Another side effect of derived types is that it can be used for
isolation of users sessions. Nowaday's roles can be used for this.
Derived types, in practice, are bad because you cannot declare types
reliably in optional policy. In effect that means that you cannot
reliably use derived types for types that may be optional.
>
> We have one games_t domain for games which were packaged by the distribution.
> Is this possible to give a useful benefit given that they some games the same
> XDG config directories as more important things. If a game has the file
> access needed to grab passwords from your MUA and network access to send them
> out then is there a real benefit in having a separate domain for it? As an
> aside I think that the ideal thing to do would be to have a SETGID program to
> manage passwords for email etc that prevents the user from accessing them, it
> could then proxy IMAP/SMTP connections so the MUA never knows the real
> passwords.
That's generalizing.
But as for games. Today things like flatpak might be more suitable.
Then you can combine SELinux and other kernel tech like namespaces,
bind mounts to make stuff inaccessible etc. Theres also steam which
essentially is a dumb version of flatpak. I don't think steam would
ever need any access to a MUA and any of its assets
>
> We have special *_cronjob_t domains which in systems that use them (IE not
> Debian) seem to give the potential for nothing but confusion. The general
> expectation is that anything which can run as a user login session can also
> run as a cron job. What benefit is this expected to provide?
the derived cronjob domains (with the exception of system_cronjob_t)
are conditional. This functionality can be tuned and i think it's
disabled by default.
There will always be legacy to carry, things change all the time. It
is give and take. I don't think refpolicy has much of a future to
forward to but not for the reasons above.
module policy and monolithic policy are just too limited compared to
CIL, and refpolicy has some designs centered around things that just
don't work (think about the derived types limitation i mentioned above
and how that is rooted to the core in refpolicy (example staff_dbusd_t
and the dbus_role_template effectively make dbus a hard dependency
(effectively nowaday's it is) but this also means that no dbus role
templates (and this any dbus interfaces) should ever be in optional
blocks
DSSP3 is my vision of what a modern policy should look like (except
that it doesn't support enforcement of confidentiality)
Eventually though DSSP3 will grow legacy just like refpolicy, I do not
pretend otherwise.
But a lot has changed and DSSP3 took the opportunity to rebuild for the new new.
Also with DSSP3 i learned from the bloat lesson. DSSP3 itself is
intentionally kept small and concise.I acknowledge that policy has to
be maintained over time and so if you limit yourself to a relatively
small set of types/roes/id etc and you focus on the quality of that
then you make life easier.
I do have a "DSSP3 constrib" and this repository can and will has as
many modules as needed (of course the quality of those modules cannot
be vouched for) but they're all optional and self-contained (to the
extent possible)
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
>
>
On Friday, 12 June 2020 6:02:15 PM AEST Dac Override wrote:
> On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <[email protected]> wrote:
> > The reference policy is getting an increasing number of domains and types
> > with an O(N^2) level of complexity for writing policy and an O(N^2) size
> > of the binary policy. In 2012 the binary policy on my machines was 560k,
> > now it's over 2M.
>
> The number of domains available by default should not be a problem if
> you can easily select which modules you want to use.
> with module policy this is not as easy as with CIL as the modular
> nature of module policy makes it harder to resolve dependencies
> (almost impractical). The human readable nature of CIL and iits "feels
> like modular but is really just monolithic" nature makes dependency
> resolving at runtime with CIL generall much easier (but there are
> still limitations).
As Topi noted there are ways of reducing the binary size. But that was the
minor part of my message.
> > In recent policy we have 6 different domains for systemd-generators. What
> > benefit are we expecting to get from this? Are we anticipating that one
> > generator will attack another? How would having separate domains for
> > generators do any good when there's no restriction on the contents of the
> > files they generate and nothing to prevent one generator from creating a
> > file of the name that another generator is expected to create? Is it
> > even reasonable to expect that a program that can create a systemd unit
> > file with arbitrary content (IE being able to start any daemon with
> > arbitrary configuration and command-line parameters) would be unable to
> > exploit that for unrestricted root access?
>
> When push comes to shove, generators are just short-running services
> (ie its code run by systemd) generally (unit) generators do some
> enumeration and then create a runtime unit accordingly.but there have
> already been instances where this functionality has been "abused" (the
> dbus -> dbus-broker migration in fedora). In the end though, it might
> not be worth the trouble to target them. If you're allowed to write to
> the systemd runtime generator dir then you can drop a script , run
> systemd daemon-reload, and systemd will run that code.
Yes.
I just did some policy searches and found the following allowing access to
init_runtime_t. This probably isn't what we want.
allow ftpd_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ allow_ftpd_full_access ]:True
allow nfsd_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ nfs_export_all_rw ]:True
allow nmbd_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ samba_export_all_rw ]:True
allow puppet_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ puppet_manage_all_files ]:True
allow sftpd_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ sftpd_full_access ]:True
allow smbd_t non_auth_file_type:file { append create getattr ioctl link lock
open read rename setattr unlink write }; [ samba_export_all_rw ]:True
> > We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that
> > for? Is someone using the X controls and in need of a privileged window
> > manager domain to manage the clipboard etc? Why is staff_wm_t needed
> > when we no longer have staff_gpg_t? Does staff_r even make sense when
> > you could just use different MCS categories for different users?
>
> I suppose it's a generic domain for window managers. It originates
> from the metacity day's Things changed quite a bit since then (think
> wayland compositors)
Are you saying we should remove the staff_wm_t?
> The derived types concept, originallly, i think, tackled the scenario
> where something needs to run either a shell or a cmmand on behalf of
> the caller and still run with private rules. This was quite an isssue
> in the recent past (for example pulseaudio clients would run
> pulseaudio on demand, pulse audio would run dbus on demand (i believe)
> and dbus would run potentially anything on demand (dbus activated
> services). So there was a dependency chain there to ensure some
> consistency.
>
> Nowaday/s thats all gone, pulseaudio is systemd socket activated, dbus
> is system socket activated, and dbus activation is really just dbus
> telling systemd to start something (rather than dbus running the dbus
> activated command itself)
That sounds great, we can remove a bunch of policy for dbus stuff then.
> Another side effect of derived types is that it can be used for
> isolation of users sessions. Nowaday's roles can be used for this.
I think roles could have always been used for that. But adding lots of roles
used to be a lot easier.
So I guess we could have 3 base domains for users, user_t, sysadm_t, and
unconfined_t. We could then have roles user_r and staff_r both suitable for
user_t and similar domains and have unconfined_r and sysadm_r for unconfined_t
and sysadm_t respectively.
Another possibility would be to remove unconfined_r, have sysadm_r:sysadm_t be
for unconfinbed users, it will be literally unconfined if the unconfined
module is installed and just like sysadm_t is now otherwise.
> Derived types, in practice, are bad because you cannot declare types
> reliably in optional policy. In effect that means that you cannot
> reliably use derived types for types that may be optional.
>
> > We have one games_t domain for games which were packaged by the
> > distribution. Is this possible to give a useful benefit given that they
> > some games the same XDG config directories as more important things. If
> > a game has the file access needed to grab passwords from your MUA and
> > network access to send them out then is there a real benefit in having a
> > separate domain for it? As an aside I think that the ideal thing to do
> > would be to have a SETGID program to manage passwords for email etc that
> > prevents the user from accessing them, it could then proxy IMAP/SMTP
> > connections so the MUA never knows the real passwords.
>
> That's generalizing.
We are trying to write policy that is generally usable.
> But as for games. Today things like flatpak might be more suitable.
> Then you can combine SELinux and other kernel tech like namespaces,
> bind mounts to make stuff inaccessible etc. Theres also steam which
> essentially is a dumb version of flatpak. I don't think steam would
> ever need any access to a MUA and any of its assets
Steam needs full network access, graphics, sound, and XDG directory access.
> > We have special *_cronjob_t domains which in systems that use them (IE not
> > Debian) seem to give the potential for nothing but confusion. The general
> > expectation is that anything which can run as a user login session can
> > also
> > run as a cron job. What benefit is this expected to provide?
>
> the derived cronjob domains (with the exception of system_cronjob_t)
> are conditional. This functionality can be tuned and i think it's
> disabled by default.
>
> There will always be legacy to carry, things change all the time. It
> is give and take. I don't think refpolicy has much of a future to
> forward to but not for the reasons above.
If the reasons I listed are a sufficient disincentive to contributing towards
the refpolicy then it can limit the future of refpolicy.
Things currently aren't working well. I'm thinking of just making changes
similar to what I describe above and letting refpolicy upstream decide whether
they want to do something compatible or whether we go separate ways.
> module policy and monolithic policy are just too limited compared to
> CIL, and refpolicy has some designs centered around things that just
> don't work (think about the derived types limitation i mentioned above
> and how that is rooted to the core in refpolicy (example staff_dbusd_t
> and the dbus_role_template effectively make dbus a hard dependency
> (effectively nowaday's it is) but this also means that no dbus role
> templates (and this any dbus interfaces) should ever be in optional
> blocks
We can change some of these things.
> DSSP3 is my vision of what a modern policy should look like (except
> that it doesn't support enforcement of confidentiality)
> Eventually though DSSP3 will grow legacy just like refpolicy, I do not
> pretend otherwise.
> But a lot has changed and DSSP3 took the opportunity to rebuild for the new
> new.
>
> Also with DSSP3 i learned from the bloat lesson. DSSP3 itself is
> intentionally kept small and concise.I acknowledge that policy has to
> be maintained over time and so if you limit yourself to a relatively
> small set of types/roes/id etc and you focus on the quality of that
> then you make life easier.
>
> I do have a "DSSP3 constrib" and this repository can and will has as
> many modules as needed (of course the quality of those modules cannot
> be vouched for) but they're all optional and self-contained (to the
> extent possible)
Sounds interesting.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> writes:
> On Friday, 12 June 2020 6:02:15 PM AEST Dac Override wrote:
>> On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <[email protected]> wrote:
>> > The reference policy is getting an increasing number of domains and types
>> > with an O(N^2) level of complexity for writing policy and an O(N^2) size
>> > of the binary policy. In 2012 the binary policy on my machines was 560k,
>> > now it's over 2M.
>>
>> The number of domains available by default should not be a problem if
>> you can easily select which modules you want to use.
>> with module policy this is not as easy as with CIL as the modular
>> nature of module policy makes it harder to resolve dependencies
>> (almost impractical). The human readable nature of CIL and iits "feels
>> like modular but is really just monolithic" nature makes dependency
>> resolving at runtime with CIL generall much easier (but there are
>> still limitations).
>
> As Topi noted there are ways of reducing the binary size. But that was the
> minor part of my message.
>
What was the main part of your message than? The complexity involved
with removing modules you do not need in any given configuration?
>> > In recent policy we have 6 different domains for systemd-generators. What
>> > benefit are we expecting to get from this? Are we anticipating that one
>> > generator will attack another? How would having separate domains for
>> > generators do any good when there's no restriction on the contents of the
>> > files they generate and nothing to prevent one generator from creating a
>> > file of the name that another generator is expected to create? Is it
>> > even reasonable to expect that a program that can create a systemd unit
>> > file with arbitrary content (IE being able to start any daemon with
>> > arbitrary configuration and command-line parameters) would be unable to
>> > exploit that for unrestricted root access?
>>
>> When push comes to shove, generators are just short-running services
>> (ie its code run by systemd) generally (unit) generators do some
>> enumeration and then create a runtime unit accordingly.but there have
>> already been instances where this functionality has been "abused" (the
>> dbus -> dbus-broker migration in fedora). In the end though, it might
>> not be worth the trouble to target them. If you're allowed to write to
>> the systemd runtime generator dir then you can drop a script , run
>> systemd daemon-reload, and systemd will run that code.
>
> Yes.
>
> I just did some policy searches and found the following allowing access to
> init_runtime_t. This probably isn't what we want.
>
> allow ftpd_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ allow_ftpd_full_access ]:True
> allow nfsd_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ nfs_export_all_rw ]:True
> allow nmbd_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ samba_export_all_rw ]:True
> allow puppet_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ puppet_manage_all_files ]:True
> allow sftpd_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ sftpd_full_access ]:True
> allow smbd_t non_auth_file_type:file { append create getattr ioctl link lock
> open read rename setattr unlink write }; [ samba_export_all_rw ]:True
>
>> > We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that
>> > for? Is someone using the X controls and in need of a privileged window
>> > manager domain to manage the clipboard etc? Why is staff_wm_t needed
>> > when we no longer have staff_gpg_t? Does staff_r even make sense when
>> > you could just use different MCS categories for different users?
>>
>> I suppose it's a generic domain for window managers. It originates
>> from the metacity day's Things changed quite a bit since then (think
>> wayland compositors)
>
> Are you saying we should remove the staff_wm_t?
I am just sharing my knowledge. I will leave that decision to others.
>
>> The derived types concept, originallly, i think, tackled the scenario
>> where something needs to run either a shell or a cmmand on behalf of
>> the caller and still run with private rules. This was quite an isssue
>> in the recent past (for example pulseaudio clients would run
>> pulseaudio on demand, pulse audio would run dbus on demand (i believe)
>> and dbus would run potentially anything on demand (dbus activated
>> services). So there was a dependency chain there to ensure some
>> consistency.
>>
>> Nowaday/s thats all gone, pulseaudio is systemd socket activated, dbus
>> is system socket activated, and dbus activation is really just dbus
>> telling systemd to start something (rather than dbus running the dbus
>> activated command itself)
>
> That sounds great, we can remove a bunch of policy for dbus stuff then.
>
>> Another side effect of derived types is that it can be used for
>> isolation of users sessions. Nowaday's roles can be used for this.
>
> I think roles could have always been used for that. But adding lots of roles
> used to be a lot easier.
No, the defaultrole functionality is relatively new.
>
> So I guess we could have 3 base domains for users, user_t, sysadm_t, and
> unconfined_t. We could then have roles user_r and staff_r both suitable for
> user_t and similar domains and have unconfined_r and sysadm_r for unconfined_t
> and sysadm_t respectively.
>
> Another possibility would be to remove unconfined_r, have sysadm_r:sysadm_t be
> for unconfinbed users, it will be literally unconfined if the unconfined
> module is installed and just like sysadm_t is now otherwise.
>
In dssp3 I take this to another level. The concept of exemption is
embraced, and the need for trust is acknowledged (yes that one was tough to swallow).
There is no unconfined_t in dssp3. there is just "the system" and "the
system" is trusted and exempted. This simplifies the policy a great deal
since there isn't a number of unconfined domains by default, there is
just one trusted context by default (you can still make additional
domains unconfined but that is discouraged)
>> Derived types, in practice, are bad because you cannot declare types
>> reliably in optional policy. In effect that means that you cannot
>> reliably use derived types for types that may be optional.
>>
>> > We have one games_t domain for games which were packaged by the
>> > distribution. Is this possible to give a useful benefit given that they
>> > some games the same XDG config directories as more important things. If
>> > a game has the file access needed to grab passwords from your MUA and
>> > network access to send them out then is there a real benefit in having a
>> > separate domain for it? As an aside I think that the ideal thing to do
>> > would be to have a SETGID program to manage passwords for email etc that
>> > prevents the user from accessing them, it could then proxy IMAP/SMTP
>> > connections so the MUA never knows the real passwords.
>>
>> That's generalizing.
>
> We are trying to write policy that is generally usable.
I dont think games should have access to MUA
>
>> But as for games. Today things like flatpak might be more suitable.
>> Then you can combine SELinux and other kernel tech like namespaces,
>> bind mounts to make stuff inaccessible etc. Theres also steam which
>> essentially is a dumb version of flatpak. I don't think steam would
>> ever need any access to a MUA and any of its assets
>
> Steam needs full network access, graphics, sound, and XDG directory access.
Yes but you were using "passwords" as an argument and then some how put
MUA into the equation (I honestly have no clue why a game would need
access to a MUA). Not to mention that when it comes to passwords (and to authentication) there are better
way's to secure access. Think for example smartcards, TFA, encryption, etc.
>
>> > We have special *_cronjob_t domains which in systems that use them (IE not
>> > Debian) seem to give the potential for nothing but confusion. The general
>> > expectation is that anything which can run as a user login session can
>> > also
>> > run as a cron job. What benefit is this expected to provide?
>>
>> the derived cronjob domains (with the exception of system_cronjob_t)
>> are conditional. This functionality can be tuned and i think it's
>> disabled by default.
>>
>> There will always be legacy to carry, things change all the time. It
>> is give and take. I don't think refpolicy has much of a future to
>> forward to but not for the reasons above.
>
> If the reasons I listed are a sufficient disincentive to contributing towards
> the refpolicy then it can limit the future of refpolicy.
>
> Things currently aren't working well. I'm thinking of just making changes
> similar to what I describe above and letting refpolicy upstream decide whether
> they want to do something compatible or whether we go separate ways.
>
>> module policy and monolithic policy are just too limited compared to
>> CIL, and refpolicy has some designs centered around things that just
>> don't work (think about the derived types limitation i mentioned above
>> and how that is rooted to the core in refpolicy (example staff_dbusd_t
>> and the dbus_role_template effectively make dbus a hard dependency
>> (effectively nowaday's it is) but this also means that no dbus role
>> templates (and this any dbus interfaces) should ever be in optional
>> blocks
>
> We can change some of these things.
I guess the question is whether it is worth the investment. I will leave
that decision to others.
>
>> DSSP3 is my vision of what a modern policy should look like (except
>> that it doesn't support enforcement of confidentiality)
>> Eventually though DSSP3 will grow legacy just like refpolicy, I do not
>> pretend otherwise.
>> But a lot has changed and DSSP3 took the opportunity to rebuild for the new
>> new.
>>
>> Also with DSSP3 i learned from the bloat lesson. DSSP3 itself is
>> intentionally kept small and concise.I acknowledge that policy has to
>> be maintained over time and so if you limit yourself to a relatively
>> small set of types/roes/id etc and you focus on the quality of that
>> then you make life easier.
>>
>> I do have a "DSSP3 constrib" and this repository can and will has as
>> many modules as needed (of course the quality of those modules cannot
>> be vouched for) but they're all optional and self-contained (to the
>> extent possible)
>
> Sounds interesting.
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
Hi, Russell,
I am a novice in SELinux, even though I am learning it for a year or so.
And I can't really understand why SELinux is SO complex. Not only the
policy, but the whole SELinux.
For example, there are two different ways of writing a policy - CIL and
the other one. And they have conflicting namesets (typeattribute =
atttribute). At the same time, this behavior is just slightly
documented. One can't create a policy only using information from docs.
At the same time, some parts of SELinux are very unstable. Like, MCS. It
was introduced and it is used only for VM management. And mcstransd is
bad. It's really bad. I was trying to use it and it was totally
unstable. So, even if someone wants to use MCS - it is almost impossible
because tools are unstable and MCS is already almost exclusively used by
VMs.
On 12.06.20 02:03, Russell Coker wrote:
> The reference policy is getting an increasing number of domains and types with
> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
> binary policy. In 2012 the binary policy on my machines was 560k, now it's
> over 2M.
>
> In recent policy we have 6 different domains for systemd-generators. What
> benefit are we expecting to get from this? Are we anticipating that one
> generator will attack another? How would having separate domains for
> generators do any good when there's no restriction on the contents of the
> files they generate and nothing to prevent one generator from creating a file
> of the name that another generator is expected to create? Is it even
> reasonable to expect that a program that can create a systemd unit file with
> arbitrary content (IE being able to start any daemon with arbitrary
> configuration and command-line parameters) would be unable to exploit that for
> unrestricted root access?
>
> We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for?
> Is someone using the X controls and in need of a privileged window manager
> domain to manage the clipboard etc? Why is staff_wm_t needed when we no
> longer have staff_gpg_t? Does staff_r even make sense when you could just use
> different MCS categories for different users?
>
> We have one games_t domain for games which were packaged by the distribution.
> Is this possible to give a useful benefit given that they some games the same
> XDG config directories as more important things. If a game has the file
> access needed to grab passwords from your MUA and network access to send them
> out then is there a real benefit in having a separate domain for it? As an
> aside I think that the ideal thing to do would be to have a SETGID program to
> manage passwords for email etc that prevents the user from accessing them, it
> could then proxy IMAP/SMTP connections so the MUA never knows the real
> passwords.
>
> We have special *_cronjob_t domains which in systems that use them (IE not
> Debian) seem to give the potential for nothing but confusion. The general
> expectation is that anything which can run as a user login session can also
> run as a cron job. What benefit is this expected to provide?
>
--
Regards, Denis Obrezkov
On Friday, 12 June 2020 9:00:05 PM AEST Denis Obrezkov wrote:
> At the same time, some parts of SELinux are very unstable. Like, MCS. It
> was introduced and it is used only for VM management. And mcstransd is
> bad. It's really bad. I was trying to use it and it was totally
> unstable. So, even if someone wants to use MCS - it is almost impossible
> because tools are unstable and MCS is already almost exclusively used by
> VMs.
Systemd has the ability to dynamically create and manage UIDs. It could do
the same with MCS categories. Having systemd manage multiple daemons doing
similar tasks with either MCS categories or the other systemd mechanisms
(namespaces etc) used to isolate them instead of different types is something
we could do. There are a heap of daemons that use a TCP or UDP socket, write
to logs, and maintain a data store (database server, proxy server, dhcp
server, and samba all look fairly similar from a certain perspective), having
an entirely separate policy for each one doesn't seem useful.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Denis Obrezkov <[email protected]> writes:
> Hi, Russell,
Not Russell but allow me...
>
> I am a novice in SELinux, even though I am learning it for a year or so.
> And I can't really understand why SELinux is SO complex. Not only the
> policy, but the whole SELinux.
In time i've learned to appreciate the simplicity and elegance of
SELinux given the tasks it accomplishes. I acknowledge that it may take
some time for one to see that "light".
> For example, there are two different ways of writing a policy - CIL and
There are actually 4 different way's of writing a policy. It's
evolution.
1. Monolitic policy
2. Modular policy
3. Reference policy
4. Common Intermediate Language
> the other one. And they have conflicting namesets (typeattribute =
> atttribute). At the same time, this behavior is just slightly
> documented. One can't create a policy only using information from docs.
I suspect that when the "attribute" statement was created no one had
foreseen that we eventually would end up with not just a "type
attribute" but also with a "user" and "role' "attribute". CIL merely
corrected this by renaming it all in a more consistent way where the
existing languages were unable to rename it for compatibility reasons:
CIL:
1. typeattribute
2. roleattribute
3. userattribute
Old:
1. attribute
2. attribute_role
3. (not even sure is user attributes are supported in anything but CIL)
> At the same time, some parts of SELinux are very unstable. Like, MCS. It
Creating a policy (from scratch) is indeed not very well documented
AFAIK. There is however a script in the kernel documentation tree called
MDP that creates a simple policy. This script can be used to get at
least some idea of what it takes to write a policy.
> was introduced and it is used only for VM management. And mcstransd is
Not everyone will agree with me probably but to me MCS was alway's a
"hack" to make some use of MLS in systems that do not enforce
confidentiality. The term hack here is meant in a good way: to highlight
how flexible SELinux is.
MCS also evolved over time, and eventually I think the current
implementation of this "hack" is the most useful. It may (or may not)
by known as "SVIRT" but really its just a technique to use the
compartments of MLS to accomplish seperation and the use case for this
is actually broader than you may think. The usuability of MCS might also
be easier than you think. I played with MCS just the other day to
separate python web application containers with gunicorn/django and
systemd/systemd-portable and it just works for me.
No need for mcstransd. mcstransd is really only used in some MLS
environments where the levels need to be human readable. This is not a
requirement for common MCS seperation. mcstransd just adds overhead.
> bad. It's really bad. I was trying to use it and it was totally
> unstable. So, even if someone wants to use MCS - it is almost impossible
> because tools are unstable and MCS is already almost exclusively used by
> VMs.
>
> On 12.06.20 02:03, Russell Coker wrote:
>> The reference policy is getting an increasing number of domains and types with
>> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
>> binary policy. In 2012 the binary policy on my machines was 560k, now it's
>> over 2M.
>>
>> In recent policy we have 6 different domains for systemd-generators. What
>> benefit are we expecting to get from this? Are we anticipating that one
>> generator will attack another? How would having separate domains for
>> generators do any good when there's no restriction on the contents of the
>> files they generate and nothing to prevent one generator from creating a file
>> of the name that another generator is expected to create? Is it even
>> reasonable to expect that a program that can create a systemd unit file with
>> arbitrary content (IE being able to start any daemon with arbitrary
>> configuration and command-line parameters) would be unable to exploit that for
>> unrestricted root access?
>>
>> We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for?
>> Is someone using the X controls and in need of a privileged window manager
>> domain to manage the clipboard etc? Why is staff_wm_t needed when we no
>> longer have staff_gpg_t? Does staff_r even make sense when you could just use
>> different MCS categories for different users?
>>
>> We have one games_t domain for games which were packaged by the distribution.
>> Is this possible to give a useful benefit given that they some games the same
>> XDG config directories as more important things. If a game has the file
>> access needed to grab passwords from your MUA and network access to send them
>> out then is there a real benefit in having a separate domain for it? As an
>> aside I think that the ideal thing to do would be to have a SETGID program to
>> manage passwords for email etc that prevents the user from accessing them, it
>> could then proxy IMAP/SMTP connections so the MUA never knows the real
>> passwords.
>>
>> We have special *_cronjob_t domains which in systems that use them (IE not
>> Debian) seem to give the potential for nothing but confusion. The general
>> expectation is that anything which can run as a user login session can also
>> run as a cron job. What benefit is this expected to provide?
>>
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote:
> What was the main part of your message than? The complexity involved
> with removing modules you do not need in any given configuration?
The difficulty in managing it all and the limited benefit in trying to do it.
> >> I suppose it's a generic domain for window managers. It originates
> >> from the metacity day's Things changed quite a bit since then (think
> >> wayland compositors)
> >
> > Are you saying we should remove the staff_wm_t?
>
> I am just sharing my knowledge. I will leave that decision to others.
To know how something it works is to know whether it works well enough or
should be improved.
> > I think roles could have always been used for that. But adding lots of
> > roles used to be a lot easier.
>
> No, the defaultrole functionality is relatively new.
Before modular policy when the entire policy was compiled in m4 on every
system it was very easy to change roles.
> > So I guess we could have 3 base domains for users, user_t, sysadm_t, and
> > unconfined_t. We could then have roles user_r and staff_r both suitable
> > for user_t and similar domains and have unconfined_r and sysadm_r for
> > unconfined_t and sysadm_t respectively.
> >
> > Another possibility would be to remove unconfined_r, have
> > sysadm_r:sysadm_t be for unconfinbed users, it will be literally
> > unconfined if the unconfined module is installed and just like sysadm_t
> > is now otherwise.
>
> In dssp3 I take this to another level. The concept of exemption is
> embraced, and the need for trust is acknowledged (yes that one was tough to
> swallow).
>
> There is no unconfined_t in dssp3. there is just "the system" and "the
> system" is trusted and exempted. This simplifies the policy a great deal
> since there isn't a number of unconfined domains by default, there is
> just one trusted context by default (you can still make additional
> domains unconfined but that is discouraged)
So you have init, getty, and syslogd all running in the same context?
https://en.wikipedia.org/wiki/Biba_Model
I've been considering how we might make a usable system that includes Biba.
> >> > We have one games_t domain for games which were packaged by the
> >> > distribution. Is this possible to give a useful benefit given that they
> >> > some games the same XDG config directories as more important things.
> >> > If
> >> > a game has the file access needed to grab passwords from your MUA and
> >> > network access to send them out then is there a real benefit in having
> >> > a
> >> > separate domain for it? As an aside I think that the ideal thing to do
> >> > would be to have a SETGID program to manage passwords for email etc
> >> > that
> >> > prevents the user from accessing them, it could then proxy IMAP/SMTP
> >> > connections so the MUA never knows the real passwords.
> >>
> >> That's generalizing.
> >
> > We are trying to write policy that is generally usable.
>
> I dont think games should have access to MUA
Yes. But if we have game data stored in the same places as MUA data then it
happens. A policy to make warzone2100 work in Debian allows games_t to access
MUA data.
> >> But as for games. Today things like flatpak might be more suitable.
> >> Then you can combine SELinux and other kernel tech like namespaces,
> >> bind mounts to make stuff inaccessible etc. Theres also steam which
> >> essentially is a dumb version of flatpak. I don't think steam would
> >> ever need any access to a MUA and any of its assets
> >
> > Steam needs full network access, graphics, sound, and XDG directory
> > access.
>
> Yes but you were using "passwords" as an argument and then some how put
> MUA into the equation (I honestly have no clue why a game would need
> access to a MUA). Not to mention that when it comes to passwords (and to
> authentication) there are better way's to secure access. Think for example
> smartcards, TFA, encryption, etc.
What's a good way of setting up TFA with IMAP on both client and server? With
most systems that have TFA you have a single password for IMAP and TFA for the
management (changing calendar, plugins, etc).
If MUA is too controversial I could find some other example of something under
~/.local that games probably shouldn't access.
> >> module policy and monolithic policy are just too limited compared to
> >> CIL, and refpolicy has some designs centered around things that just
> >> don't work (think about the derived types limitation i mentioned above
> >> and how that is rooted to the core in refpolicy (example staff_dbusd_t
> >> and the dbus_role_template effectively make dbus a hard dependency
> >> (effectively nowaday's it is) but this also means that no dbus role
> >> templates (and this any dbus interfaces) should ever be in optional
> >> blocks
> >
> > We can change some of these things.
>
> I guess the question is whether it is worth the investment. I will leave
> that decision to others.
I think the decision might be whether it's worth continuing to maintain
refpolicy or whether it should be obsoleted.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> writes:
> On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote:
>> What was the main part of your message than? The complexity involved
>> with removing modules you do not need in any given configuration?
>
> The difficulty in managing it all and the limited benefit in trying to do it.
Yes, Its a bit easier with CIL policy and maybe could even be automated
in an environment that leverages CIL (although not sure if that would be worth the overhead)
>
>> >> I suppose it's a generic domain for window managers. It originates
>> >> from the metacity day's Things changed quite a bit since then (think
>> >> wayland compositors)
>> >
>> > Are you saying we should remove the staff_wm_t?
>>
>> I am just sharing my knowledge. I will leave that decision to others.
>
> To know how something it works is to know whether it works well enough or
> should be improved.
>
I think its subjective.
Maybe there no longer is a need to derive wm_t. We would need to
identity why wm_t was derived in the first place.
Maybe its worth it to make a distinction between X window managers and
Wayland window managers (although its not as simple i guess due to the
Xwayland compatibility layer)
I guess I will just admit that I don't feel qualified to answer this question.
>> > I think roles could have always been used for that. But adding lots of
>> > roles used to be a lot easier.
>>
>> No, the defaultrole functionality is relatively new.
>
> Before modular policy when the entire policy was compiled in m4 on every
> system it was very easy to change roles.
>
That was before my time (at least I cannot remember), but I have my
doubts.
>> > So I guess we could have 3 base domains for users, user_t, sysadm_t, and
>> > unconfined_t. We could then have roles user_r and staff_r both suitable
>> > for user_t and similar domains and have unconfined_r and sysadm_r for
>> > unconfined_t and sysadm_t respectively.
>> >
>> > Another possibility would be to remove unconfined_r, have
>> > sysadm_r:sysadm_t be for unconfinbed users, it will be literally
>> > unconfined if the unconfined module is installed and just like sysadm_t
>> > is now otherwise.
>>
>> In dssp3 I take this to another level. The concept of exemption is
>> embraced, and the need for trust is acknowledged (yes that one was tough to
>> swallow).
>>
>> There is no unconfined_t in dssp3. there is just "the system" and "the
>> system" is trusted and exempted. This simplifies the policy a great deal
>> since there isn't a number of unconfined domains by default, there is
>> just one trusted context by default (you can still make additional
>> domains unconfined but that is discouraged)
>
> So you have init, getty, and syslogd all running in the same context?
Stuff that runs in "the system" context (is trusted): sys.id:sys.role:sys.isid:s0
1. systemd --system (pid1)
2. systemd-tmpfiles --system
3. dbus --system
4. default login shells
5. package managers
6. unknown system services
(i might have overlooked some)
>
> https://en.wikipedia.org/wiki/Biba_Model
>
> I've been considering how we might make a usable system that includes Biba.
>
>> >> > We have one games_t domain for games which were packaged by the
>> >> > distribution. Is this possible to give a useful benefit given that they
>> >> > some games the same XDG config directories as more important things.
>> >> > If
>> >> > a game has the file access needed to grab passwords from your MUA and
>> >> > network access to send them out then is there a real benefit in having
>> >> > a
>> >> > separate domain for it? As an aside I think that the ideal thing to do
>> >> > would be to have a SETGID program to manage passwords for email etc
>> >> > that
>> >> > prevents the user from accessing them, it could then proxy IMAP/SMTP
>> >> > connections so the MUA never knows the real passwords.
>> >>
>> >> That's generalizing.
>> >
>> > We are trying to write policy that is generally usable.
>>
>> I dont think games should have access to MUA
>
> Yes. But if we have game data stored in the same places as MUA data then it
> happens. A policy to make warzone2100 work in Debian allows games_t to access
> MUA data.
>
>> >> But as for games. Today things like flatpak might be more suitable.
>> >> Then you can combine SELinux and other kernel tech like namespaces,
>> >> bind mounts to make stuff inaccessible etc. Theres also steam which
>> >> essentially is a dumb version of flatpak. I don't think steam would
>> >> ever need any access to a MUA and any of its assets
>> >
>> > Steam needs full network access, graphics, sound, and XDG directory
>> > access.
>>
>> Yes but you were using "passwords" as an argument and then some how put
>> MUA into the equation (I honestly have no clue why a game would need
>> access to a MUA). Not to mention that when it comes to passwords (and to
>> authentication) there are better way's to secure access. Think for example
>> smartcards, TFA, encryption, etc.
>
> What's a good way of setting up TFA with IMAP on both client and server? With
> most systems that have TFA you have a single password for IMAP and TFA for the
> management (changing calendar, plugins, etc).
>
> If MUA is too controversial I could find some other example of something under
> ~/.local that games probably shouldn't access.
>
Take for example my mutt and gnus configuration.
You can GPG encrypt the passwords, then use your smartcard to decrypt
the passwords on demand (your smartcard requires a pin and a hardware
token)
I also do similar with my borg backup config:
export BORG_PASSCOMMAND='pass show borgbackup'
where pass is a shell script that basically leverages gpg/smartcard to
decrypt passwords on the fly. (You need a PIN and a smartcard)
>> >> module policy and monolithic policy are just too limited compared to
>> >> CIL, and refpolicy has some designs centered around things that just
>> >> don't work (think about the derived types limitation i mentioned above
>> >> and how that is rooted to the core in refpolicy (example staff_dbusd_t
>> >> and the dbus_role_template effectively make dbus a hard dependency
>> >> (effectively nowaday's it is) but this also means that no dbus role
>> >> templates (and this any dbus interfaces) should ever be in optional
>> >> blocks
>> >
>> > We can change some of these things.
>>
>> I guess the question is whether it is worth the investment. I will leave
>> that decision to others.
>
> I think the decision might be whether it's worth continuing to maintain
> refpolicy or whether it should be obsoleted.
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
On 6/11/20 8:03 PM, Russell Coker wrote:
> The reference policy is getting an increasing number of domains and types with
> an O(N^2) level of complexity for writing policy and an O(N^2) size of the
> binary policy. In 2012 the binary policy on my machines was 560k, now it's
> over 2M.
>
> In recent policy we have 6 different domains for systemd-generators. What
> benefit are we expecting to get from this? Are we anticipating that one
> generator will attack another? How would having separate domains for
> generators do any good when there's no restriction on the contents of the
> files they generate and nothing to prevent one generator from creating a file
> of the name that another generator is expected to create? Is it even
> reasonable to expect that a program that can create a systemd unit file with
> arbitrary content (IE being able to start any daemon with arbitrary
> configuration and command-line parameters) would be unable to exploit that for
> unrestricted root access?
I find this a valid criticism and reason enough to at least collapse them into a
single domain. The original intent was to constrain the special access they
use, but you are correct, a compromised generator could do mostly do all the bad
things anyway since it can write unit files.
> We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that for?
> Is someone using the X controls and in need of a privileged window manager
> domain to manage the clipboard etc?
Yes.
> Why is staff_wm_t needed when we no
> longer have staff_gpg_t?
Sounds like a gpg change that should be reverted.
> Does staff_r even make sense when you could just use
> different MCS categories for different users?
Yes, as user_r cannot reach admin roles whereas staff_r can.
> We have one games_t domain for games which were packaged by the distribution.
> Is this possible to give a useful benefit given that they some games the same
> XDG config directories as more important things. If a game has the file
> access needed to grab passwords from your MUA and network access to send them
> out then is there a real benefit in having a separate domain for it? As an
> aside I think that the ideal thing to do would be to have a SETGID program to
> manage passwords for email etc that prevents the user from accessing them, it
> could then proxy IMAP/SMTP connections so the MUA never knows the real
> passwords.
I'm a bit hazy on the details you're referring to but you're right that games_t
may not be too impactful. Dominick's flatpak/sandbox/container approach may make
more sense. I don't have any recent Linux gaming experience (with Steam or
otherwise) to judge.
> We have special *_cronjob_t domains which in systems that use them (IE not
> Debian) seem to give the potential for nothing but confusion. The general
> expectation is that anything which can run as a user login session can also
> run as a cron job. What benefit is this expected to provide?
I'd be fine dropping the instantiaton of *_cronjob_t (except system_cronjob_t)
but not removal of the template, for the few instances that users need it.
My question to you is why aren't you commenting on these changes as they are
submitted, instead of unloading on the changes years after the fact? You've
been around the SELinux community longer than I have. These changes aren't
merged in secrecy.
--
Chris PeBenito
On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote:
> Russell Coker <[email protected]> writes:
> > On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote:
> >> What was the main part of your message than? The complexity involved
> >> with removing modules you do not need in any given configuration?
> >
> > The difficulty in managing it all and the limited benefit in trying to do
> > it.
> Yes, Its a bit easier with CIL policy and maybe could even be automated
> in an environment that leverages CIL (although not sure if that would be
> worth the overhead)
What exactly are you saying could be automated?
> >> >> I suppose it's a generic domain for window managers. It originates
> >> >> from the metacity day's Things changed quite a bit since then (think
> >> >> wayland compositors)
> >> >
> >> > Are you saying we should remove the staff_wm_t?
> >>
> >> I am just sharing my knowledge. I will leave that decision to others.
> >
> > To know how something it works is to know whether it works well enough or
> > should be improved.
>
> I think its subjective.
>
> Maybe there no longer is a need to derive wm_t. We would need to
> identity why wm_t was derived in the first place.
>
> Maybe its worth it to make a distinction between X window managers and
> Wayland window managers (although its not as simple i guess due to the
> Xwayland compatibility layer)
>
> I guess I will just admit that I don't feel qualified to answer this
> question.
I just noticed that user_wm_t policy is in Debian/Buster, but I never noticed
it because the type label for KDE wasn't setup.
> >> There is no unconfined_t in dssp3. there is just "the system" and "the
> >> system" is trusted and exempted. This simplifies the policy a great deal
> >> since there isn't a number of unconfined domains by default, there is
> >> just one trusted context by default (you can still make additional
> >> domains unconfined but that is discouraged)
> >
> > So you have init, getty, and syslogd all running in the same context?
>
> Stuff that runs in "the system" context (is trusted):
> sys.id:sys.role:sys.isid:s0
Why be so different? Why not system_u:system_r:base_sys_t:s0?
> 1. systemd --system (pid1)
> 2. systemd-tmpfiles --system
> 3. dbus --system
> 4. default login shells
> 5. package managers
> 6. unknown system services
>
> (i might have overlooked some)
There is the argument about minimum privs. The minimum privilege extremists
want to have things like compilers locked away, I disagree with that as a
hostile party probably would have their own binaries ready. But restricting
who can run the package manager to install things seems useful, more useful
than having 32 different executable types as parts of systemd (not kidding, I
ran wc).
Most of my refpolicy development time is spent adding rules for extra domains
that people have added and for extra systemd features.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Friday, 12 June 2020 10:52:56 PM AEST Chris PeBenito wrote:
> > In recent policy we have 6 different domains for systemd-generators. What
> > benefit are we expecting to get from this? Are we anticipating that one
> > generator will attack another? How would having separate domains for
> > generators do any good when there's no restriction on the contents of the
> > files they generate and nothing to prevent one generator from creating a
> > file of the name that another generator is expected to create? Is it
> > even reasonable to expect that a program that can create a systemd unit
> > file with arbitrary content (IE being able to start any daemon with
> > arbitrary configuration and command-line parameters) would be unable to
> > exploit that for unrestricted root access?
>
> I find this a valid criticism and reason enough to at least collapse them
> into a single domain. The original intent was to constrain the special
> access they use, but you are correct, a compromised generator could do
> mostly do all the bad things anyway since it can write unit files.
OK, I'll submit a patch for that.
> > We have a new set of domains, user_wm_t, staff_wm_t, etc. What is that
> > for? Is someone using the X controls and in need of a privileged window
> > manager domain to manage the clipboard etc?
>
> Yes.
>
> > Why is staff_wm_t needed when we no
> >
> > longer have staff_gpg_t?
>
> Sounds like a gpg change that should be reverted.
I had some of that in the Debian policy, it's a pain to maintain.
> > Does staff_r even make sense when you could just use
> >
> > different MCS categories for different users?
>
> Yes, as user_r cannot reach admin roles whereas staff_r can.
The user identity has a permitted list of roles, you can have users who are
permitted user_r and sysadm_r and users who are only permitted user_r. The
original benefit of staff_r was to protect staff from attacks by user_r
accounts, but we can do that protection with the identity based constraints.
> > We have one games_t domain for games which were packaged by the
> > distribution. Is this possible to give a useful benefit given that they
> > some games the same XDG config directories as more important things. If
> > a game has the file access needed to grab passwords from your MUA and
> > network access to send them out then is there a real benefit in having a
> > separate domain for it? As an aside I think that the ideal thing to do
> > would be to have a SETGID program to manage passwords for email etc that
> > prevents the user from accessing them, it could then proxy IMAP/SMTP
> > connections so the MUA never knows the real passwords.
>
> I'm a bit hazy on the details you're referring to but you're right that
> games_t may not be too impactful. Dominick's flatpak/sandbox/container
> approach may make more sense. I don't have any recent Linux gaming
> experience (with Steam or otherwise) to judge.
Experience playing games isn't really required. The situation is we have
games_t assigned to a bunch of programs that come from the distribution and
therefore meet certain minimum quality checks (which probably give the
binaries in question a range of integrity that overlaps the contents of /usr/
sbin). We also have games downloaded from steam which don't have source
available and can't be reviewed for quality. Also steam games are probably
going to need DRI access which makes it extra exciting.
> > We have special *_cronjob_t domains which in systems that use them (IE not
> > Debian) seem to give the potential for nothing but confusion. The general
> > expectation is that anything which can run as a user login session can
> > also
> > run as a cron job. What benefit is this expected to provide?
>
> I'd be fine dropping the instantiaton of *_cronjob_t (except
> system_cronjob_t) but not removal of the template, for the few instances
> that users need it.
>
> My question to you is why aren't you commenting on these changes as they are
> submitted, instead of unloading on the changes years after the fact?
> You've been around the SELinux community longer than I have. These changes
> aren't merged in secrecy.
I have commented on some of these things in the past (I rejected *_cronjob_t
for Debian). We can deal with some inefficiency, but it builds up and now is
at the stage where I think we have to revisit some assumptions that were made
years ago.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Russell Coker <[email protected]> writes:
> On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote:
>> Russell Coker <[email protected]> writes:
>> > On Friday, 12 June 2020 8:15:34 PM AEST Dominick Grift wrote:
>> >> What was the main part of your message than? The complexity involved
>> >> with removing modules you do not need in any given configuration?
>> >
>> > The difficulty in managing it all and the limited benefit in trying to do
>> > it.
>> Yes, Its a bit easier with CIL policy and maybe could even be automated
>> in an environment that leverages CIL (although not sure if that would be
>> worth the overhead)
>
> What exactly are you saying could be automated?
Its not practical but consider this:
After every semodule transaction, code is run that looks at the cil
filecons in the module store. if none of the filecons exist on the system the module gets
marked disabled and is not compiled/loaded.
You could i guess implement a similar trigger in the package manager
that whenever you do a transaction it runs that same code to determine
which modules are applicable and compile those in, disable the
remainder.
In practice that would be a pretty hefty operation, so might not be
feasible to do this all the time ....
>
>> >> >> I suppose it's a generic domain for window managers. It originates
>> >> >> from the metacity day's Things changed quite a bit since then (think
>> >> >> wayland compositors)
>> >> >
>> >> > Are you saying we should remove the staff_wm_t?
>> >>
>> >> I am just sharing my knowledge. I will leave that decision to others.
>> >
>> > To know how something it works is to know whether it works well enough or
>> > should be improved.
>>
>> I think its subjective.
>>
>> Maybe there no longer is a need to derive wm_t. We would need to
>> identity why wm_t was derived in the first place.
>>
>> Maybe its worth it to make a distinction between X window managers and
>> Wayland window managers (although its not as simple i guess due to the
>> Xwayland compatibility layer)
>>
>> I guess I will just admit that I don't feel qualified to answer this
>> question.
>
> I just noticed that user_wm_t policy is in Debian/Buster, but I never noticed
> it because the type label for KDE wasn't setup.
>
>> >> There is no unconfined_t in dssp3. there is just "the system" and "the
>> >> system" is trusted and exempted. This simplifies the policy a great deal
>> >> since there isn't a number of unconfined domains by default, there is
>> >> just one trusted context by default (you can still make additional
>> >> domains unconfined but that is discouraged)
>> >
>> > So you have init, getty, and syslogd all running in the same context?
>>
>> Stuff that runs in "the system" context (is trusted):
>> sys.id:sys.role:sys.isid:s0
>
> Why be so different? Why not system_u:system_r:base_sys_t:s0?
DSSP3 is a research project into leveraging CIL. CIL namespaces are
therefore leveraged to the fullest. (not to mention that they rock)
>
>> 1. systemd --system (pid1)
>> 2. systemd-tmpfiles --system
>> 3. dbus --system
>> 4. default login shells
>> 5. package managers
>> 6. unknown system services
>>
>> (i might have overlooked some)
>
> There is the argument about minimum privs. The minimum privilege extremists
> want to have things like compilers locked away, I disagree with that as a
> hostile party probably would have their own binaries ready. But restricting
> who can run the package manager to install things seems useful, more useful
> than having 32 different executable types as parts of systemd (not kidding, I
> ran wc).
I would agree that one should not install a compiler unless really
needed. Defense in depth and all.
As for the package manager: yes but you have to see this in context.
I do leverage confined shells, and confined login shells as well. So
even though by default all users can run the package manager, that is
obviously not encouraged. One should instead at least use confined login
shells for unpriv users.
In DSSP3 is also confines most of the individual systemd components (even
the clients for confined shells). systemd can leverage polkit (i am not
a big fan of polkit) and DSSP3 supports that scenario as well. Thats
actually one of the relatively few ascpects targeted in DSSP3....
DSSP3 is open by default (but looks deceive) on the other side it allows
one locks it down quite a bit. It is just not treating the owner as a
child.
DSSP3 is a policy that "just works (most of the time)" for reactive users, and provides a
nice framework to work with for proactive users. Theres really quite a
bit of contrast there, some of it might not make a whole lot of sense to
you.
Then again, i do this for fun and dssp3 is a research project into
leveraging CIL, and just a toy to tinker with.
>
> Most of my refpolicy development time is spent adding rules for extra domains
> that people have added and for extra systemd features.
--
gpg --locate-keys [email protected]
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift
Hi,
I also agree with most things already said.
I would like to add that the way documentation is currently handled
involves too much copy + paste of almost meaningless descriptions, but I
haven't found a very good alternative either. (maybe adding a type
attribute to the param xml and generating a summary based on that could
work in the most common cases)
On 6/12/20 3:02 PM, Russell Coker wrote:
> Does staff_r even make sense when you could just use
>>> different MCS categories for different users?
>> Yes, as user_r cannot reach admin roles whereas staff_r can.
> The user identity has a permitted list of roles, you can have users who are
> permitted user_r and sysadm_r and users who are only permitted user_r. The
> original benefit of staff_r was to protect staff from attacks by user_r
> accounts, but we can do that protection with the identity based constraints.
I would propose replacing user based constraints with role based
constraints:
The user part of the context (normally) doesn't change after login, this
means that files edited by a staff_u user become inaccessible by anyone
else, even if sudo is used to change to staff_u:sysadm_r:sysadm_t, but
reducing the user based constraints for staff_u is undesirable.
Those are just my 2 cents,
bauen1
On 12.6.2020 15.53, Russell Coker wrote:
> I just noticed that user_wm_t policy is in Debian/Buster, but I never noticed
> it because the type label for KDE wasn't setup.
This is fixed in current (but unreleased) refpolicy.
-Topi
On 6/12/20 9:02 AM, Russell Coker wrote:
> On Friday, 12 June 2020 10:52:56 PM AEST Chris PeBenito wrote:
>>> In recent policy we have 6 different domains for systemd-generators. What
>>> benefit are we expecting to get from this? Are we anticipating that one
>>> generator will attack another? How would having separate domains for
>>> generators do any good when there's no restriction on the contents of the
>>> files they generate and nothing to prevent one generator from creating a
>>> file of the name that another generator is expected to create? Is it
>>> even reasonable to expect that a program that can create a systemd unit
>>> file with arbitrary content (IE being able to start any daemon with
>>> arbitrary configuration and command-line parameters) would be unable to
>>> exploit that for unrestricted root access?
>>
>> I find this a valid criticism and reason enough to at least collapse them
>> into a single domain. The original intent was to constrain the special
>> access they use, but you are correct, a compromised generator could do
>> mostly do all the bad things anyway since it can write unit files.
>
> OK, I'll submit a patch for that.
There were a few pending PRs that were put on hold or dropped for this change of
direction, so I've posted the change:
https://github.com/SELinuxProject/refpolicy/pull/276
--
Chris PeBenito
On Monday, 15 June 2020 11:52:43 PM AEST Chris PeBenito wrote:
> > OK, I'll submit a patch for that.
>
> There were a few pending PRs that were put on hold or dropped for this
> change of direction, so I've posted the change:
>
> https://github.com/SELinuxProject/refpolicy/pull/276
Thanks for that. I had Postfix misconfigured on my workstation so my email
with the patch didn't go through. I only use mutt for sending patches to this
list so hadn't noticed the error before.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
I realized that I missed this.
On 6/12/20 10:03 AM, bauen1 wrote:
> Hi,
>
> I also agree with most things already said.
>
> I would like to add that the way documentation is currently handled
> involves too much copy + paste of almost meaningless descriptions, but I
> haven't found a very good alternative either. (maybe adding a type
> attribute to the param xml and generating a summary based on that could
> work in the most common cases)
The original intent with the XML-based docs was for tools to use (see
policy.xml). As far as I know, the only tool that ever used it is long-dead
(SLIDE). If we can come up with with a better solution that doesn't rule-out
the potential for tools, I'd be fine with that. It may go better with a proper
HLL and named interface parameters.
> On 6/12/20 3:02 PM, Russell Coker wrote:
>> Does staff_r even make sense when you could just use
>>>> different MCS categories for different users?
>>> Yes, as user_r cannot reach admin roles whereas staff_r can.
>> The user identity has a permitted list of roles, you can have users who are
>> permitted user_r and sysadm_r and users who are only permitted user_r. The
>> original benefit of staff_r was to protect staff from attacks by user_r
>> accounts, but we can do that protection with the identity based constraints.
>
> I would propose replacing user based constraints with role based
> constraints:
> The user part of the context (normally) doesn't change after login, this
> means that files edited by a staff_u user become inaccessible by anyone
> else, even if sudo is used to change to staff_u:sysadm_r:sysadm_t, but
> reducing the user based constraints for staff_u is undesirable.
This behavior depends on the type of the file. If you end up with a
staff_u:object_r:etc_t context, the user separations don't apply since this is
not a user file.
We used to have role based separations but it was encoded into the TE rules and
generated an enormous amount of rule duplication. There are some remaining
examples of this, e.g. in the su and sudo policies (staff_su_t, sysadm_su_t).
When the default_* statements were implemented I started to reimplement the
role-based separations using the role, but then I lost the work before I
finished. I don't think it is too involved, since it may be as simple copying
the UBAC infrastructure and tweaking it to work on roles.
--
Chris PeBenito
Hi,
On 7/16/20 4:09 PM, Chris PeBenito wrote:
> I realized that I missed this.
>
> On 6/12/20 10:03 AM, bauen1 wrote:
>> Hi,
>>
>> I also agree with most things already said.
>>
>> I would like to add that the way documentation is currently handled
>> involves too much copy + paste of almost meaningless descriptions, but I
>> haven't found a very good alternative either. (maybe adding a type
>> attribute to the param xml and generating a summary based on that could
>> work in the most common cases)
>
> The original intent with the XML-based docs was for tools to use (see policy.xml). As far as I know, the only tool that ever used it is long-dead (SLIDE). If we can come up with with a better solution that doesn't rule-out the potential for tools, I'd be fine with that. It may go better with a proper HLL and named interface parameters.
>
>> On 6/12/20 3:02 PM, Russell Coker wrote:
>>> Does staff_r even make sense when you could just use
>>>>> different MCS categories for different users?
>>>> Yes, as user_r cannot reach admin roles whereas staff_r can.
>>> The user identity has a permitted list of roles, you can have users who are
>>> permitted user_r and sysadm_r and users who are only permitted user_r. The
>>> original benefit of staff_r was to protect staff from attacks by user_r
>>> accounts, but we can do that protection with the identity based constraints.
>>
>> I would propose replacing user based constraints with role based
>> constraints:
>> The user part of the context (normally) doesn't change after login, this
>> means that files edited by a staff_u user become inaccessible by anyone
>> else, even if sudo is used to change to staff_u:sysadm_r:sysadm_t, but
>> reducing the user based constraints for staff_u is undesirable.
>
> This behavior depends on the type of the file. If you end up with a staff_u:object_r:etc_t context, the user separations don't apply since this is not a user file.
I'll have to take another look at it then.
> We used to have role based separations but it was encoded into the TE rules and generated an enormous amount of rule duplication. There are some remaining examples of this, e.g. in the su and sudo policies (staff_su_t, sysadm_su_t).
There are cases where these will still be necessary, mainly when type transitions to the user type are required, but some could be eliminated.
> When the default_* statements were implemented I started to reimplement the role-based separations using the role, but then I lost the work before I finished. I don't think it is too involved, since it may be as simple copying the UBAC infrastructure and tweaking it to work on roles.
I've also worked on implementing RBAC and RBACSEP for refpolicy (A bit messy: https://github.com/bauen1/refpolicy/tree/rbac) . If this becomes a goal to implement, perhaps https://github.com/SELinuxProject/refpolicy/pull/203 could be merged first.
In my CIL policy (https://gitlab.com/bauen1/bauen1-policy/) I use RBAC/RBACSEP and share the types for the generic desktop user between roles, so `user_u:user_r:user_t` becomes `user.user:user.role:user.type` and `staff_u:staff_r:staff_t` becomes `staff.user:staff.role:user.type`. When different permissions and type transitions are necessary "derived" types are used, e.g. for `sysadm.user:sysadm.role:sysadm.type`. This can reduce the amount of types and type enforcement rules by a lot when declaring multiple users that all share the same type rules (but maybe have additional roles). I'm not sure how well this works in practice yet.
--
bauen1
https://dn42.bauen1.xyz/
On 7/19/20 3:29 PM, bauen1 wrote:
> On 7/16/20 4:09 PM, Chris PeBenito wrote:
>> This behavior depends on the type of the file. If you end up with a staff_u:object_r:etc_t context, the user separations don't apply since this is not a user file.
>
> I'll have to take another look at it then.
>
>> We used to have role based separations but it was encoded into the TE rules and generated an enormous amount of rule duplication. There are some remaining examples of this, e.g. in the su and sudo policies (staff_su_t, sysadm_su_t).
>
> There are cases where these will still be necessary, mainly when type transitions to the user type are required, but some could be eliminated.
Right, there will always be needs like this. Which ones could be eliminated? I
can't immediately think of an example.
>> When the default_* statements were implemented I started to reimplement the role-based separations using the role, but then I lost the work before I finished. I don't think it is too involved, since it may be as simple copying the UBAC infrastructure and tweaking it to work on roles.
>
> I've also worked on implementing RBAC and RBACSEP for refpolicy (A bit messy: https://github.com/bauen1/refpolicy/tree/rbac) . If this becomes a goal to implement, perhaps https://github.com/SELinuxProject/refpolicy/pull/203 could be merged first.
It's a goal, but it hasn't been a high enough priority for someone invest the
time in it.
--
Chris PeBenito