Awesome initiative! Another alternative or additional enhancement could
be a wrapper script. mount is really powerful with lots of command
line options which I don’t even know all. First step could be for a
script to record all invocations of mount / umount ( / others? ) and
to pass to the real mount command unfiltered. That is to get a survey on
how it is being used in legitimate ways. A “passthrough mode”. Next step
could be adding a filtering mode where command line options and/or
parameters are restricted. I.e. no longer possible to mount anything on
anything with any mount option.
1 Like
That wouldn’t work as mount isn’t just a program. It’s also a syscall (/bin/mount uses this syscall) so an attacker can just create their own program to abuse it.
1 Like
We might want to add this to our kernel once our version catches up with STACKLEAK. This patch was part of the original STACKLEAK patch series sent upstream but it was dropped because all VLAs were removed from the kernel so it had no purpose anymore. It’d only be useful for out-of-tree code or as a fail-safe incase VLAs are reintroduced although that’s unlikely and even more so for an LTS kernel.
There’s also these extracted PaX features we can use:
https://github.com/vmware/photon/blob/master/SPECS/linux/0002-Added-PAX_RANDKSTACK.patch
https://github.com/vmware/photon/blob/master/SPECS/linux/0003-Added-rap_plugin.patch
Although it might be better to wait til S.A.R.A., CONFIG_RANDOMIZE_KSTACK_OFFSET and clang CFI are upstream.
2 Likes
We also need to prevent the init_on_free=1 init_on_alloc=1 / page_poison=1 slub_debug=P boot parameters from being set as we’re using linux-hardened’s CONFIG_PAGE_SANITIZE / CONFIG_SLAB_SANITIZE instead.
2 Likes
Can you please add this to a phab ticket? By the time kernel 5+ rolls around this megathread will be at least a thousand posts and your finding s will be buried.
2 Likes
I appropriate the effort but I cannot review C code, let alone kernel code. Unless another qualified Whonix team member joins the project and does such reviews (which may not be likely), I don’t want to merge it. It would be irresponsible of me if I merged code that I don’t understand.
Therefore this must go through a skilled upstream. I don’t want to become the host (upstream) of it. Any of Debian, linux-hardened and/or CLIP OS seem suitable. [1] Others possibly to if any exist. Another option could be to become upstream yourself and becoming the new Libre grsecurity alternative, hardened kernel.
Also even if I could review kernel patches, I think it’s much too early to focus on something as advanced as that. There’s still a ton to do related to packaging and integration work to do before this gets ready for wide testing / installation by default.
[1] I am aware of the previous discussion on LTS vs stable kernel but perhaps this needs to be reconsidered if there is no upstream that wants to merge security enhancement patches for Linux LTS.
1 Like
Reminds me… Can’t we benefit from CLIP OS kernel config generation and/or hardened kernel sources? Is it only about ^[1]?
(Well, CLIP OS is based on hardened gentoo. That would still leave packaging and integration work left to do but maybe helpful nonetheless as this at least provides C/kernel code reviewers.)
2 Likes
The STACKLEAK patch was sent and reviewed by upstream linux. It’s already being used by CLIP OS hence why the commit is in their repo.
The extracted PaX features are hosted by vmware.
We can do that with hardened-kernel.
CLIP OS doesn’t have a full hardened config. They’ve a few config options split up in various files. When creating the config, they’re added together and the rest (e.g. hardware configuration) is done manually.
The only hardening-related options are 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 and there isn’t much we don’t already have.
CLIP OS doesn’t really maintain many kernel patches themselves (except the STACKLEAK one talked above), they just use linux-hardened currently.
2 Likes
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