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.
//Yi
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 ...
//Yi
Thanks,
Scott
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#49963): https://lists.yoctoproject.org/g/yocto/message/49963
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]
-=-=-=-=-=-=-=-=-=-=-=-
