A new model for ports and kernel security?

A new model for ports and kernel security?

[John Lange]

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

Re: A new model for ports and kernel security?

[James Morris]

On Wed, 1 Oct 2003, John Lange wrote:

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

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

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

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
<jmorris@redhat.com>

Re: A new model for ports and kernel security?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 283 bytes --]

On Wed, 01 Oct 2003 14:06:23 CDT, John Lange <john.lange@bighostbox.com>  said:

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

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

See http://www.grsecurity.org

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: A new model for ports and kernel security?

[Krzysztof Halasa]

John Lange <john.lange@bighostbox.com> writes:

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

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

> 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"?

Not commonly. They usually change ownership to something like www.www
and that is what the exploit gains first.
-- 
Krzysztof Halasa, B*FH

Re: A new model for ports and kernel security?

[John Lange]

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.

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

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


On Wed, 2003-10-01 at 14:27, James Morris wrote:
> On Wed, 1 Oct 2003, John Lange wrote:
> 
> > Suggestion: A groups based port binding security system for both
> > outgoing and incoming port binding.
> 
> Something like this for port binding exists as an external patch:
> http://www.olafdietsche.de/linux/accessfs/
> 
> > 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).
> 
> 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

Re: A new model for ports and kernel security?

[Jesse Pollard]

On Wednesday 01 October 2003 20:45, John Lange wrote:
> 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.

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

> > We should keep the standard behavior as default in the core kernel. 
> > Other security models can be implemented via LSM, Netfilter, config
> > options etc.
>
> 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.

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.

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

Not directly relevent, though it is for maintenance.

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

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.

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

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.

Re: A new model for ports and kernel security?

[John Lange]

On Thu, 2003-10-02 at 08:22, Jesse Pollard wrote:
> > - 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.
> 
> 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.

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.

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

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.

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

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?

> > So, why not?
> 
> 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.

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.

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

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

Re: A new model for ports and kernel security?

[Hans Reiser]

Jesse Pollard wrote:

>On Wednesday 01 October 2003 20:45, John Lange wrote:
>  
>
>>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.
>>    
>>
>
>Not really - that is why they have been external for several years.
>  
>
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