On Thu, 16 Jul 2020, Yi Zhao wrote:
>
> On 7/16/20 11:27 AM, 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.
> >
> >>
> >>> 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.
>
> You can install auditd into the rootfs and startup the daemon to let the
> denials messages write to audit.log rather than print to the console.
Yes, but ideally I'd like to not have to filter a bunch of spam from the
auditd logs to have them be useful for potential incident detection. As I
mentioned on my other reply, I plan to look into it further and likely
will just carry a policy patch locally if it's reasonable to work out one.
Scott
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49987): https://lists.yoctoproject.org/g/yocto/message/49987
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]
-=-=-=-=-=-=-=-=-=-=-=-
