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.
