Live data from Hacker News

SELinux is unmanageable; just turn it off if it gets in your way

ctrl.blog

131–140 of 461 posts

Re: SELinux is unmanageable; just turn it off if it gets in your way

#131

After using CentOS for years, I have come to establish a debugging rule: If things just don't make sense, check if you're fighting SELinux policy. It's just one of those things that you beat your head on the desk after crashing into multiple brick walls that eventually works its way into your debugging process. I guess it just shows how effective SELinux is if it is preventing the admin from doing something. /s

Sysadmin Rule #1 - Is it SELinux? Sysadmin Rule #2 - Is it systemd? Sysadmin Rule #3 - Have you checked the logs?

Where's the time where you could just assume it was DNS.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#132
post #61

Earlier quoted context omitted.

> when you need to stay on bare metal What cases can linux containers not handle? Containers can access GPUs, /dev/kvm, block devices... I'm having trouble thinking of anything they can't do. After all, they're just processes in a glorified chroot, not that different from processes on the linux host.

Not sure about need but I do remember it being a pain in the ass to run anything that expects to be managing docker inside docker. Things like self hosted gitlab ci where its trying to start up containers itself.

> ...anything that expects to be managing docker inside docker.

Now that's an interesting problem to have!

If you trust those tools and don't have untrusted users or untrusted code, you can sometimes just mount /var/run/docker.sock and use the VM/VPS/server's Docker directly. It is actually the approach that was used by excellent tools like Portainer, though it's also really risky as well.

Alternatively, you can try to just run Docker in Docker (DinD), which is a bit more tricky and the opinions there are split about whether to do it and when to do it: https://github.com/jpetazzo/dind

Of course, someone might also jump in and suggest that Docker is architecturally problematic (i don't care much, just want my containers to run, then again; i don't deal with untrusted code or any sort of multitenancy) and you should use Podman or another set of technologies, which is interesting advice but would necessitate other approaches.

In short, like with most technologies: Docker and OCI container in general get more messy as your requirements become more advanced. For the problems that they do solve easily (app packaging), they are pretty good, though!

Re: SELinux is unmanageable; just turn it off if it gets in your way

#133
I have built ad-tech systems which get large amounts of traffic and continuous hacking attempts/DDOS attacks.

In 10 years, the servers have never been hacked. I went to the trouble of enabling SELinux and locking things down. Not sure if it was all needed, but I can't say I am unhappy I did it. After setting things up, it hasn't been a problem.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#134
The 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 like a nuclear power plant. It's good if it works as planned, but if something blows up it endangers your whole enterprise.

The whole container movement can be seen as putting the apps in a sarcophagus like Chernobyl. That way the radiation hopefully stays in, but history has shown that it really doesn't. Also, the wheel of history has just turned one more iteration and now admins just view the sarcophagus as something you deploy as you previously deployed the app. Who is responsible that it is air tight? Well, uh, nobody, really.

You can't even blame the applications for that. Let's say you want to build a good, secure application. How do you know what files your application will try to open? What syscalls it wants to call? Library and framework functions tend to not document that properly.

Obscure files like /etc/localtime, /etc/resolv.conf, /etc/ld.so.conf, /dev/zero ... how can you expect devs to build well documented and well sandboxable applications if they don't know which files their library functions will open?

You may have heard of /etc/resolv.conf ... but have you heard of /etc/gai.conf? /etc/nsswitch.conf? /etc/host.conf? Wouldn't it be great if the man page of getaddrinfo mentioned those (mine only mentions gai.conf)

Re: SELinux is unmanageable; just turn it off if it gets in your way

#135

> Red Hat Enterprise Linux (RHEL) has some of the most accessible documentation on creating custom policies. Red Hat is the Pinterest of Google searches for Linux problems. You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.

> You’ll often find a page where someone is describing you problem but the resolution is locked behind a subscription login.

This gives me flashbacks to Oracle DB error documentation pages.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#136
post #134

The 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…

This seems like something that WebAssembly (misnomer) is set to resolve, to some degree. Sandboxing capabilities is easy because all of the wasm module imports must be provided by the process that initializes the module, so you can view imports as a kind of list of "requests for capabilities".

Re: SELinux is unmanageable; just turn it off if it gets in your way

#137
post #73

Earlier quoted context omitted.

Hum, as another admin... No thanks. With IllumOS I can agree on zones, I can partially agree on lpar on AiX, I can accept GNU/Linux limits with cgroups. Enlarging the attack surface to follow the current wannabe Gurgle mania... No. Like no in the recent past to full-stack virtualization on x86 to enrich VMWare, buy big desktops sold as powerful servers just to play matryoshka doll for someone else business... Of cour…

Can you elaborate on the scalability problems with infiniband?

It's not a problem with infiniband but a problem of sw mutating needs vs actual hw assets: matching is hard. Hw cost money so anyone try to be moderately tight, looking at life expectancy and supposed sw changes in that timeframe, but hw and sw have different lifecycle. At a certain point in time sw infra change while hw is still the same, at another point in time available/current iron change but software on it remain the same.

