Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ctrl.blog

Post reply on HN
Print view View original

361–370 of 461 posts

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

#361

Post by icedchai »

tristor wrote: post #282
fefe23 wrote: 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…

Honestly, the bigger issue is that most SWEs just aren’t very good. It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… System design, though, is the actual point of SW ENGINEERING. That’s the part that is responsible for creating a foundation of quality to build on. The other side is that sysadmins hav…

True, but even in the 90's and early 2000's, before cloud took off, most developers weren't sysadmins, and they didn't want to be. That wasn't their specialty. The "Unix wizard" developer was always a rare breed.

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

#362

Post by [deleted] »

tristor wrote: post #282
fefe23 wrote: 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…

Honestly, the bigger issue is that most SWEs just aren’t very good. It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… System design, though, is the actual point of SW ENGINEERING. That’s the part that is responsible for creating a foundation of quality to build on. The other side is that sysadmins hav…

[deleted]

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

#363

Post by paledot »

throwaway889900 wrote: post #321
paledot wrote: post #286

Earlier quoted context omitted.

If something isn't secure, it doesn't work. At that point, you would've been better off shipping a wireframe.

For you, no risk seems acceptable when it comes to security. That is generally not the case for most people, who will accept some level of risk (ie an insecure program) if it provides value to them. That's the whole point of risk management.

Pardon me for being pithy. We've all heard the adage about perfect security being a logical impossibility. I will say instead that if a tool doesn't have security proportionate to its risk factor integrated in its design, it doesn't work.

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

#364

Post by ximm »

tinco wrote: post #235
ximm wrote: post #25

Earlier quoted context omitted.

I agree that containers are easier to manage than SELinux, but still not easy enough. Linux provides many low level primitives for restricting applications and SELinux, Apparmor, Docker, Flatpak, and systemd all provide high level abstractions for those. But IMHO none of them really finds a sweet spot between flexibility and usability. `systemd-analyze security` for example lists 80 (!) different settings, even thoug…

In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a…

What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.

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

#365

Post by throwaway894345 »

fefe23 wrote: 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…

> 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.

I don't think these statements are meaningfully different. "too complicated" implies "...for humans to manage". Maybe that's sort of your point?

> 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.

Agreed. It's too burdensome for software developers to understand exactly what syscalls their program needs to make and the security implications of permitting those syscalls. It also doesn't help that Linux naming conventions and concepts are very counterintuitive (yes, dear Kernel Hacker, I'm sure they're very intuitive to you, but we lowly mortals struggle).

And unfortunately the SELinux policies are tightly coupled to the application such that you can't make SELinux policies the purview of a dedicated sysadmin expert and leave the appdev to the development teams. They have to collaborate which is swimming against the current of Conway's Law or else you make SELinux policies the responsibility of appdev and suffer their lack of expertise.

We had similar problems with operations in general, but containers largely solved this problem by allowing sysadmins to focus on a platform while developers focus on developing and operating the application. We need something similar for security. This is probably a rephrasing of your "sarcophagus" point?

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

#366

Post by kevinmgranger »

ulzeraj wrote: post #110

> 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 don't need a subscription, but you do need an account.

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

#367

Post by phkahler »

fefe23 wrote: 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…

Yeah, I came to comment on this:

>> It doesn’t help that no one wants to be told: “stop what you’re doing, spend a week to learn this other thing, make a tiny change, and then return to your real job”. They’re looking for solutions — preferably quick ones — and not a week’s worth of study.

If you're a system administrator running SeLinux why dont you already know SeLinux? It's not like some obscure command, it's a big part of the infrastructure you're running.

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

#368

Post by hexo »

f1codz wrote: post #215
josephg wrote: post #114

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…

Also technology wise its not 2022 everywhere, if you know what i mean. Many poorer nations suffer from inferior infrastructure, which could mean slower loading / processing times for https based webpages. I remember reading an article along these lines a few years ago when arguing against using https absolutely everywhere.

Nope. SSL was pretty okay performance-wise 15 years ago. So no, we don't know what you mean. 'Poorer' infrastructure excuse is void. If we cared about performance we'd get rid of almost all javascript, not https.

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

#369

Post by mwmisner »

AndyNemmity wrote: post #350
loeg wrote: post #304

Earlier quoted context omitted.

> It’s extremely telling that when you spend time in tech forums most people dread system design questions as the harder side of interviewing for senior level SWE roles… > System design, though, is the actual point of SW ENGINEERING. I mean, I would say I'm pretty good at engineering and system design (10 YoE, senior/principal for most of them). But I dread the system design interview questions because (in my experie…

In the real world, if I was tasked with "build a distrbuted wikipedia downloader" I wouldn't just start randomly guessing. I'd get input, feedback, discuss, narrow down options. Yet for some reason, that's an actual interview question. Start randomly guessing based on your knowledge of something, in a way that you'd never do in a real scenario. Edit: I feel like I should do an interview like this. Refuse to explain h…

I totally agree that system design questions can be silly sometimes. When I do system design interview questions for senior engineers, I ask a really broad and complex questions and let the candidate drive us towards the system. The point of the interview is evaluating if the candidate can complete those soft skills in a reasonable way. I try to answer basic questions such as these:

Did the candidate just go for design without asking questions?

What questions does the candidate ask?

What areas are they asking questions about?

Can they take critical feedback on their design well?

There is a little bit of discussion on technology choice, but typically if they can justify an out of the norm choice it is fine.

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

#370

Post by ryandrake »

virtue3 wrote: post #227
resonious wrote: post #222

Earlier quoted context omitted.

I've been recently thinking along similar lines about libraries. In web dev, it's common practice when you have a problem to first look for a library that solves it for you. I get the "don't reinvent the wheel" sentiment but, I think we take it too far sometimes. I've been looking at the source code for some dependencies at work lately, and many of them actually don't hold up to our own code quality standards. Kind o…

when it comes to JS libraries I'm usually a lot more interested in how good their testing is. Code quality can be very subjective in some areas. But if the dang library doesn't have a lot of good testing then I can't really trust any updates from it :/

Coming from marine and aerospace contracting, I'm always shocked by the cavalier attitude The Rest Of The Software World has about pulling in third party dependencies. "I have a problem to solve. Let's Google for: [problem] [language]. Aha! This library on GitHub has 12 bajillion stars! Pull that one down, build it, and YOLO!" No in-depth look into what other things the dependency does, how it increases the attack surface, what user data it gobbles up, what license it uses, what is the update cadence and how often do we need to pull from upstream, what is the contingency plan if it ends up not being suitable, nothing. Just git push and close that JIRA ticket!
Post reply on HN