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

441–450 of 461 posts

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

#441

Post by salawat »

fefe23 wrote: post #194
_wldu wrote: post #184

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…

Then decompile the binary, bust out gdb, and do some forensics. Or realize you're about to embark on a multi-decade mission Learn It All(TM) which equates to maybe learning the quirks of enough niches of the programming community to maybe not be surprised by what you find... Eh.. 40% of the time.

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

#442

Post by josephg »

hexo wrote: post #368
f1codz wrote: post #215

Earlier quoted context omitted.

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.

Yep. Also http2 more than makes up for the performance difference. And http2 requires TLS.

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

#443

Post by yyyk »

vaylian wrote: post #341
lazyier wrote: post #305

Earlier quoted context omitted.

The alternative, which is Linux, is to grant your calculator app the permissions to read and write to the same resources that your browser uses to store the password for your bank. Well "grant" is too strong of a word. "By default and there is nothing you can do about it unless you are exceptionally skilled" is more accurate. Also your calculator app can read your sudo password as you type it, which you do a dozen ti…

> Also your calculator app can read your sudo password as you type it True with X11. Fixed in Wayland.

Wayland fixed one problem, but there's no shortage of local privilege escalation bugs with which the calculator can still read the sudo password.

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

#444

Post by db48x »

greedo wrote: post #418
icedchai wrote: post #408

Earlier quoted context omitted.

Unless there's a vulnerability in something internet facing, you can go a very long time without updating anything. So, yes, it doesn't matter... except when it does. I've logged into production systems with multi year uptimes, with updates that haven't been applied in just as long. Many orgs have a if it's not broke, don't fix it policy. Applying needless updates are just as likely to screw something up.

Many orgs get breached (or have no way to detect if they've been breached). It depends on both your industry and your risk tolerance. We generally apply every security patch that comes along for RHEL. Application patching is different, it depends on the severity and what the vendor will support. If we can't patch, we try to apply compensating controls to mitigate the risk. And the pride we all used to have with long…

Security patches can be applied even to the kernel without restarting anything though, so having a high uptime is not mutually exclusive with staying up to date. Of course, you do have to pay extra for live patching.

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

#445

Post by raesene9 »

bonzini wrote: post #402
raesene9 wrote: post #91

Earlier quoted context omitted.

I'd generally agree with this, but for production use (where it'll be CRI-O or ContainerD in all likelihood) it's worth noting that using containers does increase your attack surface. We've had container breakout CVEs in the Kernel+ContainerD+CRI-O this year, and the ContainerD/CRI-O ones were not complex at all, so you do need to stay on top of patching as well as the other good practices mentioned.

A lot the container breakout CVEs do not affect a system that uses SELinux properly.

have you seen an analysis of SELinux against the recent set of breakouts? That'd be interesting to see.

Definitely the CRI-O one (which is most likely to affect Red Hat based systems) was able to exploit a default OpenShift cluster in my testing.

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

#446

Post by goodpoint »

someguydave wrote: post #335
goodpoint wrote: post #330

Earlier quoted context omitted.

Plus, it makes updating an application way more difficult: you need: - the distribution to recompile and test all binaries using a vulnerable dependency [x] - users to download and update all affected binaries compared to: - the distribution patching a single package - users updating that package Imagine if OpenSSL was statically linked: even the smallest fix would require users to update half of the OS. And that wou…

Why would you need to rebuild everywhere? Couldn’t you rebuild once in a trusted place and distribute signed binaries?

Distributions have their fleet of buildbots to do the latter.

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

#447

Post by pkrumins »

topspin wrote: post #379
pkrumins wrote: post #167

Earlier quoted context omitted.

Because we didn’t ask for systemd. We like init scripts that we actually understand.

systemd isn't difficult to understand.

10 years into it and I still have no idea how to use it.

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

#448

Post by pkrumins »

nix23 wrote: post #179
pkrumins wrote: post #170

Earlier quoted context omitted.

I run thousands of severs. None of them have SELinux or systemd. It’s banned tech.

Well that just says nothing, it's not a sign for security or quality nor against it. I run around 600 jails (so obviously no systemd (FreeBSD)), but the host for sure has pretty tight MAC policies (and some jails too). What other MAC-System do you use? tomoyo? apparmor?

I have to complement your choice of FreeBSD and jails. If I didn’t have a Linux stack, I’d run FreeBSD and jails, too.

I wrote my own kernel modules that do exactly what I need in my stack and use case. No need for complicated SELinux, AppArmor or other solutions. I always roll my own solutions from the ground up (usually in a couple of all-nighters).

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

#449

Post by someguydave »

goodpoint wrote: post #446
someguydave wrote: post #335

Earlier quoted context omitted.

Why would you need to rebuild everywhere? Couldn’t you rebuild once in a trusted place and distribute signed binaries?

Distributions have their fleet of buildbots to do the latter.

Exactly! So what difference does it make if there is one patched package or 1,000?

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

#450

Post by greedo »

db48x wrote: post #444
greedo wrote: post #418

Earlier quoted context omitted.

Many orgs get breached (or have no way to detect if they've been breached). It depends on both your industry and your risk tolerance. We generally apply every security patch that comes along for RHEL. Application patching is different, it depends on the severity and what the vendor will support. If we can't patch, we try to apply compensating controls to mitigate the risk. And the pride we all used to have with long…

Security patches can be applied even to the kernel without restarting anything though, so having a high uptime is not mutually exclusive with staying up to date. Of course, you do have to pay extra for live patching.

I'm still leery of ksplice etc. And the cost is a factor too.
Post reply on HN