51–56 of 56 posts
OpenBSD has removed loadable kernel modules back in 2014; macOS is aggressively moving in the same direction. Meanwhile - is running a Linux system without module support even viable these days? $ du -sh /lib/modules/$(uname -r) 294M /lib/modules/5.10.0-15-amd64
I'm not sure I understand, how OpenBSD load drivers then?
$ uname -sr
OpenBSD 7.1
$ du -sh /bsd
22.0M /bsd
Earlier quoted context omitted.
I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. https://github.com/c-blake/kslog has maybe a little more color on this topic, though I'm sure there are whole volumes written about it elsewhere. :) EDIT: But maybe your "game over" point is just that it is kind of a pipe dream to hope to block all…
> I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. That's generally called pivoting and has nothing to do with method of persistence of the malicious code. OP makes a point that certain systems move or have moved away from giving root user the ability to extend/modify kernel code at runtime via ke…
OpenBSD restricts that ability as well[1]. Neither /dev/mem nor /dev/kmem can be opened (read or write) during normal multi-user operation; you have to enter single-user mode (which requires serial console or physical access to achieve anything useful). Raw disk devices of mounted partitions can't be altered, immutable/append-only files can't be altered, etc.
You can also choose to completely prohibit access to raw disk devices, although that gets annoying when you e.g. need to format an external drive. There is of course still a lot of potential to do harm as root, but it's not as easy to create a persistent threat or resist in-system analysis by an administrator.
Earlier quoted context omitted.
> I believe the concern is that the attackers gain root access on system A but hide their presence/activity - even in the presence of logs to remote, more trusted server B. That's generally called pivoting and has nothing to do with method of persistence of the malicious code. OP makes a point that certain systems move or have moved away from giving root user the ability to extend/modify kernel code at runtime via ke…
> my argument is that none of that matters since root user can still extend/modify kernel code at runtime via binary patching. OpenBSD restricts that ability as well[1]. Neither /dev/mem nor /dev/kmem can be opened (read or write) during normal multi-user operation; you have to enter single-user mode (which requires serial console or physical access to achieve anything useful). Raw disk devices of mounted partitions…
> securelevel may no longer be lowered except by init
> The list of securelevel's effects may not be comprehensive.
So yes, it's a nice sandbox that can help prevent accidents, but doesn't sound like something you should rely on for actual defense.
Earlier quoted context omitted.
> my argument is that none of that matters since root user can still extend/modify kernel code at runtime via binary patching. OpenBSD restricts that ability as well[1]. Neither /dev/mem nor /dev/kmem can be opened (read or write) during normal multi-user operation; you have to enter single-user mode (which requires serial console or physical access to achieve anything useful). Raw disk devices of mounted partitions…
From your link: > securelevel may no longer be lowered except by init > The list of securelevel's effects may not be comprehensive. So yes, it's a nice sandbox that can help prevent accidents, but doesn't sound like something you should rely on for actual defense.
Most importantly, all of these features and mitigations are enabled by default, and are pretty much invisible to the end user or administrator; and actually easy to use for a developer. Contrast this with e.g. seccomp or SELinux. Google is even hinting "selinux permissive" and "selinux disable" in top 3 suggestions...
Earlier quoted context omitted.
Wouldn't IBM be the title holders there?
"open-source company" is kind of an subjective term at this point I guess, so hard to say. But what can be said, is that even though IBM contributes a lot to open source, not many would claim IBM is a "open-source company" I think, at least when compared to Red Hat.
If IBM put US$1B into 'Linux' 22 years ago - but this was a small part of their operating budget at the time - do we look at absolute or comparative value?
If IBM buys, three years ago, RedHat for US$34B, does that mean IBM is now the biggest 'open source' company? (If so, the next question is obvious.)
OpenBSD has removed loadable kernel modules back in 2014; macOS is aggressively moving in the same direction. Meanwhile - is running a Linux system without module support even viable these days? $ du -sh /lib/modules/$(uname -r) 294M /lib/modules/5.10.0-15-amd64
~ # zgrep -F CONFIG_MODULES /proc/config.gz
CONFIG_MODULES_USE_ELF_RELA=y
# CONFIG_MODULES is not set
CONFIG_MODULES_TREE_LOOKUP=y