On Thu, 2017-07-20 at 17:08 -0400, Chris PeBenito wrote: > On 07/20/2017 09:04 AM, Stephen Smalley wrote: > > On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: > > > On 07/19/2017 05:31 PM, Dominick Grift wrote: > > > > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > > > > > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift > > > > > wrote: > > > > > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito > > > > > > wrote: > > > > > > > Once this permission is implemented I'll likely add the > > > > > > > permission across > > > > > > > most if not all transitions out of systemd. > > > > > > > > > > > > Yes but do not expect that to ,always, be enough due to the > > > > > > inheritance aspect. A process may have inherited the NNP > > > > > > flag, > > > > > > not because its started by systemd but because its started > > > > > > by a > > > > > > process that inherited the NNP flag because it was started > > > > > > by > > > > > > systemd. > > > > > > That just makes me want to apply the permission to all > > > transitions > > > for > > > all domains. Not that I'm planning to do it in refpolicy. I'm > > > definitely inclined to be very liberal in applying the permission > > > in > > > refpolicy. For my personal systems, I'd probably do an: > > > > > > allow domain domain:process nnp_nosuid_transition; > > > > > > so I don't ever have to think about it again. > > > > Caveats: > > > > 1. It would mean that transitions on any removable media would be > > possible, even when marked nosuid. So, for example, if you were to > > mount (or have auto-mounted) removable media with nosuid but > > without > > noexec, and the removable media had been maliciously crafted with a > > file with an entrypoint type, then a user could use it to > > transition to > > a potentially more privileged SELinux domain, even though it could > > not > > gain capabilities or uid-0 that way (or, if the user can induce > > another > > process to execute from this filesystem, then this could produce a > > domain transition that would normally have been prevented). Ditto > > for > > network filesystems. This is perhaps an argument for introducing a > > separate check on nosuid; could be done via a file-based additional > > check (Can domain D nosuid_transition on file type T?) in addition > > to > > the nnp_nosuid_transition process-based permission check or by > > adding a > > process2 class and splitting nnp_nosuid_transition into > > nosuid_transition and nnp_transition process-based permissions. > > This is a good point; however, if you're trusting removable media to > do > transitions on, you're already accepting a lot of risk of shooting > yourself in the foot. Exactly, which is why allowing transitions under nosuid could be dangerous, since nosuid is the traditional way of indicating that you don't trust the filesystem. > While I understand the logic of the nosuid fs > behavior, it's always bugged me because it's not obvious to most > people. On second thought, a file-based check doesn't really help here, since the file label is untrusted in this scenario. So it only really makes sense to introduce another process permission if we want to distinguish transitions on nosuid from transitions under nnp, but that requires adding a process2 class. > > 2. It would mean that all domains could enable NNP, install seccomp > > filters (allowed for unprivileged processes if NNP is enabled), and > > execve a domain-changing program with those filters in effect, > > which > > could potentially lead to subverting the new domain. It is exactly > > for > > To make sure I understand, by subvert you mean the child domain > would > malfunction because of having less perms than required? > Not less perms, but changed behavior when it invokes system calls (based on the seccomp bpf filters). The callee could set up seccomp filters that will cause the newly executed program to be killed at arbitrary points, to invoke system calls with altered arguments, or to return from certain system calls without actually executing them. Seccomp filters are inherited across execve; safety is provided by requiring that the task that installs the filter either have NNP enabled or have CAP_SYS_ADMIN in its user namespace. > > this reason that domain transitions under NNP were originally not > > allowed, and then only allowed for bounded transitions. Also note > > that > > NNP is intended to be used to open up other previously unsafe > > actions > > for unprivileged processes, so this could be extended to more than > > just > > seccomp in the future (examples given in the past have included > > chroot, > > certain unshare/clone flags, etc, although it seems like some of > > this > > has been obsoleted/replaced by user namespaces). > > > > So from a safety POV, you really only want to allow this when the > > calling domain is more trusted than the callee domain; think of it > > as > > being similar (but not equivalent) to noatsecure and/or > > dyntransition. > > Perhaps then the permission should be named something like > nnp_nosuid_inh or inherit_nnp_nosuid or some variation thereof? It might make sense to separately introduce a seccompinh permission or similar to control whether seccomp filters can be inherited across a domain transition. That's independent of whether we allow transitions under NNP and/or nosuid. I'm starting to think it is a mistake to treat NNP and nosuid transitions the same way, given the differences above. And I think the only way I can support that sanely is by adding a process2 class. So maybe we just need to do that.
