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

451–460 of 461 posts

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

#451

Post by iggldiggl »

legalcorrection wrote: post #393
ximm wrote: post #364

Earlier quoted context omitted.

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.

You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.

Even file picker APIs are severely lacking with regards to any multi-file filetypes, where opening one file means having to subsequently access further additional files, too (but which files exactly cannot necessarily defined in advance because it depends on the contents of the initially opened file).

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

#452

Post by hajile »

dijit wrote: post #175
Hnus wrote: post #164

Earlier quoted context omitted.

WASM will probably be always slower than native but call it very inefficient is unjustified imho considering the compiler needs to be fast enough to run in browser from what I have seen its around ~1.5x slower than native code with there still being many low hanging fruits to be optimized.

prefer not to get into a debate about the efficiencies of x vs y but sufficed to say: Computers are only getting negligibly faster over the last 10 years and our software has gotten overall quite considerably slower. A runtime overhead that slows everything down to 1.5x, even with low hanging fruits is only going to accelerate this issue. From a consumer perspective: We all act as if everyone has 8-16G of ram, becaus…

That talk makes the point that replacing the swiss cheese hardware security models with a software one can shift your performance. You run 1.5x slower, but you also run 1.5x faster by avoiding all the hardware checks. On the whole, you can theoretically run about the same speed, but with better security.

Even better, if WASM takes over the world, you can bake parts of it into hardware and remove a lot of other bottlenecks.

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

#453

Post by vaylian »

yyyk wrote: post #443
vaylian wrote: post #341

Earlier quoted context omitted.

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

I want to learn more. Do you have some examples?

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

#454

Post by yyyk »

vaylian wrote: post #453
yyyk wrote: post #443

Earlier quoted context omitted.

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

I want to learn more. Do you have some examples?

Just yesterday, Microsoft found a few[0]. There's no shortage of these, but more important is the haphazard way fixes are backported to longterm (e.g. [1]). This reached the point that Google's security advice is 'always follow the latest kernel'[2], except most users and distros simply cannot afford it, so they are stuck with a vulnerable system.

Linux is not unique here. In the longterm, all the typical desktop OSs will need significant structural changes far beyond 'chase vulnerabilities and patch everything all the time'.

[0] https://www.theregister.com/2022/04/27/microsoft-linux-vulne...

[1] https://nvd.nist.gov/vuln/detail/CVE-2019-15902

[2] https://security.googleblog.com/2021/08/linux-kernel-securit...

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

#455

Post by nix23 »

pkrumins wrote: post #448
nix23 wrote: post #179

Earlier quoted context omitted.

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

I needed around 5 years to slowly move away from Linux, open/-solaris/omnios/smartos was also in my mind, but...well you probably know the sad story behind it.

But FreeBSD really kicks, from firewall to database all the way down, everything FreeBSD ;)

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

#456

Post by db48x »

greedo wrote: post #450
db48x wrote: post #444

Earlier quoted context omitted.

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.

/me nods, but it is so very _very_ convenient.

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

#457

Post by kelnos »

dale_glass wrote: post #202
kelnos wrote: post #176

Earlier quoted context omitted.

How does this work when you want to log different things? Like if I had a web server, I wouldn't want the server log and access log to go to the same place. Sure, I guess I could send one to stdout and the other to stderr, but what if I have three things? Maybe systemd/journald supports this use case by forcing you to adopt some sort of structured log format that you emit to stdout, but I don't think I want to have t…

Journald indeed supports structured logging. Try `journalctl -o json` to see all the fields that get logged. Applications can add more. So it very much means that a webserver logging to journald can already provide it all with fields for the vhost, status, URL, referer, and whatnot, and you can just search the log by that and don't need to do your own parsing.

Fair, but still annoying. The simple solution, that always works, is to write separate streams to separate files. At least journald supports JSON, and not some proprietary format, though I imagine the particular fields it supports might not be supported by other logging systems.

I'm just tired of all this added complexity, when I don't really see much of the benefit.

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

#458

Post by db48x »

kelnos wrote: post #457
dale_glass wrote: post #202

Earlier quoted context omitted.

Journald indeed supports structured logging. Try `journalctl -o json` to see all the fields that get logged. Applications can add more. So it very much means that a webserver logging to journald can already provide it all with fields for the vhost, status, URL, referer, and whatnot, and you can just search the log by that and don't need to do your own parsing.

Fair, but still annoying. The simple solution, that always works, is to write separate streams to separate files. At least journald supports JSON, and not some proprietary format, though I imagine the particular fields it supports might not be supported by other logging systems. I'm just tired of all this added complexity, when I don't really see much of the benefit.

The point is that you can include arbitrary metadata of your choosing, in addition to the standard fields that journald keeps track of for you. For example, if you include the id of the logged–in user with every message, then when they complain about a bug you can query the journal to find exactly what they did without any noise from all your other users. And you don’t even have to pay a SaaS company for the privilege.

> I'm just tired of all this added complexity, when I don't really see much of the benefit.

There is a lot less for each application to implement on its own, such as log levels, timestamp format, log rotation or even just the paths where logs should go. Instead those details can be configured by the system administrator using a uniform interface across all applications.

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

#459

Post by pkrumins »

nix23 wrote: post #455
pkrumins wrote: post #448

Earlier quoted context omitted.

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

I needed around 5 years to slowly move away from Linux, open/-solaris/omnios/smartos was also in my mind, but...well you probably know the sad story behind it. But FreeBSD really kicks, from firewall to database all the way down, everything FreeBSD ;)

Yes, I know the story. But what about Illumos?

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

#460

Post by nix23 »

pkrumins wrote: post #459
nix23 wrote: post #455

Earlier quoted context omitted.

I needed around 5 years to slowly move away from Linux, open/-solaris/omnios/smartos was also in my mind, but...well you probably know the sad story behind it. But FreeBSD really kicks, from firewall to database all the way down, everything FreeBSD ;)

Yes, I know the story. But what about Illumos?

>Illumos

Well illumos is just the kernel and userland (bit like BSD without ports/packets), Omnios is a really clean "server-distribution" with illumos at it's core but well same problem, not enough eye's and hand's (aka packets, documentation etc). I decided, that FreeBSD is the "more worry-free" solution for me...and still happy.

Post reply on HN