51–60 of 461 posts
How does SElinux compare to Secure Boot / SIP?
Secure Boot and SIP are about boot integrity preventing malware early on in the boot process [1]
I've deployed both AppArmor and SELinux in high security environments, and they're nice layers of security to have.
Yes, it has a learning curve, but it's worth it.
Well, Android has it always turned on for several years now.
SELinux policy can also be written to mitigate many vulnerabilities and vulnerability classes/vectors. Over 40% [1] of Android users may no longer be receiving important security updates, potentially putting them at risk of malware, data loss and cyber attacks.
Seems to make sense to have it enabled on Android based on the above.
[1] https://www.which.co.uk/news/2020/03/more-than-one-billion-a...
My advice is to ALWAYS turn it off. As soon as you install a new system, turn it off (together with systemd).
> turn it off (together with systemd) How practical is just turning off systemd today? I hate it too, but hasn't Red Hat basically strong-armed so many important Linux components into adding a hard-dep on it that your only way of avoiding it is to use a distro purpose-built to (e.g., Devuan)?
I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…
As an experienced RHEL admin, a few years ago I probably would have said this is very bad advice in any professional context, and you should spend the time to learn it because it will save you one day. Now, I think my advice would be: Put everything in a container, and learn how to run Docker or Podman (or k8s) in a secure way (ie no root containers, be very careful with volume mounts, etc). Yes, they aren’t as matur…
1) The article author is Testing in PROD
2) selinux debugging relies on auditd, so sanity checks required.
df -P /var/log/audit # has space?
tail -1 /var/log/audit/audit.log # is recent?
semodule -DB # disable dontaudit
setenforce 0
# run the failing test
audit2allow -l
mk_semod() {
module_name=$1; shift
audit2allow -l -m ${module_name} -a > ${module_name}.te
$EDITOR ${module_name}.te || return
checkmodule -M -m -o ${module_name}.mod ${module_name}.te
semodule_package -o ${module_name}.pp -m ${module_name}.mod
semodule -i ${module_name}.pp
}I've always preferred apparmor. SELinux has always seemed radically more complex for very little benefit, unless you have a tightly constrained OS (like Android, where the VM does most of the work and every app has the same sort of security policy) or a team of admins working full time to maintain it (again, like Android). Apparmor is weak in all the same ways SELinux is weak, at least in terms of the ways that actua…
To expand a little, for a vertically integrated OS like Android or RHEL (official packages only!) SELinux can work.
For a sysadmin trying to configure a custom service or anything outside official repositories then AppArmor is actually usable where SELinux isn't.
But what you probably want is a Docker (or Podman) container, which gets you 90% of the hardening with 1% of the effort.
If a container isn't viable for whatever reason, then a systemd "contained" service is also very easy to configure. See `man systemd.exec`.
Well, Android has it always turned on for several years now.
Mobile applications require various permissions which can be enforced via SELinux. SELinux policy can also be written to mitigate many vulnerabilities and vulnerability classes/vectors. Over 40% [1] of Android users may no longer be receiving important security updates, potentially putting them at risk of malware, data loss and cyber attacks. Seems to make sense to have it enabled on Android based on the above. [1] h…
https://android-developers.googleblog.com/2016/06/android-ch...
https://android-developers.googleblog.com/2017/07/seccomp-fi...
I have to say, for sysadmin work I find this view sorta overblown. My experience is with RHEL and derivatives, not Fedora, and for the most part those are very straightforward and while selling does rear it's head every once in a while, it's usually not that problematic to work around. When you have something failing that you need to fix and isn't an upstream problem (i.e. your own app or some third party vendor), yo…
The few times where you do need to create new policies then audit2allow is useful but still requires you to review and understand the changes it's going to make before applying them.