[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Stephen Smalley]

On Fri, Feb 17, 2023 at 10:22 AM Stephen Smalley
<stephen.smalley.work at gmail.com> wrote:
>
> On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu at chromium.org> wrote:
> >
> > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> > <dominick.grift at defensec.nl> wrote:
> > >
> > > Paul Moore <paul at paul-moore.com> writes:
> > >
> > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu at chromium.org> wrote:
> > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul at paul-moore.com> wrote:
> > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu at chromium.org> wrote:
> > > >> > >
> > > >> > > From: Jeff Xu <jeffxu at 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 at chromium.org>
> > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez at google.com>
> > > >> > > Tested-by: Luis Hector Chavez <lhchavez at chromium.org>
> > > >> > > Tested-by: Jeff Xu<jeffxu at 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.