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.
madaidan via Whonix Forum:
Merged.
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?
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.
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”.
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.
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.
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?
Anything here that anthraxx or ClipOS can readily pick up?
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.
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.
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
madaidan via Whonix Forum:
Merged.
We can change CONFIG_CMDLINE (requires CONFIG_CMDLINE_BOOL=y) to default to our security-misc boot parameters although most are solved by the config anyway.
@Patrick can you create hardened-kernel so I can add documentation? I don’t have permissions to create it.
Done.
Btw if you edit with account I could upgrade that.
That seems rather inflexible.