On Thu, Jun 18, 2020 at 10:03 AM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Wed, Jun 17, 2020 at 3:23 PM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > In general SELinux no longer treats undefined object classes or permissions > > in the policy as a fatal error, instead handling them in accordance with > > handle_unknown. However, the process class and process transition and > > dyntransition permissions are still required to be defined due to > > dependencies on these definitions for default labeling behaviors, > > role and range transitions in older policy versions that lack an explicit > > class field, and role allow checking. Log error messages in these cases > > since otherwise the policy load will fail silently with no indication > > to the user as to the underlying cause. While here, fix the checking for > > process transition / dyntransition so that omitting either permission is > > handled as an error; both are needed in order to ensure that role allow > > checking is consistently applied. > > > > Reported-by: bauen1 <j2468h@xxxxxxxxxxxxxx> > > Signed-off-by: Stephen Smalley <stephen.smalley.work@xxxxxxxxx> > > BTW I considered and even put together an initial patch to instead > make the process class and transition permissions optional but thought > it was unnecessary complexity for no real gain. One would end up with > a system where new processes would be treated like objects for > labeling (e.g. object_r for the role, inherit type from related object > in this case the executable file) and role allow rules would be > unenforceable. I suppose we could change the test of the process > class to be based on the kernel value rather than the policy value, > which would at least provide sane defaults for labeling. Yes, I think this patch is fine, it seems reasonable to require some basic policy definitions. Merged into selinux/next, thanks. -- paul moore www.paul-moore.com
