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 <s...@tycho.nsa.gov> > > > 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 <ja...@perfinion.com> > > > > > > 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
signature.asc
Description: PGP signature
