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