On Tue, Sep 25, 2018 at 1:45 AM Taras Kondratiuk <takondra@xxxxxxxxx> wrote: > Quoting Paul Moore (2018-09-24 20:46:57) > > On Fri, Sep 21, 2018 at 10:39 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > > > On 09/20/2018 06:59 PM, Taras Kondratiuk wrote: > > > > Quoting Stephen Smalley (2018-09-20 07:49:12) > > > >> On 09/19/2018 10:41 PM, Taras Kondratiuk wrote: > > > >>> Quoting Stephen Smalley (2018-09-19 12:00:33) > > > >>>> On 09/19/2018 12:52 PM, Taras Kondratiuk wrote: > > > > ... > > > > > > IMO it would be more consistent if defcontext cover all "unlabeled" > > > > groups. It seems unlikely to me that somebody who currently uses > > > > defcontext can somehow rely on mapping invalid labels to unlabeled > > > > instead of default context. > > > > > > Yes, and that seems more consistent with the current documentation in > > > the mount man page for defcontext=. > > > > > > I'd be inclined to change selinux_inode_notifysecctx() to call > > > security_context_to_sid_default() directly instead of using > > > selinux_inode_setsecurity() and change security_context_to_sid_core() > > > and sidtab_search_core() as suggested above to save and use the def_sid > > > instead of SECINITSID_UNLABELED always (initializing the context def_sid > > > to SECINITSID_UNLABELED as the default). selinux_inode_setsecurity() we > > > should leave unchanged, or if we change it at all, it should be more > > > like the handling in selinux_inode_setxattr(). The notifysecctx hook is > > > invoked by the filesystem to notify the security module of the file's > > > existing security context, so in that case we always want the _default > > > behavior, whereas the setsecurity hook is invoked by the vfs or the > > > filesystem to set the security context of a file to a new value, so in > > > that case we would only use the _force interface if the caller had > > > CAP_MAC_ADMIN. > > > > > > Paul, what say you? NB This would be a user-visible behavior change for > > > mounts specifying defcontext= on xattr filesystems; files with invalid > > > contexts will then show up with the defcontext value instead of the > > > unlabeled context. If that's too risky, then we'd need a flag or > > > something to security_context_to_sid_default() to distinguish the > > > behaviors and only set it when called from selinux_inode_notifysecctx(). > > > > Visible changes like this are always worrisome, even though I think it > > is safe to assume that the defcontext option is not widely used. I'd > > feel much better if this change was opt-in. > > > > Which brings about it's own problems. We have the policy capability > > functionality, but that is likely a poor fit for this as the policy > > capabilities are usually controlled by the Linux distribution while > > the mount options are set by the system's administrator when the > > filesystem is mounted. We could add a toggle somewhere in selinuxfs, > > but I really dislike that idea, and would prefer to find a different > > solution if possible. I'm not sure how much flak we would get for > > introducing a new mount option, but perhaps that is the best way to > > handle this: defcontext would continue to behave as it does now, but > > new option X would behave as mentioned in this thread. > > > > Thoughts? > > The new option X will also mean "default context", so it will be pretty > hard to come up with a different but a sensible name. I'm afraid that > having two options with hardly distinguishable semantics will be very > confusing. > > What about a kernel config option that modifies the behavior of > defcontext? A kernel config option would be going in the wrong direction; that would put it almost completely under the control of the distribution. -- paul moore www.paul-moore.com _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
