[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Stephen Smalley]

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".