public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Lange <john.lange@bighostbox.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Valdis.Kletnieks@vt.edu, mcmanus@ducksong.com, jmorris@redhat.com
Subject: Re: A new model for ports and kernel security?
Date: Wed, 01 Oct 2003 20:45:04 -0500	[thread overview]
Message-ID: <1065059104.5142.133.camel@mars> (raw)
In-Reply-To: <Pine.LNX.4.44.0310011523510.14121-100000@thoron.boston.redhat.com>

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



  reply	other threads:[~2003-10-02  1:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-01 19:06 A new model for ports and kernel security? John Lange
2003-10-01 19:27 ` James Morris
2003-10-02  1:45   ` John Lange [this message]
2003-10-02 13:22     ` Jesse Pollard
2003-10-02 14:30       ` John Lange
2003-10-06  8:06       ` Hans Reiser
2003-10-01 19:28 ` Valdis.Kletnieks
2003-10-01 20:10 ` Krzysztof Halasa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1065059104.5142.133.camel@mars \
    --to=john.lange@bighostbox.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=jmorris@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcmanus@ducksong.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox