Hacker News Reader

Comment by charcircuit | Hacker News Reader

The existence of the root user is bad security. Any distro serious about security should disable it and strip it of as much power as possible. It is such a juicy target for attackers due to how much power it has and most distros protect it poorly by having programs such as sudo installed allowing an attacker to easily escalate their privileges.

View on HN

Nah. Root user actual capabilities can be limited in a number of ways.

On RHEL this is done by default via SELinux.

If you define a policy that prevents anyone from doing kexec, and enable the boolean to prevent root from disabling enforcing mode for selinux, there you go, done with tools that have been available for ~15-20 years.

Has SELinux become configurable on the command-line with well documented tools? Does it still occasionally decide to "relabel files" for 10 hours on a random reboot?

It's a great mechanism in theory, but the practice leaves much to be desired.

It's a great mechanism in practice, it just has a bad rep because too many were scared by the complexity.

The complexity is a self-inflicted problem. This is a rake that many computer security people refuse to stop stepping on. If it's not usable then it doesn't work.

FWIW it does look like Gentoo stepped up and filled in the gaps since I last looked. Their Wiki has good docs starting from https://wiki.gentoo.org/wiki/SELinux.

Yes and no. But the thing is... SELinux does complex stuff. You can simplify that, but only to a certain point.

If you dumb it down too much it becomes useless. Simple tools usually get their simplicity by making some choices for you. You don't always want that.

SELinux is one of those things where you don't want that.

That being said, without diving too much, I have configured many custom services to run under SELinux by just running them in a dev/staging environment, collecting violations and creating policies via the audit2allow tool. So yeah, things have improved I guess.

In my experience, SELinux is the sort of thing you avoid unless you're forced to use it, then when you are forced to use it, you're encouraged to stumble around until you get it out of your way, then forget about it until it gets in your way again.

Good documentation and good tools would encourage more people to use it and understand it willingly and effectively.

Can selinux be configured to prevent root from loading a kernel module..?

yes.

Well TIL. I had no idea SELinux was so user hostile.

Yes, it is hostile to malicious users, that’s by design and it’s a feature.

That being said, it can be configured that way but (of course, duh) it’s not the default setting.

I’ll stop replying here because this branch of the discussion doesn’t seem to be any constructive on your side (or even conducted in good faith, to be honest)

The problem is, there's a very very narrow line between restricting what the user can do on their system for the user's benefit and restricting what the user can do on their system for your benefit as the manufacturer/whatever. That's what makes the idea of restricting the root user so uncomfortable.

Now you’re being dishonest and posting actual bs.

There is no such line. Everything is foss software, you can change any policy.

You can still do everything you want.

This is literally what people said about Android until it wasn't true anymore though.

We're fundamentally talking about building up pieces in a "chain of trust" which allows the entity in charge of the UEFI to decide what can and can't be done with the system. That's a scary thing.

How do you propose that the owner of a system should be able to administer it?

The distro maintainers should make sure the operating system works well on its own. For what needs to be customized there can be a settings application and individual applications can expose ways for themselves to be customized.

You want distro maintainers to have final control instead of hardware owners? Isn't that arguing for the iOS-ification of Linux?

I want distros to make an operating system that actually works and doesn't need to be fiddled with. Hardware owners shouldn't have to be the ones fixing the operating system. Most people just want their computer to work and don't want to learn about the internals of how it works. If a user really cares about changing the internals he can make his own operating system.

>Isn't that arguing for the iOS-ification of Linux?

Linux distros could learn a thing or two (or 100) from how iOS handles security.

> I want distros to make an operating system that actually works and doesn't need to be fiddled with.

Doesn't need to be fiddled with? Sure. Can't be fiddled with? No way.

> Hardware owners shouldn't have to be the ones fixing the operating system.

Ditto. Owners shouldn't have to fix it, but they should be able to.

> Most people just want their computer to work and don't want to learn about the internals of how it works.

Most people, sure. So don't make them learn. But don't prevent people from learning if they want to.

> If a user really cares about changing the internals he can make his own operating system.

Wouldn't this mean that incremental improvements wouldn't be possible anymore?

> Linux distros could learn a thing or two (or 100) from how iOS handles security.

How so specifically?

>Wouldn't this mean that incremental improvements wouldn't be possible anymore?

One can make a fork of the distro and then make the change you want to incrementally improve it.

>How so specifically?

Reading the documentation and reading information about its internals.

Why though?

How is that better than what we have now, where a system can be easily modified in-place without every distro needing dozens of forks for each slight preference change?

What exactly is it you're advocating for?

>Why though?

Because most Linux distros have terrible security.

