| View previous topic :: View next topic |
| Author |
Message |
wuger
n00b
Joined: 22 Nov 2024
Posts: 3
|
 Posted: Fri Nov 22, 2024 7:56 pm Post subject: Fresh Install: amd64/23.0/musl/hardened/selinux profile swap |
 |
|
Hello,
I am wanting to configure an amd64 machine using musl with a kernel configured to follow the KSPP recommendations (no-multilib). As this is just a fun vector for me to learn more about systems, I figured it was time I wrapped my head around SELinux in accordance with KSPP.
Upon evaluating the different stages and profiles, I noticed there was no stage3 configured for musl/hardended/selinux. Upon searching threads in the forum and other discussion hosts, I determined the best route would be to start with the amd64-musl-hardened stage3 installation and add SELinux according to the steps outlined here. Installation went smoothly, I hardened the kernel following the lovely tutorials from Pietinger, confirmed that my kernel adhered to app-admin/kernel-hardening-checker's checks (not including SELinux), however I have reached an impasse when attempting to switch profiles.
I am booted into my kernel, and followed the steps outlined in the aforementioned SELinux installation guide up until the merging of sec-policy/selinux-base instructed here. For more specific context, I currently have the "default/linux/amd64/23.0/musl/hardened/selinux" profile selected, but have not rebuilt world using it.
[/i]
The issue arises when building the sys-process/audit package, a dependency of selinux-base
| Code: |
make[4]: *** [Makefile:740: audisp_remote-audisp-remote.o] Error 1
make[4]: Leaving directory '/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1-abi_x86_64.amd64/audisp/plugins/remote'
make[4]: Entering directory '/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1-abi_x86_64.amd64/audisp/plugins/remote'
x86_64-pc-linux-musl-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/audisp/plugins/remote -I../../.. -I/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1 -I/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/lib -I/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/common -fPIE -DPIE -g -D_REENTRANT -D_GNU_SOURCE -Wundef -Wno-format-truncation -Wno-unused-but-set-variable -march=skylake -O2 -pipe -c -o audisp_remote-remote-config.o `test -f 'remote-config.c' || echo '/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/audisp/plugins/remote/'`remote-config.c
make[4]: Leaving directory '/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1-abi_x86_64.amd64/audisp/plugins/remote'
make[3]: *** [Makefile:412: all-recursive] Error 1
make[2]: *** [Makefile:545: all-recursive] Error 1
make[1]: *** [Makefile:467: all-recursive] Error 1
make: *** [Makefile:399: all] Error 2
* ERROR: sys-process/audit-4.0.1-r1::gentoo failed (compile phase):
* emake failed
|
I found a bug on this version of this package reported a couple of months ago, which was confirmed but never resolved, however it seems to be using glibc and was related to the tests for auparse rather than audisp where the error is rising in my case. I do have earlier warning related to auparse:
| Code: |
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/../lib/gen_tables.c:89:22: warning: overflow in conversion from 'long long unsigned int' to 'int' changes value from '4294967296' to '0' [-Woverflow]
89 | #define _S(VAL, S) { (VAL), (S), 0, 0 },
| ^
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/clone-flagtab.h:47:1: note: in expansion of macro '_S'
47 | _S(0x100000000ULL, "CLONE_CLEAR_SIGHAND")
| ^~
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/../lib/gen_tables.c:89:22: warning: overflow in conversion from 'long long unsigned int' to 'int' changes value from '8589934592' to '0' [-Woverflow]
89 | #define _S(VAL, S) { (VAL), (S), 0, 0 },
| ^
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/clone-flagtab.h:48:1: note: in expansion of macro '_S'
48 | _S(0x200000000ULL, "CLONE_INTO_CGROUP")
| ^~
|
followed by:
| Code: |
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/auparse.c: In function 'strndupa':
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/auparse.c:1203:16: warning: function returns address of local variable [-Wreturn-local-addr]
1203 | return memcpy(tmp, old, len);
| ^~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/stdlib.h:140,
from /var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/auparse.c:32:
/var/tmp/portage/sys-process/audit-4.0.1-r1/work/audit-4.0.1/auparse/auparse.c:1201:21: note: declared here
1201 | char *tmp = alloca(len + 1);
| ^
|
Things I tried:
Allowing the unstable audit package 4.0.2 - However I seem to be running into this bug, my output is very similar, however the reporter here is also using glibc so I am not so sure if the issue from 4.0.1-r1 is related/fixed even when this bug gets resolved.
Switching python versions - The issue doesn't seem to be python related, but I figure I would mention it anyway.
Booting into the SELinux enabled kernel - the guide for SELinux install doesn't explicitly state to reboot into the newly configured kernel before doing this oneshot install, however I decided to give it a try netting no noticed change in output.
Searching upstream - There doesn't seem to be any musl specific issues open or documented at all.
Refocusing:
I know this is an experimental profile and simply doesn't have many testing it, so I am not really expecting a simple process that will resolve this, however I would like to get some pointers on how to better tackle issues like this in the future in the context of gentoo.
Am I fundamentally misunderstanding anything here?
Is this process the best route to achieving a SELinux hardened musl system?
What other steps can I take to resolve this?
It seems odd to my naive self that the bug reported back in August was confirmed but never resolved. Is this because it was only found in a test and wasn't subsequently reported by any users?
Let me know if I can provide anymore context! |
|
| Back to top |
|
 |
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1258
Location: Richmond Hill, Canada
|
| Posted: Fri Nov 22, 2024 8:44 pm Post subject: |
|
|
IMHO there may be logical step (in term of thoughts) need to rearrange.
you mention you successfully got a kernel/rootfs/SELinux with arm64-musl-hardended stage3 to state you like. Then you want to switch profile. In my mind I will stay with the profile you succeed and select a profile (i.e. default/linux/arm64/23.0/musl/hardened/selinux) just view its setting (Not switching profile) and use those setting and test setup. Once you achive a working condition to your like. You then either make a local profile or report a bug indicate what need to adjust in order to success for the target profile.
A Gentoo Profile, is bunch of USE flags and mask of package versions as well as some specific must have packages to meet the profile definition. So my suggestion is not switch profile before you have working thingy.
In essence I am suggesting a process debug a Gentoo profile. |
|
| Back to top |
|
|
wuger
n00b
Joined: 22 Nov 2024
Posts: 3
|
| Posted: Fri Nov 22, 2024 10:14 pm Post subject: |
|
|
| pingtoo wrote: | | A Gentoo Profile, is bunch of USE flags and mask of package versions as well as some specific must have packages to meet the profile definition. So my suggestion is not switch profile before you have working thingy. |
Point noted here. Looking into /var/db/gentoo/profiles/features/selinux I am now seeing the mass amount of changes being made to the environment. This gives me a good chain of breadcrumbs to follow if running into other problems in the future.
Unfortunately, re-selecting my previous profile default/linux/amd64/23.0/musl/hardened gives the same output for sys-process/audit-4.0.1-r1, so I doubt it is one of these introduced USE flags which is causing grief. The only difference from my understanding is the "python" USE flag on sys-process/audit (which selinux-base would need anyway). |
|
| Back to top |
|
|
pingtoo
Veteran
Joined: 10 Sep 2021
Posts: 1258
Location: Richmond Hill, Canada
|
| Posted: Fri Nov 22, 2024 10:51 pm Post subject: |
|
|
wuger,
I understand. What done is done, there is no easy to reverse.
I am no expert in this area (selinux/hardened) but I like to help to see if I can sport something that I know how.
The post that have the build error is not complete. It only show last part of build.log. So please follow the end of emerge message, there suggest several output should be shared.
You can use try wgetpaste if you are not able to post logs in forums. |
|
| Back to top |
|
|
wuger
n00b
Joined: 22 Nov 2024
Posts: 3
|
| Posted: Fri Nov 22, 2024 11:41 pm Post subject: |
|
|
| pingtoo wrote: | | You can use try wgetpaste if you are not able to post logs in forums. |
Neat tool! Your inquiry here made me look at the build logs closer and I determined it was due to a missing header which was fixed in the v3.x chain, but reintroduced in 4.0.1.
Here is the upstream github issue for full recording of this issue's sake. It claims this patch in regards to musl compilation was reintroduced in 4.0.2.
To my luck, as we were conversing here, it seems the 4.0.2 bug was resolved. I synced with the latest repo and am now getting a successful build for 4.0.2-r1. Yahoo! 
With all this said, it seems the musl/hardened/selinux profile needs to force usage of audit-4.0.2-r1 in order to build the namesake package of the profile, "selinux-base". Is this something I should report somewhere? The way I am currently fixing this is by adding line "sys-process/audit ~amd64" in /etc/portage/package.accept_keywords, but by doing this I am essentially accepting usage of the latest unstable/stable version of this package upon updating this package correct? Is there a more stable way of doing this? Would I need to make a modified ebuild of sec-policy/selinux-base to select for the 4.0.2-r1 version of audit essentially?
Thank you for illuminating some flaws in my thought chain! Sometimes I guess it is best to just wait it out or at the very least be more critical of my own build logs  |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Installing Gentoo
