In an attempt to harden my system, I implemented a lynis suggestion: Performing test ID AUTH-9328 (Default umask values) [03:13:53] Test: Checking /etc/profile [03:13:53] Result: file /etc/profile exists [03:13:53] Test: Checking umask value in /etc/profile [03:13:53] Result: found umask (prefixed with spaces) [03:13:53] Result: found umask 022, which could be more strict [03:13:53] Suggestion: Default umask in /etc/profile could be more strict like 027 [AUTH-9328] [03:13:53] Hardening: assigned 0 hardening points (max for this item: 2), current: 11, total: 18 And changed the /etc/profile umask from 022 to 027. Weeks later, I recompiled my kernel to add a module. I then found that the major external modules nvidia-drivers (ZFS related and virtualbox) would not compile. The nvidia-driver message is: test -e include/generated/autoconf.h -a -e include/config/auto.conf || (\ 000041 echo >&2;\ 000042 echo >&2 " ERROR: Kernel configuration is invalid.";\ 000043 echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ 000044 echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";\ 000045 echo >&2 ;\ After resetting those two file permissions, nvidia-drivers compiled a little further until it issues another warning about a file it could not read. I hate to waist dev time, but is this some kind of bug, or am I messing up? Alternatively, do I need to take additional steps (sandbox issue) to work around the a tighter umask? I did a web search/bug search by the way. Reproducible: Always
Hello Mark. From first view it seems like portage user didn't have access to /usr/src and thus it failed. The suggestion says, that it "could be more strict". But as I see you are doing it on a workstation. If you really want more security, I would recommend trying out Selinux or something similar.
