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]
-=-=-=-=-=-=-=-=-=-=-=-
