On 21/05/16 09:57, (GalaxyMaster) wrote:
All,
On Sat, May 21, 2016 at 3:05 PM, (GalaxyMaster) gm.outside+arm-dev@gmail.com wrote:
If I understand it correctly, it has nothing to do with SELinux LSM, but a misconfiguration of the kernel source. [...]
[skipped]
[...] Anyway, I'm going to build a kernel that matches the hardware and we will see whether it would help. For your builds, however, I'd suggest to adjust LSM_MMAP_MIN_ADDR to 32768 or even lower, like 16384. This will likely make your build be able to run in the enforcing mode with the default CentOS 7 targeted policy.
P.S. Will update once my Pi3 is running in the enforced mode of SELinux.
Confirmed, a kernel rebuilt with LSM_MMAP_MIN_ADDR set to 32768 works with the default targeted SELinux policy with no issues: === Last login: Sat May 21 07:42:30 2016 from home.fritz.box [root@centos-rpi3 ~]# uname -a Linux centos-rpi3 4.1.19-v7 #1 SMP Sat May 21 07:09:33 UTC 2016 armv7l armv7l armv7l GNU/Linux [root@centos-rpi3 ~]# semanage export boolean -D login -D interface -D user -D port -D node -D fcontext -D module -D [root@centos-rpi3 ~]# audit2why -b
<no matches> [root@centos-rpi3 ~]# sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 29 [root@centos-rpi3 ~]# ===
I'm not going to dump the output of semodule -l, but trust me there are no custom modules. My goal is to bring this image as close to the official CentOS7 as possible.
Now, a question: why did we deviate from CentOS7's default kernel (which at this particular moment is 3.10.0-327.18.2.el7)? If the project is to port CentOS7 to Pi3 I'd suggest to keep inline with the upstream since there may be incompatible changes in the interface (e.g. I recall there was one such change in 3.* series which broke strace and other binutils tools).
-- (GM)
Great news and good finding ! Thanks for this
I guess we can rebuild the kernel by changing the initial patch then. I also had a quick look at the rpi kernel source tree and it seems they rebased to 4.4.x so wondering if that's not a good time to also bump to that release. To answer your question about el7 default : it doesn't support armhfp by default (as there is no upstream EL7 kernel for this) , and even el7 aarch64 deviates from the 3.10.0 kernel. So it was decided to stick to Fedora kernel when possible, but also rebuild directly specific kernel when needed : RPI is such an example as even the upstream kernel doesn't support the rpi (I was told that it would probably be the case for 4.5 but haven't followed closely) That's also the reason why we call the armhfp release "CentOS 7 userland", because kernel differs from the CentOS 7 x86_64 (see https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32#head-447eb2193fd9...)