Earlier quoted context omitted.
You can use strace to get this information. Linux also offers seccomp and landlock which are very similar to pledge and unveil.
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…
SELinux is unmanageable; just turn it off if it gets in your way
261–270 of 461 posts
Re: SELinux is unmanageable; just turn it off if it gets in your way
#262Earlier quoted context omitted.
> Wouldn't it be great if the man page of getaddrinfo mentioned those (mine only mentions gai.conf) That's a huge part of the problem. Was looking for a monograph to pass on my successor that wasn't so familiar with linux - modern linux - as in systemd, docker, nssswitch, pam_homed, network-manager is penetrable but more often than not I'm just looking at the c source in github and I am in my 30ies, starting in my te…
> there is no overview documentation, Documentation on Linux has always been shit.
Now if we are talking of a documentation of a random project on github..
Re: SELinux is unmanageable; just turn it off if it gets in your way
#263Basically linux is moving from a hobbyist operating system that a single person can reasonably manage in their spare time to an enterprise ish complex monstruosity that requires training and a time investment. Probably because the main Linux sponsors have found that it's the only way to make money with it. SELinux... systemd... who knows what's coming next. Let's not forget ipv6, although that's not a linux specific…
As a Desktop environment, major Linux distros have never been as well polished as they currently are. It's gotten to a point that regular people can use them without much hassle. From a sysadmin perspective,one always needed to invest time in Linux to be proficient in it, I don't see how that has changed greatly.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#264Earlier 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…
> Unless you have 100% test coverage (and if you had, why do you still need a sandbox then?) 100% test coverage does not guarantee absence of vulnerabilities in any way. > you will miss error handling and optional code paths that you didn't enable in the configuration, and handling code for circumstances you didn't trigger and didn't foresee. Having sandboxed many things, this is plain false. Normal applications and…
This is probably the most well known issue with sandboxing - maintaining the sandbox. It's especially hard with seccomp, because you could upgrade your distro, or a dependency, and suddenly you're making a different system call.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#265The 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 not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understan…
My opinion is that there's a cultural and policy problem and you're simply not going to solve it with technology. I don't think SE Linux is bad, it just isn't the answer here. One (clearly not the only) main reasons people just run a bunch of software they don't understand is due to expectations in productivity. In an idealistic world with caution built in, we are willing to sacrifice some productivity for security, stability, understanding, etc. I think many engineers like these ideas because they like to work with and build solid systems they understand very well--otherwise they wouldn't be practicing any form of engineering.
What we instead have is a world of engineering with no sort of guard rails. Unlike Civil Engineering, there's no licensing, no sorts of inspections, no oversight, liability is completepy waived in a 300 page agreement people just click through, etc. Even when things go horribly wrong (e.g. Equifax) the repercussions are limited. We see abuse in other engineering fields where actual life and death are factors and they're still just amortized in a cost analysis.
Ultimately though engineers simply don't lead the world (and arguably, maybe they shouldn't) , people with wealth lead the world (arguably, they shouldn't either) because it underpins pretty much all other systems anymore. As such, productivity is always prioritized over safety and security. This issue isn't limited to software, it happens everywhere almost ubiquitously at this point. Software is one of those areas where most people just care less, so you can get away with more and more of this. The issue is that I believe we're building a house of cards that will be difficult to revert to a reasonably stable state once it finally collapses.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#266Earlier 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…
Yet another rabbit hole has emerge. And it is called “systemd”. What a great time to be a Linux system administrator.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#267Eh, what? SElinux is completely manageble and usable. I've been happily living with it for a long time. Now when I have to live with apparmor (which is exactly unmanageble) I really miss SElinux and really don't feel any secure without it. Another wave of excuses in the manner of "i don't wanna learn anything".
Re: SELinux is unmanageable; just turn it off if it gets in your way
#268The 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…
Re: SELinux is unmanageable; just turn it off if it gets in your way
#269The 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 whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. […] Who is responsible that it is air tight? Well, uh, nobody, really. The people who designed the container/sarcophagus system. If it's not secure don't sell it as secure: see the difference between Linux containers and FreeBSD jails or Solaris zones. > You can't even blame the applications for that. Let's say you want to…
> The people who designed the container/sarcophagus system.
Original comment misses two nuances with the gripe.
1. Container creators and software creators are not the same people. So they can (and should!) have different goals and priorities. For containers, security and reliability. For software, make it work.
2. There is a nuanced, different interface between software-system and container-system, created by encapsulating a system-like environment inside the container. Much of what software does can be encapsulated. Which allows a more controlled (and much smaller) subset to exit the container.
Re: SELinux is unmanageable; just turn it off if it gets in your way
#270The 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 not so much that selinux is too complicated (it is as complicated as it needs to be) I disagree. > but that we all run software we don't understand. I fully agree. My disagreement lies in the fact that you've described the problem, but are proposing that some software (SELinux) that fails to solve the problem is somehow good. SELinux might be a perfect tool in an ideal utopia where everyone understan…
If you’re using SELinux rules off the shelf for a handful of Fedora boxes for personal use, maybe that use case doesn’t work. But is that more “real world” than an institution like the NSA trying to completely lock down its production systems?