Hello,
I'm new here and I'm quite happy to discover that there is an effort to port CentOS 7 to ARM.
I've just downloaded the image, put it onto the card and booted up my Pi3 from it. The following I noticed right away: === [root@centos-rpi3 ~]# rpm -V initscripts .....UG.. /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# ls -ld /etc/sysconfig/network-scripts drwxr-xr-x. 2 1000 1000 4096 Nov 27 16:23 /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# chown -h root:root /etc/sysconfig/network-scripts [root@centos-rpi3 ~]# rpm -V initscripts [root@centos-rpi3 ~]# ===
It is still my first 10 minutes with Pi3 and CentOS 7 on it, but given my background I think I'll be a regular here and would able to contribute from Ops and InfoSec perspective, if there is such need.
For example, I think we can do much better in terms of a minimal CentOS 7 and we should be able to enforce SELinux. I'm going investigate on both and once I'm ready I will share :)
P.S. In any case, I'm very grateful for all your effort for bringing this project to life!
Hello,
On Fri, May 20, 2016 at 8:35 PM, (GalaxyMaster) gm.outside+arm-dev@gmail.com wrote:
I've just downloaded the image, put it onto the card and booted up my Pi3 from it. The following I noticed right away:
Looked a bit further and it looks that whoever set the system up was not careful enough with the ownership of directories/files: === [root@centos-rpi3 /]# find / -xdev ( -nouser -o -nogroup ) -ls 19531 4 drwxr-xr-x 2 1000 1000 4096 Nov 27 16:23 /etc/rbf 19538 4 -rw-r--r-- 1 1000 1000 92 Mar 15 16:20 /etc/rbf/board.xml 448 4 drwxr-xr-x 6 1000 1000 4096 May 20 10:51 /etc/sysconfig 348 4 -rw-rw-r-- 1 1000 1000 198 Mar 15 16:20 /etc/fstab 349 4 -rw-rw-r-- 1 1000 1000 11 Mar 15 16:20 /etc/hostname [root@centos-rpi3 /]# ===
These all should be owned by root:root and permissions for directories should be 0755 while files should be 0644. It would be really great if the image could do it right.
Is there a defined way to contribute to the build system and the process of releasing the image, by the way?
-- (GM)
On 20/05/16 13:07, (GalaxyMaster) wrote:
Hello,
On Fri, May 20, 2016 at 8:35 PM, (GalaxyMaster) gm.outside+arm-dev@gmail.com wrote:
I've just downloaded the image, put it onto the card and booted up my Pi3 from it. The following I noticed right away:
Looked a bit further and it looks that whoever set the system up was not careful enough with the ownership of directories/files: === [root@centos-rpi3 /]# find / -xdev ( -nouser -o -nogroup ) -ls 19531 4 drwxr-xr-x 2 1000 1000 4096 Nov 27 16:23 /etc/rbf 19538 4 -rw-r--r-- 1 1000 1000 92 Mar 15 16:20 /etc/rbf/board.xml 448 4 drwxr-xr-x 6 1000 1000 4096 May 20 10:51 /etc/sysconfig 348 4 -rw-rw-r-- 1 1000 1000 198 Mar 15 16:20 /etc/fstab 349 4 -rw-rw-r-- 1 1000 1000 11 Mar 15 16:20 /etc/hostname [root@centos-rpi3 /]# ===
These all should be owned by root:root and permissions for directories should be 0755 while files should be 0644. It would be really great if the image could do it right.
Is there a defined way to contribute to the build system and the process of releasing the image, by the way?
-- (GM)
Thanks for your report. I had a quick look and it's due to the tool used to generate the RootFS. I'll try to modify it in the post-scripts that are launched after the RootFS creation to modify those back to default owner:group. You can find the original version here : https://github.com/mndar/rbf while I was using the forked version here : https://github.com/arrfab/rbf
WRT selinux, you've probably seen that there isn't even an upstream kernel from rpi supporting selinux. With some efforts, we were able to add the required config (and so the kernel that we build/ship supports selinux) but then it conflicts with the default el7 policy (the way that specific kernel is allocating memory). That's the reason why the current rpi3 has selinux in permissive mode.
Fabian,
On Fri, May 20, 2016 at 9:30 PM, Fabian Arrotin arrfab@centos.org wrote:
WRT selinux, you've probably seen that there isn't even an upstream kernel from rpi supporting selinux. With some efforts, we were able to add the required config (and so the kernel that we build/ship supports selinux) but then it conflicts with the default el7 policy (the way that specific kernel is allocating memory).
If I understand it correctly, it has nothing to do with SELinux LSM, but a misconfiguration of the kernel source. The only issue that prevents SELinux from being enforced on the image we have is that binaries are trying to do mmap_zero() calls and this goes against the SELinux default policy. The most likely cause for this is a misconfiguration of LSM_MMAP_MIN_ADDR -- most likely it is (mis)configured to be 64K instead of 32K (See: http://cateee.net/lkddb/web-lkddb/LSM_MMAP_MIN_ADDR.html).
That's the reason why the current rpi3 has selinux in permissive mode.
No, the reason is most likely that people are blindly building kernels from the same source tree without verifying whether configuration suits the target system, in my opinion. 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.
Fabian,
On Sat, May 21, 2016 at 3:05 PM, (GalaxyMaster) gm.outside+arm-dev@gmail.com wrote:
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.
I've looked into the SRPM for the kernel and I found that I was indeed correct: === From: Fabian Arrotin <arrfab "we-do-not-want-spammers-here" armv7-01.dev.centos.org> Date: Tue, 15 Mar 2016 13:48:56 +0000 Subject: [PATCH] Added selinux support
--- arch/arm/configs/bcm2709_defconfig | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/arch/arm/configs/bcm2709_defconfig b/arch/arm/configs/bcm2709_defconfig index 39f9a11..824bf1a 100644 --- a/arch/arm/configs/bcm2709_defconfig +++ b/arch/arm/configs/bcm2709_defconfig @@ -1265,3 +1265,23 @@ CONFIG_CRYPTO_SHA512_ARM_NEON=m CONFIG_CRYPTO_AES_ARM_BS=m CONFIG_CRC_ITU_T=y CONFIG_LIBCRC32C=y +CONFIG_AUDIT=y [skipped] +CONFIG_LSM_MMAP_MIN_ADDR=65536 [skipped] +CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 ===
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)
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...)
Looked a bit further and it looks that whoever set the system up was not careful enough with the ownership of directories/files: === [root@centos-rpi3 /]# find / -xdev ( -nouser -o -nogroup ) -ls 19531 4 drwxr-xr-x 2 1000 1000 4096 Nov 27 16:23 /etc/rbf 19538 4 -rw-r--r-- 1 1000 1000 92 Mar 15 16:20 /etc/rbf/board.xml 448 4 drwxr-xr-x 6 1000 1000 4096 May 20 10:51 /etc/sysconfig 348 4 -rw-rw-r-- 1 1000 1000 198 Mar 15 16:20 /etc/fstab 349 4 -rw-rw-r-- 1 1000 1000 11 Mar 15 16:20 /etc/hostname
Thanks for pointing out the problem. This is something I'll have to fix in RootFS Build Factory. I've used "cp -rpv ./etc/* /tmp/temp/etc/" to copy the entire etc overlay for an image. This part of the code needs changes. I'll be done with my final year exams at the end of this month. Will fix it then.
These all should be owned by root:root and permissions for directories should be 0755 while files should be 0644. It would be really great if the image could do it right.
Fabian, I've fixed this issue. Changes are in the https://github.com/mndar/rbf
-
(GalaxyMaster) -
Fabian Arrotin -
Mandar Joshi