[Arm-dev] Wrong permissions on /etc/sysconfig/network-scripts

[Fabian Arrotin]

On 21/05/16 09:57, (GalaxyMaster) wrote:
> All,
> 
> On Sat, May 21, 2016 at 3:05 PM, (GalaxyMaster)
> <gm.outside+arm-dev at 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 at 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 at centos-rpi3 ~]# semanage export
> boolean -D
> login -D
> interface -D
> user -D
> port -D
> node -D
> fcontext -D
> module -D
> [root at centos-rpi3 ~]# audit2why -b
> <no matches>
> [root at 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 at 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-447eb2193fd92db5a65be9cae5a6f95c3546605b)

-- 
Fabian Arrotin
The CentOS Project | http://www.centos.org
gpg key: 56BEC54E | twitter: @arrfab


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20160521/bbaab49a/attachment.sig>