51–60 of 88 posts
Ya'll are beyond parody. It was added to CVS two months ago? Yay. I'll be sure to upgrade and rebuild from dev in CVS. Call me when doas has finished reimplementing sudo, oh so much better and more auditably.
Earlier quoted context omitted.
MACs come in many different flavors. E.g. AppArmor is very easy to administrate an provides security over running 'random' applications without MAC.
There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capa…
Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
Earlier quoted context omitted.
You do know that OpenBSD just recently introduced a hypervisor, right? (From the "(historically)", I'm guessing you do but others reading this may not realize that OpenBSD now does ship with a hypervisor. It's very "early", though, FWIW.)
Correct. Currently it can only run OpenBSD guests, and it only supports x86. The landscape is a little different now that hypervisors are no longer cutting edge, and the x86 architecture has improved virtualization abilities which help prevent some security flaws.
Earlier quoted context omitted.
I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.
While containers can't help against privilege escalation, they help against information leakage. For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's foolproof if you use it. It's also incredibly annoying if you are on a system with selinux enabled, but aren't familiar with selinux.
Earlier quoted context omitted.
The typical configuration I see in /etc/selinux/config is: SELINUX=disabled
Its definitely one of the things that shows up when you call about a lot of vendor's software support. I find it rather annoying that a company tells you to buy a specific Linux distribution then pulls exactly what you say. Thinking about it (maybe because I am watching a update go as I type), what the heck does this say about how we program? I guess in some ways its why I like the idea of pledge. It makes me think b…
SELinux is not complex because we program in complex ways, but because we don't know the target program.
For example, (again, nothing against Apache but...) if I want to secure Apache, there's no way for me (as a sysadmin) to tell exactly which files, exactly which syscalls, and exactly which libs does it need to function, and there's no way for me to stay on top of it.
And the same applies to any other complicated software. How to I lock down X? Firefox?
Really, the beauty of a "pledge" like system is that the programmer/PM of the code (which he should understand) should know how to lock it down
Earlier quoted context omitted.
I'm not sure that containers will help with security profiles. They should help with (for example) privilege escalation, but you will still be left with managing what systems/programs need access to what resources.
While containers can't help against privilege escalation, they help against information leakage. For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
seriously ?
Earlier quoted context omitted.
There's not enough data / samples of secure operating systems to make an intellectually honest assertion that one approach is definitively superior, but OpenBSD likely has the best security track record for an operating system in real-world scenarios. While auditing is definitely a good idea, the latter approach only works when you only run services and applications that are part of OpenBSD. Since that is not the cas…
The comment you are replying to does not mention auditing.
Earlier quoted context omitted.
While containers can't help against privilege escalation, they help against information leakage. For example, even assuming privilege escalation isn't a possibility, www-user can read /etc/passwd, getting all usernames. Containers help mitigate this.
If your www-user can read /etc/passwd without 'avc: denied' appearing in your selinux log, you are doing it wrong. The whole idea behind selinux is to prevent this scenario from ever happening. Apache has a policy written for it, that specifies precisely which paths and contexts apache needs type of access to. If it tries to access anything outside those paths and context, the selinux module denies the attempt. It's…
Earlier quoted context omitted.
There's two separate issues here, both of which apply: 1. A knob that can't be configured can't be misconfigured (IIRC Debian had a hole in its default selinux config for years that created a vulnerability selinux-less machines didn't have) 2. (This was more what I meant) the promise that makes people like MACs is that you no longer need a single all-powerful root user to do everything (this bleeds into ACLs and capa…
> capabilities Well. There just aren't many useful caps to begin with. For example, consider backups. You'd want the backup system to have full read access to everything. Well. You can't do that with capabilities. You only get DAC_OVERRIDE, which is one of the many root-equivalent caps in Linux. Probably half of them are.
Great. You need to give a process more or less root so that it can deny itself privileges.