In classic times that's just a matter of balancing both, carefully designing both, but in modern time developers just "produce code", operation is pushed aside, communications are constrained often by the policies and the result it's a mess => companies choose "the cloud" witch means outsource the issue to third parties. Those third parties count on the fact that even if anything change in the end a computer is always a computer so they can live on a changing world because if single companies have irregularly changing needs on average the rate of change is similar. Also on scale redundancy needs lower the costs and that's why we switch from classic big iron to desktop crap packed in racks. Now we start seeing more and more the limit of such model, and no solution is here.

Big iron is long lost, now way to expensive not much in absolute terms but in demand terms: try to sell a Power system, the customer look at specs and say "hu?! a couple of PCs from nearby grocery store are equally powerful!". Such iron modularity coming from classic mainframes (infiniband in the end is crylink changed a bit by SGI and others) is considered too expensive, on the other side of the spectrum small-board ARM super-blades tentative still results in fails.

Until we accept that hw and sw can't really be two separate world and both must be open to being able to interoperate on scale we will not find any really scalable solution.

Sw side it's not different: these days is the containers mania days because after many have suffered burn with full-stack virtualization on x86 they look for something with less overhead and equal design: hw-sw decoupled, possibility of run an infra you do not know buy pre-made images/containers from third parties who maintain them without needing to know your infra. The result again is an enormous amount of layers and giant attack surface no one really know how extended it is. Since coms are needed we punch holes here and there, and on the other side "safety features" arrive to compensate, making more complicatedness layers on complicatedness instead of admitting the basic issue: in sw terms our OSes are badly designed for current needs, they are a relic form a long lost past where they aren't even good but just cheaper alternatives to something better.

If we ever admit those errors probably we will be able to design modular iron and modern OSes marginalizing those issue, but so far no one want such a nightmarish adventure...

Re: SELinux is unmanageable; just turn it off if it gets in your way

#138
Seatbelts in cars are also constantly getting in my way. Why shouldn't I just cut them off?!

I think the problem is, that people don't understand SELinux. And containers are not a solution, because I can exploit a vulnerability and escape the container. But if I have SELinux running, then me escaping a container would not cause any harm.

There is no good tutorial for SELinux and most people don't invest the time to understand it.

Re: SELinux is unmanageable; just turn it off if it gets in your way

#139

Earlier quoted context omitted.

Because plenty of unscrupulous ISPs and governments log unencrypted web traffic. Some ISPs use that information for advertising, or inject custom javascript into unencrypted web pages their customers visit for who knows what reason. HTTPS is free and stops most of these tricks from working. You can still sniff the domain name via DNS or SNI, but HTTPS blocks attackers from seeing the URL you're visiting, or seeing th…

> Because plenty of unscrupulous ISPs and governments log unencrypted web traffic. Ok. Not relevant here. I don't care if my ISP knows I'm learning SELinux. And they would know that even with HTTPS. > Some ISPs use that information for advertising, or inject custom javascript into unencrypted web pages Sounds like an ISP problem. Buy service from a better one. No need to impose SSL on the website for this. > HTTPS is…

> HTTP is faster.

Thats not always true, thanks to awful middleware boxes. Especially inside corporate networks.

Also TLS is required for http2 - which is much faster than HTTP1.1 in almost every case.

> It takes time and effort to set up. And then maintain forever.

People level the exact same accusations at SELinux. Some would say SELinux doesn't add a lot of security, and its a pain to set up and maintain.

HTTPS is much easier to set up than SELinux thanks to letsencrypt and certbot. And it adds real security for your users. Its weird to promote SELinux but not bother with TLS.

But all these complaints are moot in this case anyway because this website is hosted by github pages[1]. Github will do all the heavy lifting to make HTTPS work. The owner just needs to set DNS up:

https://docs.github.com/en/pages/configuring-a-custom-domain...

Oh yeah and you know what I was saying about http2 being faster than http1.1? Github enables http2 automatically on github pages. But only, y'know, if you set your site up correctly.

[1] At least according to the invalid cert warnings I'm seeing

Re: SELinux is unmanageable; just turn it off if it gets in your way

#140
post #128

Earlier quoted context omitted.

AppArmor is great. It can do much of what SELinux does, but it uses plain configuration files as opposed to incredibly obscure and clunky filesystem-level hacks.

It still has the same gotchas as a user though. I was daemonizing a uvicorn (Python) process using systemd and could not get the Python script to write its log file anywhere. Not the current directory owned by the user, not elsewhere, and no errors showing up in the system logs. After a few hours banging my head against the wall I discovered systemd's ReadWritePaths. Once I set that, it would log to any directory I s…

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= settings which can greatly limit where a service is allowed to read from and write to and thus require you to open specific directories back up. Instead of using ReadWritePaths=, you might prefer to set LogsDirectory=.

Post reply on HN