| Message ID | 20220921185426.1663357-2-jeffxu@chromium.org (mailing list archive) |
|---|---|
| State | Rejected |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT | expand |
On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > From: Jeff Xu <jeffxu@chromium.org> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > mode, it is useful to disable logging from permissive domain, so audit > log does not get spamed. > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > Tested-by: Jeff Xu<jeffxu@chromium.org> > --- > security/selinux/Kconfig | 10 ++++++++++ > security/selinux/avc.c | 9 +++++++++ > 2 files changed, 19 insertions(+) I'm sorry, but I can't accept this into the upstream kernel. Permissive mode, both per-domain and system-wide, is not intended to be a long term solution. Permissive mode should really only be used as a development tool or emergency "hotfix" with the proper solution being either an adjustment of the existing policy (SELinux policy booleans, labeling changes, etc.) or the development of a new policy module which better fits your use case.
On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > > > From: Jeff Xu <jeffxu@chromium.org> > > > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > > mode, it is useful to disable logging from permissive domain, so audit > > log does not get spamed. > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > > --- > > security/selinux/Kconfig | 10 ++++++++++ > > security/selinux/avc.c | 9 +++++++++ > > 2 files changed, 19 insertions(+) > > I'm sorry, but I can't accept this into the upstream kernel. > Permissive mode, both per-domain and system-wide, is not intended to > be a long term solution. Permissive mode should really only be used > as a development tool or emergency "hotfix" with the proper solution > being either an adjustment of the existing policy (SELinux policy > booleans, labeling changes, etc.) or the development of a new policy > module which better fits your use case. > Thanks for the response. For a system that wants to control a few daemons, is there a recommended pattern from selinux ? I read this blog about unconfined domain (unconfined_t), maybe this is one way ? https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes I have two questions on unconfined domain: 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? 2> will unconfined_t domain log also as permissive domain ? Thanks Jeff > -- > paul-moore.com
On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > > > > > From: Jeff Xu <jeffxu@chromium.org> > > > > > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > > > mode, it is useful to disable logging from permissive domain, so audit > > > log does not get spamed. > > > > > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > > > Tested-by: Jeff Xu<jeffxu@chromium.org> > > > --- > > > security/selinux/Kconfig | 10 ++++++++++ > > > security/selinux/avc.c | 9 +++++++++ > > > 2 files changed, 19 insertions(+) > > > > I'm sorry, but I can't accept this into the upstream kernel. > > Permissive mode, both per-domain and system-wide, is not intended to > > be a long term solution. Permissive mode should really only be used > > as a development tool or emergency "hotfix" with the proper solution > > being either an adjustment of the existing policy (SELinux policy > > booleans, labeling changes, etc.) or the development of a new policy > > module which better fits your use case. > > Thanks for the response. > For a system that wants to control a few daemons, is there a > recommended pattern from selinux ? Guidance on how to write a SELinux policy for an application is a bit beyond what I have time for in this email, but others on this mailing list might be able to help. There has definitely been a lot written on the subject, both available online and offline. My suggestion would be to start "small" with a single SELinux domain for the application and a single type for any configuration, data, or log files it might need; get this initial domain working properly and then you can add increasing levels of access control granularity until you've met your security requirements. If you've never done this before, go slow, the start might be challenging as you get used to the tools, but you can do it :) > I read this blog about unconfined domain (unconfined_t), maybe this is one way ? > https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes It is important to remember that an unconfined domain is, as the name would imply, effectively unconfined by SELinux. Perhaps this is what you want, but generally speaking if you are running SELinux it is because you have a need or desire for additional access controls beyond the legacy Linux discretionary access controls. > I have two questions on unconfined domain: > 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? Yes. The SECURITY_SELINUX_DEVELOP kernel build configuration only enables the admin to boot the kernel initially in permissive mode and/or determine the SELinux mode using the "enforcing=X" kernel command line option and a sysfs/securityfs tunable under /sys/fs/selinux/enforce. The unconfined_t domain is defined purely in the SELinux policy and not the kernel; you could write a SELinux policy without it you wanted, or you could grant unconfined_t-like permissions to multiple different domains in your policy. It's been a while since I played with it, but I believe the SELinux reference policy (refpol) provides a macro interface to define an arbitrary domain with unconfined_t-like permissions. > 2> will unconfined_t domain log also as permissive domain ? The intent of the unconfined_t domain is that there would be no access denials due to SELinux and thus no AVC audit records related to the unconfined_t domain. It is not permissive in the sense of the SELinux "mode" (enforcing/permissive/disabled), but it is permissive in the sense that it is given a large number of permissions.
Paul Moore <paul@paul-moore.com> writes: > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: >> > > >> > > From: Jeff Xu <jeffxu@chromium.org> >> > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive >> > > mode, it is useful to disable logging from permissive domain, so audit >> > > log does not get spamed. >> > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> >> > > --- >> > > security/selinux/Kconfig | 10 ++++++++++ >> > > security/selinux/avc.c | 9 +++++++++ >> > > 2 files changed, 19 insertions(+) >> > >> > I'm sorry, but I can't accept this into the upstream kernel. >> > Permissive mode, both per-domain and system-wide, is not intended to >> > be a long term solution. Permissive mode should really only be used >> > as a development tool or emergency "hotfix" with the proper solution >> > being either an adjustment of the existing policy (SELinux policy >> > booleans, labeling changes, etc.) or the development of a new policy >> > module which better fits your use case. >> >> Thanks for the response. >> For a system that wants to control a few daemons, is there a >> recommended pattern from selinux ? That is effectively a "targeted" policy model. You target a selection of entities and everything else is "unconfined" (ie not targeteed). An "unconfined" domain is just a process type that has many allow rules associated with it making it effectively similar to an "permissive" domain. The difference is that since "unconfined" domains have full access there should not be any AVC denials (nothing is blocked by SELinux because the policy does not target the entity) The stock policy enforced in Red Hat based distributions is a "targeted" policy model for example. The unconfined_t domain is one of various "unconfined" domains (other examples are unconfined_service_t but effectively any type could be made unconfined by simply allowing all accesses. > > Guidance on how to write a SELinux policy for an application is a bit > beyond what I have time for in this email, but others on this mailing > list might be able to help. There has definitely been a lot written > on the subject, both available online and offline. My suggestion > would be to start "small" with a single SELinux domain for the > application and a single type for any configuration, data, or log > files it might need; get this initial domain working properly and then > you can add increasing levels of access control granularity until > you've met your security requirements. If you've never done this > before, go slow, the start might be challenging as you get used to the > tools, but you can do it :) > >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ? >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes > > It is important to remember that an unconfined domain is, as the name > would imply, effectively unconfined by SELinux. Perhaps this is what > you want, but generally speaking if you are running SELinux it is > because you have a need or desire for additional access controls > beyond the legacy Linux discretionary access controls. > >> I have two questions on unconfined domain: >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? > > Yes. The SECURITY_SELINUX_DEVELOP kernel build configuration only > enables the admin to boot the kernel initially in permissive mode > and/or determine the SELinux mode using the "enforcing=X" kernel > command line option and a sysfs/securityfs tunable under > /sys/fs/selinux/enforce. The unconfined_t domain is defined purely in > the SELinux policy and not the kernel; you could write a SELinux > policy without it you wanted, or you could grant unconfined_t-like > permissions to multiple different domains in your policy. It's been a > while since I played with it, but I believe the SELinux reference > policy (refpol) provides a macro interface to define an arbitrary > domain with unconfined_t-like permissions. > >> 2> will unconfined_t domain log also as permissive domain ? > > The intent of the unconfined_t domain is that there would be no access > denials due to SELinux and thus no AVC audit records related to the > unconfined_t domain. It is not permissive in the sense of the SELinux > "mode" (enforcing/permissive/disabled), but it is permissive in the > sense that it is given a large number of permissions.
On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift <dominick.grift@defensec.nl> wrote: > > Paul Moore <paul@paul-moore.com> writes: > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > >> > > > >> > > From: Jeff Xu <jeffxu@chromium.org> > >> > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > >> > > mode, it is useful to disable logging from permissive domain, so audit > >> > > log does not get spamed. > >> > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > >> > > --- > >> > > security/selinux/Kconfig | 10 ++++++++++ > >> > > security/selinux/avc.c | 9 +++++++++ > >> > > 2 files changed, 19 insertions(+) > >> > > >> > I'm sorry, but I can't accept this into the upstream kernel. > >> > Permissive mode, both per-domain and system-wide, is not intended to > >> > be a long term solution. Permissive mode should really only be used > >> > as a development tool or emergency "hotfix" with the proper solution > >> > being either an adjustment of the existing policy (SELinux policy > >> > booleans, labeling changes, etc.) or the development of a new policy > >> > module which better fits your use case. > >> > >> Thanks for the response. > >> For a system that wants to control a few daemons, is there a > >> recommended pattern from selinux ? > > That is effectively a "targeted" policy model. You target a selection of > entities and everything else is "unconfined" (ie not targeteed). > > An "unconfined" domain is just a process type that has many allow rules > associated with it making it effectively similar to an "permissive" > domain. The difference is that since "unconfined" domains have full > access there should not be any AVC denials (nothing is blocked by > SELinux because the policy does not target the entity) > > The stock policy enforced in Red Hat based distributions is a "targeted" > policy model for example. The unconfined_t domain is one of various > "unconfined" domains (other examples are unconfined_service_t but > effectively any type could be made unconfined by simply allowing all accesses. > > > > > Guidance on how to write a SELinux policy for an application is a bit > > beyond what I have time for in this email, but others on this mailing > > list might be able to help. There has definitely been a lot written > > on the subject, both available online and offline. My suggestion > > would be to start "small" with a single SELinux domain for the > > application and a single type for any configuration, data, or log > > files it might need; get this initial domain working properly and then > > you can add increasing levels of access control granularity until > > you've met your security requirements. If you've never done this > > before, go slow, the start might be challenging as you get used to the > > tools, but you can do it :) > > > >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ? > >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes > > > > It is important to remember that an unconfined domain is, as the name > > would imply, effectively unconfined by SELinux. Perhaps this is what > > you want, but generally speaking if you are running SELinux it is > > because you have a need or desire for additional access controls > > beyond the legacy Linux discretionary access controls. > > > >> I have two questions on unconfined domain: > >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? > > > > Yes. The SECURITY_SELINUX_DEVELOP kernel build configuration only > > enables the admin to boot the kernel initially in permissive mode > > and/or determine the SELinux mode using the "enforcing=X" kernel > > command line option and a sysfs/securityfs tunable under > > /sys/fs/selinux/enforce. The unconfined_t domain is defined purely in > > the SELinux policy and not the kernel; you could write a SELinux > > policy without it you wanted, or you could grant unconfined_t-like > > permissions to multiple different domains in your policy. It's been a > > while since I played with it, but I believe the SELinux reference > > policy (refpol) provides a macro interface to define an arbitrary > > domain with unconfined_t-like permissions. > > > >> 2> will unconfined_t domain log also as permissive domain ? > > > > The intent of the unconfined_t domain is that there would be no access > > denials due to SELinux and thus no AVC audit records related to the > > unconfined_t domain. It is not permissive in the sense of the SELinux > > "mode" (enforcing/permissive/disabled), but it is permissive in the > > sense that it is given a large number of permissions. > > -- > gpg --locate-keys dominick.grift@defensec.nl > Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 > Dominick Grift Thanks for details about the unconfined_t domain, this is one option. IMHO: between permissive domain + audit log and unconfined_t, there might be room for letting each permissive domain decide its own audit logging strategy. The reasons are: 1> For a system that have many daemons, a lot of those are not actively worked by devs, relying on tests is not sufficient to discover all possible legitimate accesses at runtime, dev won't be comfortable to enable enforced mode without some bake time in production, this is where permissive + audit log helps. 2> The set back of "permissive + audit log" is that one daemon might generate too much log in production, set to unconfined_t is one option, but then dev revert the progress made so far with permissive mode. 3> For a system that is on continuous delivery pipeline, during the phase of development of selinux policy, daemon owner might need permissive + audit log in testing, but permissive - audit log in production. This is where the per-domain audit log can help, it would be even nicer if this can be controlled at runtime, similar to sysctl. Best regards, Jeff
On Mon, Sep 26, 2022 at 2:03 PM Jeff Xu <jeffxu@chromium.org> wrote: > Thanks for details about the unconfined_t domain, this is one option. > > IMHO: between permissive domain + audit log and unconfined_t, there might > be room for letting each permissive domain decide its own audit logging > strategy. The reasons are ... I'm sorry, but I don't want to support a permissive mode that doesn't generate denial records in the upstream kernel at this point in time.
On Mon, Sep 26, 2022 at 2:41 PM Paul Moore <paul@paul-moore.com> wrote: > > On Mon, Sep 26, 2022 at 2:03 PM Jeff Xu <jeffxu@chromium.org> wrote: > > Thanks for details about the unconfined_t domain, this is one option. > > > > IMHO: between permissive domain + audit log and unconfined_t, there might > > be room for letting each permissive domain decide its own audit logging > > strategy. The reasons are ... > > I'm sorry, but I don't want to support a permissive mode that doesn't > generate denial records in the upstream kernel at this point in time. > No problem, I understand. Thanks Best Regards Jeff > -- > paul-moore.com
On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift <dominick.grift@defensec.nl> wrote: > > Paul Moore <paul@paul-moore.com> writes: > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > >> > > > >> > > From: Jeff Xu <jeffxu@chromium.org> > >> > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > >> > > mode, it is useful to disable logging from permissive domain, so audit > >> > > log does not get spamed. > >> > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > >> > > --- > >> > > security/selinux/Kconfig | 10 ++++++++++ > >> > > security/selinux/avc.c | 9 +++++++++ > >> > > 2 files changed, 19 insertions(+) > >> > > >> > I'm sorry, but I can't accept this into the upstream kernel. > >> > Permissive mode, both per-domain and system-wide, is not intended to > >> > be a long term solution. Permissive mode should really only be used > >> > as a development tool or emergency "hotfix" with the proper solution > >> > being either an adjustment of the existing policy (SELinux policy > >> > booleans, labeling changes, etc.) or the development of a new policy > >> > module which better fits your use case. > >> > >> Thanks for the response. > >> For a system that wants to control a few daemons, is there a > >> recommended pattern from selinux ? > > That is effectively a "targeted" policy model. You target a selection of > entities and everything else is "unconfined" (ie not targeteed). > > An "unconfined" domain is just a process type that has many allow rules > associated with it making it effectively similar to an "permissive" > domain. The difference is that since "unconfined" domains have full > access there should not be any AVC denials (nothing is blocked by > SELinux because the policy does not target the entity) > It seems that my system doesn't have unconfined_t, so I am trying to get an example. Can I use a wildcard, something like below ? type unconfined_t allow unconfined_t * An example would be appreciated. Thanks! -Jeff > The stock policy enforced in Red Hat based distributions is a "targeted" > policy model for example. The unconfined_t domain is one of various > "unconfined" domains (other examples are unconfined_service_t but > effectively any type could be made unconfined by simply allowing all accesses. > > > > > Guidance on how to write a SELinux policy for an application is a bit > > beyond what I have time for in this email, but others on this mailing > > list might be able to help. There has definitely been a lot written > > on the subject, both available online and offline. My suggestion > > would be to start "small" with a single SELinux domain for the > > application and a single type for any configuration, data, or log > > files it might need; get this initial domain working properly and then > > you can add increasing levels of access control granularity until > > you've met your security requirements. If you've never done this > > before, go slow, the start might be challenging as you get used to the > > tools, but you can do it :) > > > >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ? > >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes > > > > It is important to remember that an unconfined domain is, as the name > > would imply, effectively unconfined by SELinux. Perhaps this is what > > you want, but generally speaking if you are running SELinux it is > > because you have a need or desire for additional access controls > > beyond the legacy Linux discretionary access controls. > > > >> I have two questions on unconfined domain: > >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? > > > > Yes. The SECURITY_SELINUX_DEVELOP kernel build configuration only > > enables the admin to boot the kernel initially in permissive mode > > and/or determine the SELinux mode using the "enforcing=X" kernel > > command line option and a sysfs/securityfs tunable under > > /sys/fs/selinux/enforce. The unconfined_t domain is defined purely in > > the SELinux policy and not the kernel; you could write a SELinux > > policy without it you wanted, or you could grant unconfined_t-like > > permissions to multiple different domains in your policy. It's been a > > while since I played with it, but I believe the SELinux reference > > policy (refpol) provides a macro interface to define an arbitrary > > domain with unconfined_t-like permissions. > > > >> 2> will unconfined_t domain log also as permissive domain ? > > > > The intent of the unconfined_t domain is that there would be no access > > denials due to SELinux and thus no AVC audit records related to the > > unconfined_t domain. It is not permissive in the sense of the SELinux > > "mode" (enforcing/permissive/disabled), but it is permissive in the > > sense that it is given a large number of permissions. > > -- > gpg --locate-keys dominick.grift@defensec.nl > Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 > Dominick Grift
Jeff Xu <jeffxu@chromium.org> writes: > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift > <dominick.grift@defensec.nl> wrote: >> >> Paul Moore <paul@paul-moore.com> writes: >> >> > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: >> >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: >> >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: >> >> > > >> >> > > From: Jeff Xu <jeffxu@chromium.org> >> >> > > >> >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive >> >> > > mode, it is useful to disable logging from permissive domain, so audit >> >> > > log does not get spamed. >> >> > > >> >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> >> >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> >> >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> >> >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> >> >> > > --- >> >> > > security/selinux/Kconfig | 10 ++++++++++ >> >> > > security/selinux/avc.c | 9 +++++++++ >> >> > > 2 files changed, 19 insertions(+) >> >> > >> >> > I'm sorry, but I can't accept this into the upstream kernel. >> >> > Permissive mode, both per-domain and system-wide, is not intended to >> >> > be a long term solution. Permissive mode should really only be used >> >> > as a development tool or emergency "hotfix" with the proper solution >> >> > being either an adjustment of the existing policy (SELinux policy >> >> > booleans, labeling changes, etc.) or the development of a new policy >> >> > module which better fits your use case. >> >> >> >> Thanks for the response. >> >> For a system that wants to control a few daemons, is there a >> >> recommended pattern from selinux ? >> >> That is effectively a "targeted" policy model. You target a selection of >> entities and everything else is "unconfined" (ie not targeteed). >> >> An "unconfined" domain is just a process type that has many allow rules >> associated with it making it effectively similar to an "permissive" >> domain. The difference is that since "unconfined" domains have full >> access there should not be any AVC denials (nothing is blocked by >> SELinux because the policy does not target the entity) >> > It seems that my system doesn't have unconfined_t, so > I am trying to get an example. It does not necessarily have to be unconfined_t. > > Can I use a wildcard, something like below ? > type unconfined_t > allow unconfined_t * I took some time to try and come up with an example that goes to the essence. For this i used the example tiny cil-policy from the SELinux notebook. You would need `secilc`, `seinfo` and, `sesearch` to try it out yourself: curl \ https://raw.githubusercontent.com/SELinuxProject/selinux-notebook/main/src/notebook-examples/cil-policy/cil-policy.cil \ > cil-policy.cil secilc -vvv cil-policy.cil seinfo policy.33 this is "tiny CIL policy" it can be used for demonstration. it has a single type "sys.isid": seinfo policy.33 -t and it has only one security class that has two access vector permissions associated with it namely: "process { dyntransition transition }" seinfo policy.33 -xc the single type "sys.isid" has "unconfined" access: sesearch policy.33 -A this is essentially the simplest example of an "unconfined" domain. lets add a new type, and new security class and some permissions. to demonstrate what it takes to have a unconfined domain in an environment that has more than just one type, one security class and two permission. I will do it in stages. echo '(type mytype) ;; a new type' >> cil-policy.cil echo '(class myclass ( myperm1 myperm2 )) (classorder (unordered myclass)) ;; a new class with two new permissions' >> cil-policy.cil secilc -vvv cil-policy.cil seinfo policy.33 seinfo policy.33 -t seinfo policy.33 -xc sesearch policy.33 -A now type sys.isid is no longer an unconfined domain because it does not have access to "myclass { myperm1 myperm2 }". The new "mytype" type has no permisssions associated with it at all. to make sys.isid unconfined again we have to: 1. (allow sys.isid sys.isid (myclass (myperm1 myperm2))) 2. (allow sys.isid mytype (myclass (myperm1 myperm2))) 3. (allow sys.isid mytype (process (dyntransition transition))) this is a bit hard to manage. we can use type attributes to group types: echo '(typeattribute mytypes) ;; a new type attribute' >> cil-policy.cil echo '(typeattributeset mytypes (sys.isid mytype)) ;; all our types are associates' >> cil-policy.cil secilc -vvv cil-policy.cil seinfo policy.33 -xamytypes now the above 3 rules can be written in a simpler way: echo '(allow sys.isid mytypes (myclass (all))) ;; access to effectively: * myclass *' >> cil-policy.cil echo '(allow sys.isid mytypes (process (all))) ;; access to effectively: * process *' >> cil-policy.cil secilc -vvv cil-policy.cil seinfo policy.33 seinfo policy.33 -t seinfo policy.33 -xc sesearch policy.33 -A I think this is probably the simplest example of an unconfined domain. type attributes can be used to "organise your policy" if you plan your policy well then eventually making a "domain" unconfined could be as easy as associating it with a type attribute. sesearch policy.33 -A -t sys.isid -t mytypes -dt seinfo policy.33 -xa mytypes for example we could create a type attribute called "unconfined_access" and associate all access vectors with it: (typeattribute unconfined_access) (allow unconfined_access mytypes (myclass (all))) (allow unconfined_access mytypes (process (all))) then to make type "mytype" unconfined as well; simple associate it with unconfined_access (typeattributeset unconfined_access (mytype))) > > An example would be appreciated. > > Thanks! > -Jeff > > > >> The stock policy enforced in Red Hat based distributions is a "targeted" >> policy model for example. The unconfined_t domain is one of various >> "unconfined" domains (other examples are unconfined_service_t but >> effectively any type could be made unconfined by simply allowing all accesses. >> >> > >> > Guidance on how to write a SELinux policy for an application is a bit >> > beyond what I have time for in this email, but others on this mailing >> > list might be able to help. There has definitely been a lot written >> > on the subject, both available online and offline. My suggestion >> > would be to start "small" with a single SELinux domain for the >> > application and a single type for any configuration, data, or log >> > files it might need; get this initial domain working properly and then >> > you can add increasing levels of access control granularity until >> > you've met your security requirements. If you've never done this >> > before, go slow, the start might be challenging as you get used to the >> > tools, but you can do it :) >> > >> >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ? >> >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes >> > >> > It is important to remember that an unconfined domain is, as the name >> > would imply, effectively unconfined by SELinux. Perhaps this is what >> > you want, but generally speaking if you are running SELinux it is >> > because you have a need or desire for additional access controls >> > beyond the legacy Linux discretionary access controls. >> > >> >> I have two questions on unconfined domain: >> >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ? >> > >> > Yes. The SECURITY_SELINUX_DEVELOP kernel build configuration only >> > enables the admin to boot the kernel initially in permissive mode >> > and/or determine the SELinux mode using the "enforcing=X" kernel >> > command line option and a sysfs/securityfs tunable under >> > /sys/fs/selinux/enforce. The unconfined_t domain is defined purely in >> > the SELinux policy and not the kernel; you could write a SELinux >> > policy without it you wanted, or you could grant unconfined_t-like >> > permissions to multiple different domains in your policy. It's been a >> > while since I played with it, but I believe the SELinux reference >> > policy (refpol) provides a macro interface to define an arbitrary >> > domain with unconfined_t-like permissions. >> > >> >> 2> will unconfined_t domain log also as permissive domain ? >> > >> > The intent of the unconfined_t domain is that there would be no access >> > denials due to SELinux and thus no AVC audit records related to the >> > unconfined_t domain. It is not permissive in the sense of the SELinux >> > "mode" (enforcing/permissive/disabled), but it is permissive in the >> > sense that it is given a large number of permissions. >> >> -- >> gpg --locate-keys dominick.grift@defensec.nl >> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 >> Dominick Grift
On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote: > > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift > <dominick.grift@defensec.nl> wrote: > > > > Paul Moore <paul@paul-moore.com> writes: > > > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > >> > > > > >> > > From: Jeff Xu <jeffxu@chromium.org> > > >> > > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > > >> > > mode, it is useful to disable logging from permissive domain, so audit > > >> > > log does not get spamed. > > >> > > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > > >> > > --- > > >> > > security/selinux/Kconfig | 10 ++++++++++ > > >> > > security/selinux/avc.c | 9 +++++++++ > > >> > > 2 files changed, 19 insertions(+) > > >> > > > >> > I'm sorry, but I can't accept this into the upstream kernel. > > >> > Permissive mode, both per-domain and system-wide, is not intended to > > >> > be a long term solution. Permissive mode should really only be used > > >> > as a development tool or emergency "hotfix" with the proper solution > > >> > being either an adjustment of the existing policy (SELinux policy > > >> > booleans, labeling changes, etc.) or the development of a new policy > > >> > module which better fits your use case. > > >> > > >> Thanks for the response. > > >> For a system that wants to control a few daemons, is there a > > >> recommended pattern from selinux ? > > > > That is effectively a "targeted" policy model. You target a selection of > > entities and everything else is "unconfined" (ie not targeteed). > > > > An "unconfined" domain is just a process type that has many allow rules > > associated with it making it effectively similar to an "permissive" > > domain. The difference is that since "unconfined" domains have full > > access there should not be any AVC denials (nothing is blocked by > > SELinux because the policy does not target the entity) > > > It seems that my system doesn't have unconfined_t, so > I am trying to get an example. > > Can I use a wildcard, something like below ? > type unconfined_t > allow unconfined_t * > > An example would be appreciated. If your policy in Android-based, then the su domain would be the easiest starting point. It isn't quite what you want (a permissive domain with dontaudit rules that suppress all denials, only included in userdebug or eng builds) but if you replace "dontaudit" with allow everywhere, it would be "unconfined".
On Fri, Feb 17, 2023 at 10:22 AM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote: > > > > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift > > <dominick.grift@defensec.nl> wrote: > > > > > > Paul Moore <paul@paul-moore.com> writes: > > > > > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > > >> > > > > > >> > > From: Jeff Xu <jeffxu@chromium.org> > > > >> > > > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > > > >> > > mode, it is useful to disable logging from permissive domain, so audit > > > >> > > log does not get spamed. > > > >> > > > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > > > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > > > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > > > >> > > --- > > > >> > > security/selinux/Kconfig | 10 ++++++++++ > > > >> > > security/selinux/avc.c | 9 +++++++++ > > > >> > > 2 files changed, 19 insertions(+) > > > >> > > > > >> > I'm sorry, but I can't accept this into the upstream kernel. > > > >> > Permissive mode, both per-domain and system-wide, is not intended to > > > >> > be a long term solution. Permissive mode should really only be used > > > >> > as a development tool or emergency "hotfix" with the proper solution > > > >> > being either an adjustment of the existing policy (SELinux policy > > > >> > booleans, labeling changes, etc.) or the development of a new policy > > > >> > module which better fits your use case. > > > >> > > > >> Thanks for the response. > > > >> For a system that wants to control a few daemons, is there a > > > >> recommended pattern from selinux ? > > > > > > That is effectively a "targeted" policy model. You target a selection of > > > entities and everything else is "unconfined" (ie not targeteed). > > > > > > An "unconfined" domain is just a process type that has many allow rules > > > associated with it making it effectively similar to an "permissive" > > > domain. The difference is that since "unconfined" domains have full > > > access there should not be any AVC denials (nothing is blocked by > > > SELinux because the policy does not target the entity) > > > > > It seems that my system doesn't have unconfined_t, so > > I am trying to get an example. > > > > Can I use a wildcard, something like below ? > > type unconfined_t > > allow unconfined_t * > > > > An example would be appreciated. > > If your policy in Android-based, then the su domain would be the > easiest starting point. It isn't quite what you want (a permissive > domain with dontaudit rules that suppress all denials, only included > in userdebug or eng builds) but if you replace "dontaudit" with allow > everywhere, it would be "unconfined". BTW SELinux already has a way to achieve the same end as your kernel patch without any code changes; there are dontaudit rules in policy that can silence denials and you just need to write them to cover all classes/permissions. This is done in the Android su policy.
On Fri, Feb 17, 2023 at 7:25 AM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Fri, Feb 17, 2023 at 10:22 AM Stephen Smalley > <stephen.smalley.work@gmail.com> wrote: > > > > On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote: > > > > > > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift > > > <dominick.grift@defensec.nl> wrote: > > > > > > > > Paul Moore <paul@paul-moore.com> writes: > > > > > > > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote: > > > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote: > > > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote: > > > > >> > > > > > > >> > > From: Jeff Xu <jeffxu@chromium.org> > > > > >> > > > > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive > > > > >> > > mode, it is useful to disable logging from permissive domain, so audit > > > > >> > > log does not get spamed. > > > > >> > > > > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > > > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com> > > > > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org> > > > > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org> > > > > >> > > --- > > > > >> > > security/selinux/Kconfig | 10 ++++++++++ > > > > >> > > security/selinux/avc.c | 9 +++++++++ > > > > >> > > 2 files changed, 19 insertions(+) > > > > >> > > > > > >> > I'm sorry, but I can't accept this into the upstream kernel. > > > > >> > Permissive mode, both per-domain and system-wide, is not intended to > > > > >> > be a long term solution. Permissive mode should really only be used > > > > >> > as a development tool or emergency "hotfix" with the proper solution > > > > >> > being either an adjustment of the existing policy (SELinux policy > > > > >> > booleans, labeling changes, etc.) or the development of a new policy > > > > >> > module which better fits your use case. > > > > >> > > > > >> Thanks for the response. > > > > >> For a system that wants to control a few daemons, is there a > > > > >> recommended pattern from selinux ? > > > > > > > > That is effectively a "targeted" policy model. You target a selection of > > > > entities and everything else is "unconfined" (ie not targeteed). > > > > > > > > An "unconfined" domain is just a process type that has many allow rules > > > > associated with it making it effectively similar to an "permissive" > > > > domain. The difference is that since "unconfined" domains have full > > > > access there should not be any AVC denials (nothing is blocked by > > > > SELinux because the policy does not target the entity) > > > > > > > It seems that my system doesn't have unconfined_t, so > > > I am trying to get an example. > > > > > > Can I use a wildcard, something like below ? > > > type unconfined_t > > > allow unconfined_t * > > > > > > An example would be appreciated. > > > > If your policy in Android-based, then the su domain would be the > > easiest starting point. It isn't quite what you want (a permissive > > domain with dontaudit rules that suppress all denials, only included > > in userdebug or eng builds) but if you replace "dontaudit" with allow > > everywhere, it would be "unconfined". > > BTW SELinux already has a way to achieve the same end as your kernel > patch without any code changes; there are dontaudit rules in policy > that can silence denials and you just need to write them to cover all > classes/permissions. This is done in the Android su policy. Got it, Thanks everyone for pointing out solutions! -Jeff
diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index 9e921fc72538..99b8b88abc3d 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -61,6 +61,16 @@ config SECURITY_SELINUX_DEVELOP permissive mode (if permitted by the policy) via /sys/fs/selinux/enforce. +config SECURITY_SELINUX_PERMISSIVE_DONTAUDIT + bool "NSA SELinux don't audit permissive" + depends on SECURITY_SELINUX + default n + help + This prevents logging when permissive=1. If unsure, say N. With + this option enabled, any avc logs that would occur on a permissive + domain won't be logged. This can prevent a significant amount of + logspam. + config SECURITY_SELINUX_AVC_STATS bool "NSA SELinux AVC Statistics" depends on SECURITY_SELINUX diff --git a/security/selinux/avc.c b/security/selinux/avc.c index 9a43af0ebd7d..2f0a49d7c714 100644 --- a/security/selinux/avc.c +++ b/security/selinux/avc.c @@ -777,6 +777,15 @@ noinline int slow_avc_audit(struct selinux_state *state, if (WARN_ON(!tclass || tclass >= ARRAY_SIZE(secclass_map))) return -EINVAL; + /* + * Avoid logging permissive=1 messages for + * SECURITY_SELINUX_PERMISSIVE_DONTAUDIT. + */ + if (IS_ENABLED(CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT) && denied + && !result) { + return 0; + } + if (!a) { a = &stack_data; a->type = LSM_AUDIT_DATA_NONE;