Re: Is this mail list dead?

[Raju Mathur <raju@linux-delhi.org>]

Hi,

Why would any non-system process /need/ to bind to a port below 1024?
Or has this question already been answered?

On a related note, IRIX (SGI) permits fine-grained access levels by
giving specific low-level permissions to processes (through the CAP_*
feature).  One of the permissions is that of being able to bind to a
port below 1024.  This is possibly true of other Unixen too.  Linux
also seems to support this feature, though I don't see much discussion
of its usage except for a few isolated posts and writeups at Bugtraq.
Isn't this what should be used to grant capabilities to processes
which need to run mainly with user privileges except for a few
system-level access requirements?  Sendmail comes to mind :-)

More information in /usr/include/linux/capability.h, man setcap.

Regards,

-- Raju

>>>>> "Neale" == Neale Banks <neale@lowendale.com.au> writes:

    Neale> On Mon, 12 Mar 2001, Coltrey Mather wrote:
    >> On Mon, 12 Mar 2001, Tracy R Reed wrote:
    >> 
    >> > Is there really any reason to require programs to be run as
    >> root to bind > to ports <1024 anymore? I was just discussing
    >> this with some friends after > the regular LUG meeting at
    >> Denny's the other day. That's where the best > LUG conversation
    >> happens. :) There used to be a good reason for it but >
    >> nowadays it seems like an unnecessary liability. Fixing this is
    >> probably a > very simple little patch.
    >> 
    >> I think it would be better if there were an option to allow
    >> non-root access to certain ports (controlled by some file in
    >> /proc/sys/ perhaps?).

    Neale> So long as:

    Neale> 1) existing behavious remains default

    Neale> 2) only root can make this adjustment ;-)

    >> I wouldn't want a malicious shell user on my system (I only use
    >> ssh for logins) to run a fake telnet server on port 23 to
    >> confuse other users and collect passwords.  The potential for a
    >> malicious user to abuse trust that people have in standard
    >> system services is something to take into consideration for
    >> something like this.

    Neale> Good point.  But it doesn't necessarily follow that
    Neale> root-user privs are required to enforce this.

    >> Perhaps in addition to just filtering by user, there should be
    >> a method to filter by application.  e.g.: only a certain piece
    >> of software could bind to a port...'though I'm not sure if/how
    >> that could be implemented. (maybe have the kernel check the
    >> commandline of the process against a list of allowed commands
    >> in /proc/ somewhere.)  One could also combine some sort of
    >> signature verification with this so the kernel can determine if
    >> the application has been modified.

    Neale> "filter by application" could inded be a bit tricky - and
    Neale> security is often (always?) easier to maintain in "simple"
    Neale> systems.

    Neale> How about starting with "group" permissions?  There's a few
    Neale> ways this could be implemented, starting with something
    Neale> really simple like membership of group 0 (or 1?) being
    Neale> sufficient for binding to a port.

    Neale> More elaborate schemes might do something like representing
    Neale> the TCP and UDP port-space in a virtual file system and
    Neale> allowing the nodes therein to have their permissions
    Neale> changed.

    Neale> On a more down-to-earth level, how many distro's can run
    Neale> out-of-the box without inetd?  Or at least without
    Neale> portmapper?

    Neale> Regards, Neale.

-- 
Raju Mathur          raju@kandalaya.org           http://kandalaya.org/
-
Securedistros: A common list for all secured Linux distributions
Archive:       http://humbolt.nl.linux.org/lists/