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:
> > > On 07/18/2017 05:26 PM, Paul Moore wrote:
> > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote:
> > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote:
> > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@xxxxxxxxxxxxx>
> > > > > > > wrote:
> > > >
> > > > ...
> > > >
> > > > > > > > Why do we want to disallow type-bounds to work even with the
> > > > > > > > capability?
> > > > > > > > it seems sensible to me to allow typebounds to transition even in
> > > > > > > > the
> > > > > > > > future. If we do then we probably dont need the policycap which
> > > > > > > > seems
> > > > > > > > less complicated.
> > > > > > >
> > > > > > > The suggestion to continue to support bounded domain transitions
> > > > > > > seems
> > > > > > > reasonable to me, although we would need to worry about which check
> > > > > > > to
> > > > > > > do first (bounded transition or process:nnp_nosuid_transition), and
> > > > > > > how to limit the auditing/reporting so admins are confused by the
> > > > > > > first check failing, yet the transition still taking place. None
> > > > > > > of
> > > > > > > these are unsolvable problems, but it will likely need a bit more
> > > > > > > work.
> > > > > > >
> > > > > > > I'm sure Stephen has some thoughts on this as well.
> > > > > >
> > > > > > Others (e.g. Dominick) seemed to take the opposite view on the
> > > > > > earlier
> > > > > > RFC discussion, i.e. that we should only check the new permission if
> > > > > > the capability is enabled. I specifically raised that as a question
> > > > > > there.
> > > > > >
> > > > > > I'm willing to change it to fallback to checking for a bounded type,
> > > > > > but that will mean two audit messages (I don't think we can just hide
> > > > > > one of them) when neither is allowed. That said, it is unlikely to
> > > > > > cause much confusion in practice because users typically only look
> > > > > > for
> > > > > > and pay attention to AVC messages, and anyone using audit2allow will
> > > > > > just end up allowing the permission, not the bounds.
> > > > >
> > > > > As Jason noted, if we fallback to checking for a bounded type, then we
> > > > > don't strictly need a policy capability for it.
> > > >
> > > > It seems as though Dominick is okay with the fallback, what do the
> > > > rest of the policy folks think about that approach?
> >
> > I am okay with the faillback
> >
> > > >
> > > > I'm of the opinion that changes which don't require a new policy
> > > > capability are slightly more favorable, but since one of the goals
> > > > with this change is to make policy development easier, I want to make
> > > > sure we are actually doing that. It would appear we are, but a few
> > > > explicit nods from the policy folks would be nice to see.
> > >
> > > With my coder hat on, I can see the value of having the existing behavior be
> > > available for anyone who currently uses it, so it makes sense.
> >
> > I agree, its only that I believe that no one is using it because it is impractical (except for mod_selinux users, and people that currently use type_bounds to deal with nosuid),, mainly because the nnp flag is inherited.
> > The only scenario currently where, I believe, type_bounds might be prefered is containers since container process types do not change and the inheritance aspect is not much of a problem.
> >
> > >
> > > With my policy hat on, I don't have an opinion on a fallback. What I do
> > > know is I don't like typebounds, avoid it as much as possible, and strongly
> > > prefer it not be forced on me. There are no typebounds in refpolicy.
> > >
> > > In fact, I think NNP should not affecting SELinux at all as NNP is
> > > discretionary and SELinux is mandatory. NNP makes sense where you start out
> > > with lots of privileges and have to shed them, (i.e. the Linux
> > > DAC/capabilities perspective) whereas you have no privileges in SELinux
> > > except what is explicitly allowed.
> > >
> > > 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.
>
> In dssp2 i have this concept called forked subject types, basically these are systemd daemons *and* any processes types transitioned to by systemd daemons.
>
> These are rules specific for systemd (system) forked subject types*:
>
> [root@julius ~]# sesearch -A -t systemd.system.forked_subj_type_attribute -dt
> allow systemd.system.subj systemd.system.forked_subj_type_attribute:process { getsched setrlimit setsched };
>
> [root@julius ~]# sesearch -A -s systemd.system.forked_subj_type_attribute -ds
> allow systemd.system.forked_subj_type_attribute systemd.system.subj:fd use;
> allow systemd.system.forked_subj_type_attribute systemd.system.subj:unix_stream_socket { append bind connect getattr getopt ioctl read setattr setopt shutdown write };
>
> Here are some types of process types that are (potentially) associated with children of systemd system daemons (but arent daemons themselves):
>
> [root@julius ~]# for i in `seinfo -xasystemd.system.forked_subj_type_attribute`; do [[ $(seinfo -xt $i | grep "systemd.system.daemon_subj_type_attribute") ]] || echo $i | grep ".subj$"; done
> apache.rotatelogs.subj
> bootloader.subj
> chage.subj
> dracut.subj
> fuse.fusermount.subj
> iputils.subj
> kernel_install.subj
> kexec_tools.mkdumprd.subj
> loadkeys.subj
> logger.subj
> mysql.daemon.utils.subj
> nm_openvpn.subj
> notify.subj
> nspawn.generic_container.subj
> resolve.subj
> semodule.subj
> seutils.load_policy.subj
> seutils.setfiles.subj
> sysadm_systemd.subj
> tunctl.subj
> udisks.lvm.subj
> user_systemd.subj
> usermanage.groupadd.subj
> usermanage.useradd.subj
> wheel_systemd.subj
> xserver.subj
>
> So if i were to use the nnp_nosuid_transition permission then i would probably associate it with systemd.system.forked_subj_type_attribute
>
> * output might not be accurate due to limitations CIL/setools
By the way. If i am going to use nnp_nosuid_transition then am not going to "just" associate this permission. I am going to deal with this on a case by case basis.
In the systemd world this concept is very common. Systemd "potentially" needs to be able to do a lot of things to assets owned by its children. If you generalize this then you might as well make systemd unconfined.
Containing systemd is very expensive in terms of policy rules. I am starting to wonder whether it is even worth bothering.
It is not just the state today. Things still escalate. It is getting worse by the day.
>
> >
> > >
> > > --
> > > Chris PeBenito
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://secure-web.cisco.com/1A_WrTj3kAjkwuBmWXg6PuoiAjXyH8UU-z-ApV2MDP3SSs0P2YkubSRbbCGiWxhWgNW5klo0gJ7QkLGwI7-11-jTt1HK7ypKpW7DtXtM4yOgy0_5N5yjCh3Ow77XpHYfc97klOQlmQONWNDBLC8rWkav3UqnwZHYhXbRyCqUA6iaRo6dq3FnPFa9IGl_iQuKdoTF1_-lhkKf-NPcuCWzcdMELJKhoFAQjnj3eu2j053TxFKhnVi_vCMqnqub0qfS7cGjZLJ7lPioFySKJn4J23g/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://secure-web.cisco.com/1A_WrTj3kAjkwuBmWXg6PuoiAjXyH8UU-z-ApV2MDP3SSs0P2YkubSRbbCGiWxhWgNW5klo0gJ7QkLGwI7-11-jTt1HK7ypKpW7DtXtM4yOgy0_5N5yjCh3Ow77XpHYfc97klOQlmQONWNDBLC8rWkav3UqnwZHYhXbRyCqUA6iaRo6dq3FnPFa9IGl_iQuKdoTF1_-lhkKf-NPcuCWzcdMELJKhoFAQjnj3eu2j053TxFKhnVi_vCMqnqub0qfS7cGjZLJ7lPioFySKJn4J23g/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://secure-web.cisco.com/1A_WrTj3kAjkwuBmWXg6PuoiAjXyH8UU-z-ApV2MDP3SSs0P2YkubSRbbCGiWxhWgNW5klo0gJ7QkLGwI7-11-jTt1HK7ypKpW7DtXtM4yOgy0_5N5yjCh3Ow77XpHYfc97klOQlmQONWNDBLC8rWkav3UqnwZHYhXbRyCqUA6iaRo6dq3FnPFa9IGl_iQuKdoTF1_-lhkKf-NPcuCWzcdMELJKhoFAQjnj3eu2j053TxFKhnVi_vCMqnqub0qfS7cGjZLJ7lPioFySKJn4J23g/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
