Could we acquire kernel sources from CLIP OS?
2 Likes
In other words, CLIP OS is missing out on some kernel hardening config options? If yes, could you please point that out in Hardened Kernel Config File for Virtual Machines (VMs) ("cloud kernel") and Hosts · Issue #38 · clipos/bugs · GitHub?
2 Likes
Why? The kernel source is just vanilla and then they apply linux-hardened and the STACKLEAK patch.
That’s not what I mean. They have the hardening options already in src_platform_config-linux-hardware/kernel_config/security/basic at master · clipos/src_platform_config-linux-hardware · GitHub and src_platform_config-linux-hardware/kernel_config/blacklist at master · clipos/src_platform_config-linux-hardware · GitHub
By “doesn’t have a full hardened config”, I mean they don’t have a full kernel config in general due to parts needing to be done manually, not that they’re missing out on hardening options.
1 Like
madaidan via Whonix Forum:
Why? The kernel source is just vanilla and then they apply linux-hardened and the STACKLEAK patch.
Then no patch needs to be applied against Whonix/hardened-kernel. Can
just use CLIP OS repository. Any modifications would be gotten
automatically by us - no need to manually stay on top. If we follow CLIP
OS as upstream (since they are using vanilla + linux-hardened +
STACKLEAK patch) it makes sense to use them as upstream.
I.e.
option A) Whonix/hardened-kernel = linux-hardened + STACKLEAK patch
option B) Whonix/hardened-kernel = CLIP OS kernel sources
The latter being fully complete already. Seems simpler.
That’s not what I mean. They have the hardening options already in src_platform_config-linux-hardware/kernel_config/security/basic at master · clipos/src_platform_config-linux-hardware · GitHub and src_platform_config-linux-hardware/kernel_config/blacklist at master · clipos/src_platform_config-linux-hardware · GitHub
By “doesn’t have a full hardened config”, I mean they don’t have a full kernel config in general due to parts needing to be done manually, not that they’re missing out on hardening options.
I see. And we’re not using CLIP OS because we don’t want users to do
manual parts?
(Really ought to avoid manual configuration. Really bad usability for
our target audience.)
I.e. the missing feature by upstream CLIP OS is a fully pre-configured
kernel config that does not require manual user input?
2 Likes
It would be better to just apply the patches before compiling rather than needing to trust a third party to apply them for us.
And besides, CLIP OS uses non-LTS kernels AFAIK.
Yes, manually creating your own config is a massive pain. It’s extremely easy to severely worsen security and/or break everything. Only really advanced users should.
Yes.
1 Like
1 Like
madaidan via Whonix Forum:
Merged.
2 Likes
madaidan via Whonix Forum:
It would be better to just apply the patches before compiling rather than needing to trust a third party to apply them for us.
And besides, CLIP OS uses non-LTS kernels AFAIK.
Another reason to re-consider using non-LTS too.
I consider applying a patch against a different version becoming a new
upstream too. A patch very much depends on the context of the
surrounding code. Often patches cannot be applied for older/newer
versions since the base file changed. Even if it applies, it might not
be advisable. The patch author must state against which versions that
patch was tested.
The link to the patch was
https://github.com/vmware/photon/blob/master/SPECS/linux/01-clear-linux.patch
That is interesting.
They have many more patches.
Part of this project.
Quote:
Security hardened: The kernel and other aspects of the operating
system are built with an emphasis on security.
What photon be suitable as an upstream for kernel patches / kernel config?
2 Likes
madaidan via Whonix Forum:
Instead of the complexity of all those wrappers, maybe we could just use a bash alias?
alias apt="hdapt" alias apt-get="hdapt"
I still don’t know yet. Created ⚓ T960 hardened kernel Debian packaging and APT integration - hkapt for it.
Doesn’t seem much less complex either way wrappers vs bash alias.
hdapt, not sure why I wrote that. hd what? Should be hkapt for hardened
kernel apt? My mistake.
Either way, hkapt could be developed independently. Wrappers could be
solved last.
rapt runs
aptwhich if hardened-kernel is being used would be an alias ofhdapt. If not using hardened-kernel, it would be realapt.
rapt runs as root. It ought to not parse anything in user’s home folder.
(Bash alias are run in user ~/.bashrc.)
There is no /etc/bashrc.d yet.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675008
Therefore would probably have to take over (config-package-dev displace)
some system file which doesn’t lower complexity either.
bash aliases are probably ignored when apt is called by another tool
internally (such as for scripting / automating, whatnot).
We instruct users to use
raptwhen using apparmor-profile-everything and justaptwhen not.
One day apparmor-profile-everything hopefully becomes a default.
Therefore ideally it wouldn’t need a new command to teach all users.
1 Like
Why should we base everything off of not having to run 1 extra patch command?
I don’t see why we need to switch upstreams. Using kernel.org and cat ... | patch is perfectly fine.
No, photon is just an OS optimized for vmware. They only have a few extracted PaX features I pointed out above.
I assumed “hd” was short for “hardened”.
2 Likes
I’ve ported this and will send it to linux-hardened. It denies all read-write mounts and writes to block devices once kernel.romount_protect=1 is set. It cannot be changed back during runtime.
We just need to figure out when to set this and how.
1 Like
2 Likes
From the results of GitHub - a13xp0p0v/kconfig-hardened-check: A tool for checking the security hardening options of the Linux kernel, the only things we can really improve now are (excluding things not in our kernel version, SLUB_DEBUG_ON as it doesn’t help, LOADPIN as we aren’t using it, USER_NS as linux-hardened fixes that issue and modules as we’re working on that):
option name | desired val | decision | reason | check result
=========================================================================================================================
CONFIG_STATIC_USERMODEHELPER | y | clipos | self_protection | FAIL: "is not set"
CONFIG_KALLSYMS | is not set | clipos | cut_attack_surface | FAIL: "y"
CONFIG_MAGIC_SYSRQ | is not set | clipos | cut_attack_surface | FAIL: "y"
CONFIG_BPF_JIT | is not set | my | cut_attack_surface | FAIL: "y"
CONFIG_STATIC_USERMODEHELPER would be very useful but this breaks boot for some unknown reason and leaves me with a black screen although we can use LKRG’s umh_lock instead if the issues with the firewall are ever fixed.
Disabling CONFIG_KALLSYMS isn’t that helpful since we set kptr_restrict but it would reduce attack surface.
Disabling CONFIG_MAGIC_SYSRQ isn’t that helpful either as we’re going to restrict SysRq.
The only really useful one is a static usermode helper.
2 Likes
Would be helpful to document this on the wiki so users running the hardening check script don’t come in here and ask "why is X not enabled in your kernel but done in ClipOS?
2 Likes
Anything here that anthraxx or ClipOS can readily pick up?
2 Likes
Dapper is just a forward port of grsec. I don’t think they’ve added any new features and I’m already combing over the original grsec patch anyway.
2 Likes
Yes I know. I was wondering if stuff like RAP can be easily ported forward and integrated by either of these projects because it hasn’t succumbed to bitrot yet.
2 Likes
Not easily. RAP is a very large feature. Porting it would be hard.
Besides, the full version was never publicly released, only a subset of its features were part of the public patch grsecurity
We should just wait until clang CFI is upstream https://outflux.net/slides/2020/lca/cfi.pdf
2 Likes
madaidan via Whonix Forum:
Merged.
1 Like