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
>
> >
> > --
> > Chris PeBenito
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://secure-web.cisco.com/1p1yJD5SgewwVGBgT_zKJkJvFL8qog155yQggcavHJLjq48wjbhNA8aQVb-yKQytK0gkNSJhEmUqMNd7ObjKqKswecjvBELF3FoljHWmV5zG0pB2nieTMCq4GE3au_YNQm5K0alYZfpAYKBkjlB_W_Ggozlt-y4ubCZAZslUDrFPKKKD8bt3id7r7bbLHxRm9YHUfoGFUUIkGL_yDuJL3Sl1eg0m10DIZooifM6xADBJLIcRPkSRgIK2740270KkcloQimp3iGjxZS04dN6GpqA/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/1p1yJD5SgewwVGBgT_zKJkJvFL8qog155yQggcavHJLjq48wjbhNA8aQVb-yKQytK0gkNSJhEmUqMNd7ObjKqKswecjvBELF3FoljHWmV5zG0pB2nieTMCq4GE3au_YNQm5K0alYZfpAYKBkjlB_W_Ggozlt-y4ubCZAZslUDrFPKKKD8bt3id7r7bbLHxRm9YHUfoGFUUIkGL_yDuJL3Sl1eg0m10DIZooifM6xADBJLIcRPkSRgIK2740270KkcloQimp3iGjxZS04dN6GpqA/https%3A%2F%2Fsks-keyservers.net%2Fpks%2Flookup%3Fop%3Dget%26search%3D0x3B6C5F1D2C7B6B02
Dominick Grift
Attachment:
signature.asc
Description: PGP signature