>How is that better than what we have now, where a system can be easily modified in-place without every distro needing dozens of forks for each slight preference change?

Preferences can be done via configuration. Most people do not actually want or need to modify the operating system.

>What exactly is it you're advocating for?

The root user to be effectively removed.

> Linux distros could learn a thing or two (or 100) from how iOS handles security.

Sorry no, I don't want my Linux to become like iOS. iOS security model "all powers to the manufacturer" is broken model and doesn't work.

> If a user really cares about changing the internals he can make his own operating system.

Don't we already have that, and it's called... Linux?

iOS handles security by having a completely integrated ecosystem. Linux has to work on a wide range of hardware, basically none of which is under the control of anyone involved in Linux (kernel, GNU, distro, etc). Even Microsoft can't exercise Apple levels of control over the PC platform, and they have 100 times the revenue of the largest Linux distro.

> individual applications can expose ways for themselves to be customized.

They do. That way is exposing files in /etc that the administrator account can edit.

Unfortunately these files in /etc usually can only be edited by root. What could be done is allow a user from the administrator group to edit such files.

A user from the administrator group has all the same power that the root user does.

Or, labeled differently, the root user is the administrator group.

No, for example the root user can read any file on the system. If someone gains access to the root user they shouldn't also gain the ability to read and write to every file on the system.

How should I be able to read any file on the system on a device I own, if not with the root user?

I don't think this makes much sense to have to avoid empowering stealer malware. It would be better to find what the actual user need is and make a proper API to expose that functionality.

I don’t think anybody would use or develop a system like that. It would put too much responsibility in the hands of the (volunteer) maintainers. Trying to guess what use-case everybody will have is a horrible tooth-pulling and bikesheding exercise that nobody would do for fun.

That said there’s nothing stopping you from trying it. It just seems unlikely to succeed.

It's no more responsibility than what already exists. Telling end users to go and fix the operating system themselves was never acceptable to do.

>Trying to guess what use-case everybody will have is a horrible tooth-pulling and bikesheding exercise that nobody would do for fun.

You seem to be misunderstanding what I am saying. People could still install new applications, or uninstall preexisting applications just like how it works now.

I guess I don’t know what you are suggesting

How do I install a custom kernel module in your model

Using something like sudo. Parent is not saying remove root entirely but that it should be super locked down and maybe broken up into different accounts.

I think they are saying to remove root entirely?

If the solution is just "use sudo" then what's the difference compared to today's model?

Instead of sudoing to the root account, you would sudo to the network account that could only do network admin, or sudo to the software-install account that could only install packages, etc.

You should install it from the distro's package manager. If it's not cryptographically signed by the distro you have to fork the operating system to add another key to trust. A custom kernel module has immense security implications so it shouldn't be easy to do as an attacker shouldn't be able to trick someone into installing one for free vbucks.

My distro's repositories don't contain my newly written custom kernel module

Most users aren't writing their own custom kernel modules and using them on their current install instead of qemu. This is a niche use case that the average user's security shouldn't be compromised for.

It's an important use case that the system shouldn't lock the user out of.

Have you ever used anything that uses DKMS? Should you have had to make your own operating system kernel instead?

DKMS already supports signed kernel modules.

It supports them by creating its own private key and signing them on your system. That's inherently incompatible with only trusting modules from your distro vendor.

You are right only the distro's build servers would be able to use DKMS as the distro couldn't ship the private key.

That's fundamentally not how DKMS works.

I think sudo done well could be exactly what you're advocating for: configure all possible commands that a user should be allowed to execute as superuser for ordinary and extra-ordinary maintenance and prohibit everything else (especially sudo -i).

I make liberal use of sudo -i on my personal Linux machines, because otherwise I have to prefix sudo to 99% of my commands and be arsed to enter passwords if I dilly dally too long between commands.

If you have to prefix almost all of your commands with sudo, either your usage is highly irregular or your problem is mostly caused by poor file permissions resulting from overuse of sudo.

I don't as doing that is as bad as suid binaries except now the binaries aren't even hardened. suid binaries shouldn't exist either.

What would you replace suid binaries with? Just getting rid of suid without replacement would totally break your system.

Normal binaries that talk to services running as other users who have the minimal possible permissions. For example instead having users run ping as the root user using suid, you instead have a ping client talk to a ping service on the system. The ping service runs as a user with the raw sockets capability and nothing else.

How is that an improvement over just giving the ping binary on disk that capability? And how would "su" and "sudo" work in your model?

>How is that an improvement over just giving the ping binary on disk that capability?

That would be okay too, but not all suid usages can be replaced like that.

>And how would "su" and "sudo" work in your model?

They wouldn't exist in my model.

Reply on news.ycombinator.com