Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux