On Thu, 16 Jul 2020, Yi Zhao wrote: > > On 7/15/20 6:38 PM, Scott Murray wrote: > > On Wed, 15 Jul 2020, Yi Zhao wrote: > > > >> On 7/15/20 12:19 AM, Scott Murray wrote: > >>> On Tue, 7 Jul 2020, Yi Zhao wrote: > >>> > >>>> Here is the changelog for this is patchset: > >>>> > >>>> * Drop refpolicy 2.20190201 > >>>> If we still keep two versions of refpolicy, it is difficult to > >>>> maintain > >>>> two huge local patchsets. So drop this version and only keep the git > >>>> version. > >>>> > >>>> * Add patches to make systemd/sysvinit can work with all policy types. > >>>> > >>>> Here are the results with this patcheset: > >>>> > >>>> Machine: qemux86-64 > >>>> Image: core-image-selinux > >>>> Init manager: sysvinit and systemd > >>>> Policy types: minimum, targeted, standard, mcs, mls > >>>> Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1 > >>>> enforcing=1" qemuparams="-m 1024" > >>>> > >>>> 1. All refpolicy type can be built without problems. > >>>> > >>>> 2. With parameter selinux=1 & enforcing=1 > >>>> The qemu can boot up and login with all policy types. > >>> [snip] > >>> > >>> I suspect I'm really missing something, but I'm unable to successfully > >>> make this work with poky + meta-selinux and its meta-openembedded > >>> dependencies with either sysvinit or systemd; I see denials on boot and > >>> cannot log in due to denials on reading /etc/passwd. That's also the > >>> behavior I see without this update, so I'm wondering if I'm just doing > >>> something significantly wrong with respect to configuration. My > >>> local.conf additions for testing are just: > >>> > >>> DISTRO_FEATURES_append = " selinux" > >> > >> Please set the following DISTRO_FEATURES: > >> > >> DISTRO_FEATURES_append = " acl xattr pam selinux" > > Ah, poky is missing "pam", I somehow missed that when I checked > > previously. I can get logged in when I add it and rebuild. It likely > > would make sense to use the check_features class in e.g. > > core-image-selinux to catch this. Would you be okay with a patch that > > does so? > > Thanks. It makes sense. I can send a patch later or you can also do it.
I'll look at it on the weekend and see about getting a patch posted. > >> If you see some AVC denials for {map} like below: > >> > >> avc: denied { map } for pid=249 comm="dbus-daemon" path="/etc/passwd" > >> dev="vda" ino=345 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > >> tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 > >> avc: denied { map } for pid=319 comm="avahi-daemon" path="/etc/passwd" > >> dev="vda" ino=345 scontext=system_u:system_r:avahi_t:s0 > >> tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 > >> avc: denied { map } for pid=379 comm="login" path="/etc/passwd" > >> dev="vda" > >> ino=345 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 > >> tcontext=system_u:object_r:etc_t:s0 tclass=file permissive=0 > >> > >> They are harmless. > > Having spurious denials seems like it would make using them for detecting > > actual bad behavior harder, I'll likely start looking at the policy to > > see if some of this can be fixed. > > For this issue, there is a discussion in > http://oss.tresys.com/pipermail/refpolicy/2017-September/009865.html > > Actually I saw lots of map denials on /etc/passwd or /etc/group for various > commands. I'm not sure if we should allow them all via > files_map_etc_files(domain) or dontaudit them ... Okay. I plan to research this further, worse comes to worst I'll carry a policy patch locally. Scott
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49986): https://lists.yoctoproject.org/g/yocto/message/49986 Mute This Topic: https://lists.yoctoproject.org/mt/75351492/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-