A new model for ports and kernel security?

It will not surprise me if this topic has been discussed before but my search of the archives did not turn up anything meaningful.

I have a question and a suggestion.

What I'm wondering is, why do we have this requirement that only root processes can connect to low ports (under 1024) ?

My understanding is that this is a hold-over from ancient days gone past where it was meant to be a security feature. Since only root processes can listen on ports less than 1024, you could "trust" any connection made to a low port to be "secure". In other words, nobody could be "bluffing" on a telnet port that didn't have root access therefore it was "safe" to type in your password.

I don't know if the above is the real reason or not but if it is, clearly it has outlived its usefulness as a "security" feature.

Regardless, does not the requirement that only root can bind to low ports now create more of a security problem than it ever solved?

Are not processes forced to run as root (at least at startup) that have security holes in them not the leading cause of "remote root exploits"?

So if the root-low-port requirement isn't serving any purpose and is indeed the cause of security problems is it not time to do away with it?

Furthermore, while only root can bind to low-ports, ANY user can bind to high ports. This also causes a ton of security concerns as well!

So I would like to propose the following improvement to kernel security and I invite your comments.

Suggestion: A groups based port binding security system for both outgoing and incoming port binding.

For example, the group "root" is allowed to listen to ports "*" (all) and allowed outgoing connections to "*" (all) as well.

The group "www" would be allowed to bind to ports "80, 443" (http, https) and not allowed ANY outgoing connections.

The group "mail" (or postfix, or whatever) would be allowed to listen to port "25" (smtp) and connect to "25".

The group "users" would not be allowed to listen at all but might be allowed to connect to 20-21, 80, 443.

etc.

This accomplishes two major things:

- no process ever needs to run as root.

- no unauthorized process can ever listen on a port or make connections. On servers that allow remote users this prevents things like bots, spam relays, ftp drops and all sorts of mischief.

I envision a simplistic "/etc/ports" with the format, "<groupid>,<incoming ports>,<outgoing ports>"

I realize similar things can be accomplished in other ways (with iptables I believe) but it just seems to me that this should be a fundamental part of the systems security and therefore should be in the kernel by default (just as the root binding to low ports is currently).

I hereby make the disclaimer that I am not a kernel hacker, just a sysadmin. So feel free to give me the smackdown if this violates some kernel rule.

John Lange

Something like this for port binding exists as an external patch:
http://www.olafdietsche.de/linux/accessfs/

We should keep the standard behavior as default in the core kernel. Other security models can be implemented via LSM, Netfilter, config options etc.

- James

James Morris
<[email protected]>

A few people suggested various patches which implement a similar functionality to what I was suggesting and I thank them for that.

I think this clearly demonstrates that there is a demand for such a feature.

I believe there are several compelling reasons why the standard behaviour should be changed.

- patches are not a real solution. As a sysadmin I can't afford the extra headache of applying patches after the fact every time I need to upgrade the kernel. Also, if there is an urgent patch to the kernel then I would have to wait for the external patch to be updated before I could do a kernel compile. So generally external patches are problematic for your standard sysadmin.

- If the functionality is not built into the standard behaviour then no one will code for it.

- If it is generally agreed that the current behaviour is outdated and creates problems with security then we have to ask "Is there any compelling reason to keep it?" Would linux with the patch not be a better, more secure Linux?

Backward compatibility would not be a problem because most programs just try and grab the port and error if they can't get it. They would work fine under the /etc/ports idea.

Any other programs that might have problems (for example any which check to see if they are root before starting) can still be started as root. Again, no problem.

So, why not?

John Lange
BigHostBox.com ltd

Not really - that is why they have been external for several years.

The LSM is part of the kernel. Any/most enhanced security modules may be loaded without patching the core. Second, it is possible to alter some modules policy on the fly for an additional control.

Not directly relevent, though it is for maintenance.

No. It completely disallows those applications (ie, grid, legion, and any other distributed application) from functioning for general users. Since these users choice of application is generally unknown, you would also have to generate a group of ports dynamically.

Also, since group membership is controling ACCESS functions, you end up sharing more than what you want. Your purpose is to have "group" apply to port access, yet "group" also applies to file access. You REALLY don't want to mix these.

Application porting compatabiltiy. Right now all that is necessary is to recompile the application. With the patch, you also have to figure out how to apply appropriate ports to the application, and you don't know ahead of time how many ports to allocate. Grid applications tend to have one port for each node they communicate with. If two users generate a 5 way connection you have to give two sets of groups... If the user then wants a 10 way you have to reallcate again.

This is insufficent flexibility. What you want is to tie each port to a capability (or tie port allocation to a capability) and then grant the user the capability to allocate ports. This really calls for a LSM based module that can pass the request to a security daemon to permit/deny port allocation based on external rules.

This would be more flexable, maintainable, and is less intrusive of the kernel core.

I admit my knowledge of LSM is very limited. If your saying that the functionality I'm suggesting can be made into a module that will won't require a new version every time a new version of the kernel comes out then fantastic!

My major concern with external kernel patches and or modules is that they lag (sometimes significantly) kernel versions. If a given kernel contains a critical fix (say a security issue) and no new version of your module/patch is immediately available then you are in serious trouble.

I don't see how what I'm suggesting would have the effect you are describing. The default configuration would mimic the current functionality so nothing would change for the average user.

People who want to tighten things would implement the port security as required.

As a parallel, look at when IPTables was added to the kernel. By default it basically does nothing so for average end user nothing is broken. You tighten it as required.

Perhaps a very good point. I suggested adding it as an extension of the existing group system for the sake of simplicity. Why should the user/groups security model be limited to only the file system? And its already mixed since it effectively controls access to devices (via the file system).

If I can specify which users and groups can access my floppy drive, why can't I specify which users can bind to my ports?

I touched on this above. Since the change I'm suggesting would leave the system configured to act exactly as it does now there would be no compatibility issues.

Admins who are used to starting everything "important" as root can still do that if they wish.

Only people who want better security via complete control over their ports would deviate from the current functionality.

An LSM based module sounds great to me provided it has the functionality I'm suggesting and its distributed with the kernel.

I wish I had the skill and time to create one.

Thanks for your insight Jesse. Very informative.

John Lange

I would hope that it is more because the grsecurity documentation suggests it is still a work in progress. Perhaps its author might consider dividing his work up into smaller patches for Linus to consider.

The original poster was right that restricting ports below 1024 is an unclean hack, and a poor substitute for a better permissions model. Unfortunately it is an unclean hack in an area where it is difficult for society to achieve the decision needed for change.

Hans

I believe this sort of thing is already in the grsecurity patch.

See http://www.grsecurity.org

It was for rlogin-like accesses, too - the server knew the client is a suid and trusted program.
Think - NFS.

Not commonly. They usually change ownership to something like www.www and that is what the exploit gains first.

Krzysztof Halasa, B*FH