Well, Android has it always turned on for several years now.
Android's systems are developed alongside those policies, though. Things like lighttpd don't ship selinux policies, and bolting it on later is fragile.
SELinux is unmanageable; just turn it off if it gets in your way
241–250 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#242Earlier quoted context omitted.
Why would a container increase latency? It's just a pointer on a process. It's there on all processes. https://elixir.bootlin.com/linux/latest/source/include/linux...
https://www.diva-portal.org/smash/get/diva2:1252694/FULLTEXT... Also docker NAT will add significant latency if you don’t use host network mode. When microseconds matter, everything matters. Any intermediate program would be suspect.
Then that's not about containers, but about NAT. So maybe don't use NAT. You can have NAT on the host, too, and it would slow down things also.
"Container" (namespace to be precise) is not really an intermediate program, it's a state associated with any Linux process.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#243Earlier quoted context omitted.
I would like to emphatically point out that: no, you can't. You can't use strace to get this information. Let's say you want to use seccomp to whitelist allowed syscalls. Your code opens a file, uses stat to get the file size, then mallocs that many bytes and reads the file contents into the buffer. Trivial program, right? glibc will turn open into openat, stat into statx, malloc can become either nothing, or sbrk, o…
Docker actually comes with a seccomp and an apparmor config that bans many things by default. while it is absolutely not noticeable unless you are trying something like docker in docker. There are so many syscall that shouldn't even be relevant to normal programs.
That's why I explicitly mention "whitelisting".
If you just want to ban some obscure syscalls and call it a day, you can do that. It will probably even be helpful to some degree.
I personally think our aspirations should be higher than "let's ban ptrace(2)".
Re: SELinux is unmanageable; just turn it off if it gets in your way
#244The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…
I would argue that the fundamental problem is that the companies selling software "engineering" products do not actually take any responsibility that the product they have engineered works as intended. (see: https://www.snopes.com/fact-check/car-balk/ ) And of course, the main reason they do not take the responsibility is that the customers won't pay for it. It is kind of interesting. We are very good at making bridg…
There are a limited number of known failure modes when working with physical materials. We know the properties of materials and we know the physics.
The equivalent to fizzbuzz would be something like a free body diagram.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#245The problem is not so much that selinux is too complicated (it is as complicated as it needs to be), but that we all run software we don't understand. The whole IT ecosystem has become a hail mary. Even admins usually have no idea what a certain program actually wants to do. If the admin knows how to install the app so that it actually runs, you call them a good admin. From a security point of view, an application is…
The problem is that we have built all our software on Unix. The Unix security model is based on an attack model where users have to be protected from each other on a terminal server. Code is implicitly trusted and exploits were an unknown unknown. That security model is almost completely useless now. Terminal servers are an extreme edge case. Services implement their own security model between users. Special “Users”…
I agree with your points about the Unix threat model being designed around protecting users from each other, but for completeness I'd like to point out that while modern Linux/BSD systems ship with Discretionary Access Control (DAC) by default, SELinux implements a Mandatory Access Control (MAC) system which is much more fine grained. SELinux is not limited to the traditional Unix security model.
Short simplified example highlighting DAC/MAC differences: DAC asks "is user Alice allowed to read Bob's files?" while MAC asks "is the SMTP server (subject user/role) process allowed to read private keys (object type) of the HTTP server (object user/role)?"
And if you're really motivated (read: want to have fun diagnosing unexpected file permission issues), you can associate files and processes with different security categories and levels (MCS/MLS), implementing horizontal and vertical separation. For example, "is this software update service allowed to read confidential files owned by the accounting database or keys used to encrypt classified information?"
There are other MAC systems besides SELinux as well.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#246Earlier quoted context omitted.
Most systemd services log to stdout and let systemd put it in the journal, or they log to syslog and let systemd put it in the journal. Most don’t write their own log files any more. I really recommend going that route because it is nice to be able to search the journal, especially if you provide extra metadata for each log message. It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= setti…
> It sounds like you were using the DynamicUser=, ProtectSystem=, or ProtectHome= settings which can greatly limit where a service is allowed to read from and write to Thank you! I have DynamicUser set - I can't think why I added it here, perhaps no reason at all - and that is the difference to previous systemd services I've written. I did not know it had such an effect on behavior.
It is a nice security measure; it means that no other service can accidentally read or write to the same files. An older form of the security measure was to create new system users like “ftp” and “mail” so that the ftp daemon couldn’t be tricked into overwriting someone’s mail queue and so on. The downside is that this takes a certain amount of effort on the part of the system administrators and distros to arrange; the bookkeeping becomes a significant source of manual effort.
The DynamicUser= setting tells systemd to invent a new user on the spot, with an id that is not in use by any other service. You can add as many such services as you like¹ without having to do any extra work to keep /etc/passwd updated.
¹ as many as you like as long is it isn’t more than several thousand, unless you recompile systemd with larger limits.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#247Earlier quoted context omitted.
I would argue that the fundamental problem is that the companies selling software "engineering" products do not actually take any responsibility that the product they have engineered works as intended. (see: https://www.snopes.com/fact-check/car-balk/ ) And of course, the main reason they do not take the responsibility is that the customers won't pay for it. It is kind of interesting. We are very good at making bridg…
The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.
Which in my opinion brings up the certification argument, but I, as I’m sure others, have found that most certifications mean nothing in regards to whether someone can actually do the job. Is the key component missing in hiring in our industry a vastly more rigorous/extensive/difficult testing and certification protocol?
Re: SELinux is unmanageable; just turn it off if it gets in your way
#248Earlier quoted context omitted.
SELinux is so ridiculous. If you want a real security on linux where root is not God ! Go to this site. https://www.rsbac.org/ It's little difficult to implement (by kernel customisation) but there is a learning mode to secure all Linux structure Be "root" is not be "God" after implementation. You will must ask to Security Officer (SecOff) You can speak of "Evaluation Assurance Level" with this security solution and…
root is not God under SELinux either. root processes are also confined.
Indeed, that's possible and a good idea - as long as you're not talking about user shells [1] running as confined processes. It turns out that having an unconfined root shell is actually not a bad idea unless you're interested in extreme levels of security. My experience is that confining user shells is a significant hassle.
Running daemon processes etc. as confined root on the other hand is a good idea, but if you're going to the trouble of confining a root process you might as well just run it as a normal user instead if that's possible.
[1] Meaning shells used by a real person attached to ssh.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#249Eh, I generally disagree - but not completely. Set SELinux to permissive for your personal systems at your own relative risk. Never disable it, you'll end up in a situation where nothing is labeled and relevant policy adjustments probably don't exist. Making re-enabling it later a nightmare. I'd argue it's particularly advantageous for desktops where untrusted software is a more common occurrence... and other control…
It's been years since I was responsible for administering Linux Servers, but half the issues I ran into were generally fixed with `restorecon`.
I used to be that "never disable SELinux" person, but I've since become a bit more pragmatic. But I still think you should at least spend a bit of time trying to get it to work before defaulting to `setenforce 0`.
I'm a Detection and Response Engineer now, Analyst for several years prior, and I've seen several incidents that would have been stopped by SELinux. Almost all of them were web shells or web app based RCEs. E.g. https://nvd.nist.gov/vuln/detail/cve-2019-3396
Re: SELinux is unmanageable; just turn it off if it gets in your way
#250Earlier quoted context omitted.
I would argue that the fundamental problem is that the companies selling software "engineering" products do not actually take any responsibility that the product they have engineered works as intended. (see: https://www.snopes.com/fact-check/car-balk/ ) And of course, the main reason they do not take the responsibility is that the customers won't pay for it. It is kind of interesting. We are very good at making bridg…
The engineer building the bridge is liable. Hence, you get engineers with qualifications (instead of a random person with X years in Y), and those qualifications certify they know what they are doing.
which is why bridges and buildings certified by qualified engineers have never collapsed