* Are we on the wrong track? @ 2020-06-12 0:03 Russell Coker 2020-06-12 7:05 ` Topi Miettinen ` (3 more replies) 0 siblings, 4 replies; 21+ messages in thread From: Russell Coker @ 2020-06-12 0:03 UTC (permalink / raw) To: selinux-refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 0:03 Are we on the wrong track? Russell Coker @ 2020-06-12 7:05 ` Topi Miettinen 2020-06-12 8:02 ` Dac Override ` (2 subsequent siblings) 3 siblings, 0 replies; 21+ messages in thread From: Topi Miettinen @ 2020-06-12 7:05 UTC (permalink / raw) To: Russell Coker, selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 0:03 Are we on the wrong track? Russell Coker 2020-06-12 7:05 ` Topi Miettinen @ 2020-06-12 8:02 ` Dac Override 2020-06-12 9:54 ` Russell Coker 2020-06-12 11:00 ` Denis Obrezkov 2020-06-12 12:52 ` Chris PeBenito 3 siblings, 1 reply; 21+ messages in thread From: Dac Override @ 2020-06-12 8:02 UTC (permalink / raw) To: Russell Coker; +Cc: refpolicy On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <russell@coker.com.au> 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/ > > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 8:02 ` Dac Override @ 2020-06-12 9:54 ` Russell Coker 2020-06-12 10:15 ` Dominick Grift 0 siblings, 1 reply; 21+ messages in thread From: Russell Coker @ 2020-06-12 9:54 UTC (permalink / raw) To: Dac Override; +Cc: refpolicy On Friday, 12 June 2020 6:02:15 PM AEST Dac Override wrote: > On Fri, Jun 12, 2020 at 2:16 AM Russell Coker <russell@coker.com.au> 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 9:54 ` Russell Coker @ 2020-06-12 10:15 ` Dominick Grift 2020-06-12 12:05 ` Russell Coker 0 siblings, 1 reply; 21+ messages in thread From: Dominick Grift @ 2020-06-12 10:15 UTC (permalink / raw) To: Russell Coker; +Cc: Dac Override, refpolicy Russell Coker <russell@coker.com.au> 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 <russell@coker.com.au> 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 dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 10:15 ` Dominick Grift @ 2020-06-12 12:05 ` Russell Coker 2020-06-12 12:26 ` Dominick Grift 0 siblings, 1 reply; 21+ messages in thread From: Russell Coker @ 2020-06-12 12:05 UTC (permalink / raw) To: Dominick Grift, refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 12:05 ` Russell Coker @ 2020-06-12 12:26 ` Dominick Grift 2020-06-12 12:53 ` Russell Coker 0 siblings, 1 reply; 21+ messages in thread From: Dominick Grift @ 2020-06-12 12:26 UTC (permalink / raw) To: Russell Coker; +Cc: refpolicy Russell Coker <russell@coker.com.au> 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 dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 12:26 ` Dominick Grift @ 2020-06-12 12:53 ` Russell Coker 2020-06-12 13:20 ` Dominick Grift 2020-06-14 16:30 ` Topi Miettinen 0 siblings, 2 replies; 21+ messages in thread From: Russell Coker @ 2020-06-12 12:53 UTC (permalink / raw) To: Dominick Grift; +Cc: refpolicy On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote: > Russell Coker <russell@coker.com.au> 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 12:53 ` Russell Coker @ 2020-06-12 13:20 ` Dominick Grift 2020-06-14 16:30 ` Topi Miettinen 1 sibling, 0 replies; 21+ messages in thread From: Dominick Grift @ 2020-06-12 13:20 UTC (permalink / raw) To: Russell Coker; +Cc: refpolicy Russell Coker <russell@coker.com.au> writes: > On Friday, 12 June 2020 10:26:35 PM AEST Dominick Grift wrote: >> Russell Coker <russell@coker.com.au> 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 dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 12:53 ` Russell Coker 2020-06-12 13:20 ` Dominick Grift @ 2020-06-14 16:30 ` Topi Miettinen 1 sibling, 0 replies; 21+ messages in thread From: Topi Miettinen @ 2020-06-14 16:30 UTC (permalink / raw) To: Russell Coker, Dominick Grift; +Cc: refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 0:03 Are we on the wrong track? Russell Coker 2020-06-12 7:05 ` Topi Miettinen 2020-06-12 8:02 ` Dac Override @ 2020-06-12 11:00 ` Denis Obrezkov 2020-06-12 11:53 ` Russell Coker 2020-06-12 11:57 ` Dominick Grift 2020-06-12 12:52 ` Chris PeBenito 3 siblings, 2 replies; 21+ messages in thread From: Denis Obrezkov @ 2020-06-12 11:00 UTC (permalink / raw) To: Russell Coker, selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 11:00 ` Denis Obrezkov @ 2020-06-12 11:53 ` Russell Coker 2020-06-12 11:57 ` Dominick Grift 1 sibling, 0 replies; 21+ messages in thread From: Russell Coker @ 2020-06-12 11:53 UTC (permalink / raw) To: Denis Obrezkov; +Cc: selinux-refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 11:00 ` Denis Obrezkov 2020-06-12 11:53 ` Russell Coker @ 2020-06-12 11:57 ` Dominick Grift 1 sibling, 0 replies; 21+ messages in thread From: Dominick Grift @ 2020-06-12 11:57 UTC (permalink / raw) To: Denis Obrezkov; +Cc: Russell Coker, selinux-refpolicy Denis Obrezkov <denisobrezkov@gmail.com> 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 dominick.grift@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 0:03 Are we on the wrong track? Russell Coker ` (2 preceding siblings ...) 2020-06-12 11:00 ` Denis Obrezkov @ 2020-06-12 12:52 ` Chris PeBenito 2020-06-12 13:02 ` Russell Coker 3 siblings, 1 reply; 21+ messages in thread From: Chris PeBenito @ 2020-06-12 12:52 UTC (permalink / raw) To: Russell Coker, selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 12:52 ` Chris PeBenito @ 2020-06-12 13:02 ` Russell Coker 2020-06-12 14:03 ` bauen1 2020-06-15 13:52 ` Chris PeBenito 0 siblings, 2 replies; 21+ messages in thread From: Russell Coker @ 2020-06-12 13:02 UTC (permalink / raw) To: Chris PeBenito; +Cc: selinux-refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 13:02 ` Russell Coker @ 2020-06-12 14:03 ` bauen1 2020-07-16 14:09 ` Chris PeBenito 2020-06-15 13:52 ` Chris PeBenito 1 sibling, 1 reply; 21+ messages in thread From: bauen1 @ 2020-06-12 14:03 UTC (permalink / raw) Cc: selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 14:03 ` bauen1 @ 2020-07-16 14:09 ` Chris PeBenito 2020-07-19 19:29 ` bauen1 0 siblings, 1 reply; 21+ messages in thread From: Chris PeBenito @ 2020-07-16 14:09 UTC (permalink / raw) To: bauen1; +Cc: selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-07-16 14:09 ` Chris PeBenito @ 2020-07-19 19:29 ` bauen1 2020-07-21 14:22 ` Chris PeBenito 0 siblings, 1 reply; 21+ messages in thread From: bauen1 @ 2020-07-19 19:29 UTC (permalink / raw) To: Chris PeBenito, bauen1; +Cc: selinux-refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-07-19 19:29 ` bauen1 @ 2020-07-21 14:22 ` Chris PeBenito 0 siblings, 0 replies; 21+ messages in thread From: Chris PeBenito @ 2020-07-21 14:22 UTC (permalink / raw) To: bauen1; +Cc: selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-12 13:02 ` Russell Coker 2020-06-12 14:03 ` bauen1 @ 2020-06-15 13:52 ` Chris PeBenito 2020-06-15 21:02 ` Russell Coker 1 sibling, 1 reply; 21+ messages in thread From: Chris PeBenito @ 2020-06-15 13:52 UTC (permalink / raw) To: Russell Coker; +Cc: selinux-refpolicy 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Are we on the wrong track? 2020-06-15 13:52 ` Chris PeBenito @ 2020-06-15 21:02 ` Russell Coker 0 siblings, 0 replies; 21+ messages in thread From: Russell Coker @ 2020-06-15 21:02 UTC (permalink / raw) To: Chris PeBenito; +Cc: selinux-refpolicy 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/ ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2020-07-21 14:22 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-12 0:03 Are we on the wrong track? Russell Coker 2020-06-12 7:05 ` Topi Miettinen 2020-06-12 8:02 ` Dac Override 2020-06-12 9:54 ` Russell Coker 2020-06-12 10:15 ` Dominick Grift 2020-06-12 12:05 ` Russell Coker 2020-06-12 12:26 ` Dominick Grift 2020-06-12 12:53 ` Russell Coker 2020-06-12 13:20 ` Dominick Grift 2020-06-14 16:30 ` Topi Miettinen 2020-06-12 11:00 ` Denis Obrezkov 2020-06-12 11:53 ` Russell Coker 2020-06-12 11:57 ` Dominick Grift 2020-06-12 12:52 ` Chris PeBenito 2020-06-12 13:02 ` Russell Coker 2020-06-12 14:03 ` bauen1 2020-07-16 14:09 ` Chris PeBenito 2020-07-19 19:29 ` bauen1 2020-07-21 14:22 ` Chris PeBenito 2020-06-15 13:52 ` Chris PeBenito 2020-06-15 21:02 ` Russell Coker
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).