A few quick searches on google turned up some rather interesting
kernel patches...
sockfs:
http://users.ox.ac.uk/~mbeattie/linux-kernel.html
I'm not quite sure what to make of this. Very interesting, but
I can't imagine having 1024 numbers/socket representations in a
directory is the best way to
On Wed, May 02, 2001 at 02:53:29AM +, Adam Olsen wrote:
> Since there IS a way to do what he wanted, what would it take to make
> it used by default? I'm sure everybody running BIND would feel alot
> safer if it never ran as root, and such a practice would probably earn
> Debian as a whole a
A few quick searches on google turned up some rather interesting
kernel patches...
sockfs:
http://users.ox.ac.uk/~mbeattie/linux-kernel.html
I'm not quite sure what to make of this. Very interesting, but
I can't imagine having 1024 numbers/socket representations in a
directory is the best way to
On Tue, May 01, 2001 at 12:11:30AM +, Jim Breton wrote:
> On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
> > I know that UNIX does it so that normal users can't seem like legit and
> > important services, but there surely must be some better way of delegating
> > a
> > port bel
On Wed, May 02, 2001 at 02:53:29AM +, Adam Olsen wrote:
> Since there IS a way to do what he wanted, what would it take to make
> it used by default? I'm sure everybody running BIND would feel alot
> safer if it never ran as root, and such a practice would probably earn
> Debian as a whole a
Forgive my off & on following of this thread; this may have been mentioned.
Wasn't there a kernel patch at one point detailed in Phrack or some such
that bound the opening of certain priviledged ports to membership in certain
groups? That is, if you belonged to group id 20 (say), you could ope
On Tue, May 01, 2001 at 12:11:30AM +, Jim Breton wrote:
> On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
> > I know that UNIX does it so that normal users can't seem like legit and
> > important services, but there surely must be some better way of delegating a
> > port below 1
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
>
> I know that UNIX does it so that normal users can't seem like legit and
> important services, but there surely must be some better way of delegating a
> port below 1024 to a deamon.
*DISCLAIMER* I do not know exactly what I'm talk
Forgive my off & on following of this thread; this may have been mentioned.
Wasn't there a kernel patch at one point detailed in Phrack or some such
that bound the opening of certain priviledged ports to membership in certain
groups? That is, if you belonged to group id 20 (say), you could ope
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
>
> I know that UNIX does it so that normal users can't seem like legit and
> important services, but there surely must be some better way of delegating a
> port below 1024 to a deamon.
*DISCLAIMER* I do not know exactly what I'm tal
At 07:19 AM 4/29/01 -0400, you wrote:
Hi
I know that this might sound like a stupid question, but its one that has
been bugging me.
Why does UNIX continue to give root access to all deamons below port 1024?
I know that UNIX does it so that normal users can't seem like legit and
important servi
Andres Salomon <[EMAIL PROTECTED]> writes:
> > The current method you describe was vulnerable to bugs concerning
> > setuid(), as per the 2.2.15->16 bug found by sendmail - having come
> > from root and called stuid() to become someone else, it was still
> > possible to return to being root, at wh
At 07:19 AM 4/29/01 -0400, you wrote:
>Hi
>
>I know that this might sound like a stupid question, but its one that has
>been bugging me.
>
>Why does UNIX continue to give root access to all deamons below port 1024?
>
>I know that UNIX does it so that normal users can't seem like legit and
>importa
On Tue, May 01, 2001 at 11:25:49AM +0100, Tim Haynes wrote:
>
> Andres Salomon <[EMAIL PROTECTED]> writes:
>
> > Perhaps I'm misunderstanding your proposition, but how is this different
> > than, say, having inetd listen on ports below 1024, and then
> > forking/changing to a different user once
On Tue, May 01, 2001 at 10:11:45AM +, Adam Olsen wrote:
>
> On Tue, May 01, 2001 at 05:48:54AM -0400, Andres Salomon wrote:
> > Perhaps I'm misunderstanding your proposition, but how is this different
> > than, say, having inetd listen on ports below 1024, and then
> > forking/changing to a di
Andres Salomon <[EMAIL PROTECTED]> writes:
> Perhaps I'm misunderstanding your proposition, but how is this different
> than, say, having inetd listen on ports below 1024, and then
> forking/changing to a different user once a connection is made to the
> port?
The current method you describe was
On Tue, May 01, 2001 at 05:48:54AM -0400, Andres Salomon wrote:
> Perhaps I'm misunderstanding your proposition, but how is this different
> than, say, having inetd listen on ports below 1024, and then
> forking/changing to a different user once a connection is made to the port?
>
To use inetd, a
Perhaps I'm misunderstanding your proposition, but how is this different
than, say, having inetd listen on ports below 1024, and then
forking/changing to a different user once a connection is made to the port?
[EMAIL PROTECTED] drive2]# echo "finger stream tcp nowait nobody /usr/bin/id"
>> /etc/
Andres Salomon <[EMAIL PROTECTED]> writes:
> > The current method you describe was vulnerable to bugs concerning
> > setuid(), as per the 2.2.15->16 bug found by sendmail - having come
> > from root and called stuid() to become someone else, it was still
> > possible to return to being root, at w
On Tue, May 01, 2001 at 11:25:49AM +0100, Tim Haynes wrote:
>
> Andres Salomon <[EMAIL PROTECTED]> writes:
>
> > Perhaps I'm misunderstanding your proposition, but how is this different
> > than, say, having inetd listen on ports below 1024, and then
> > forking/changing to a different user once
On Tue, May 01, 2001 at 10:11:45AM +, Adam Olsen wrote:
>
> On Tue, May 01, 2001 at 05:48:54AM -0400, Andres Salomon wrote:
> > Perhaps I'm misunderstanding your proposition, but how is this different
> > than, say, having inetd listen on ports below 1024, and then
> > forking/changing to a d
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
>
> A while ago, I remember reading on slashdot about how TrustedBSD and OpenBSD
> were different from each other.
http://www.sigmasoft.com/cgi-bin/wilma/openbsd-misc
use a "restricted files match" for Apr 2001
search for "acl" or "t
Andres Salomon <[EMAIL PROTECTED]> writes:
> Perhaps I'm misunderstanding your proposition, but how is this different
> than, say, having inetd listen on ports below 1024, and then
> forking/changing to a different user once a connection is made to the
> port?
The current method you describe was
On Tue, May 01, 2001 at 05:48:54AM -0400, Andres Salomon wrote:
> Perhaps I'm misunderstanding your proposition, but how is this different
> than, say, having inetd listen on ports below 1024, and then
> forking/changing to a different user once a connection is made to the port?
>
To use inetd,
Perhaps I'm misunderstanding your proposition, but how is this different
than, say, having inetd listen on ports below 1024, and then
forking/changing to a different user once a connection is made to the port?
[root@incandescent drive2]# echo "finger stream tcp nowait nobody /usr/bin/id" >>
/et
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
>
> A while ago, I remember reading on slashdot about how TrustedBSD and OpenBSD
> were different from each other.
http://www.sigmasoft.com/cgi-bin/wilma/openbsd-misc
use a "restricted files match" for Apr 2001
search for "acl" or "
On Mon, Apr 30, 2001 at 08:04:50PM -0400, Jacob Kuntz wrote:
> > Why does UNIX continue to give root access to all deamons below port 1024?
>
> Other way around. In order to bind to ports <1024 a process must have uid 0.
on linux 2.2 and later this is wrong, see below.
> Interesting idea. I had
On Mon, Apr 30, 2001 at 08:04:50PM -0400, Jacob Kuntz wrote:
> > Why does UNIX continue to give root access to all deamons below port 1024?
>
> Other way around. In order to bind to ports <1024 a process must have uid 0.
on linux 2.2 and later this is wrong, see below.
> Interesting idea. I had
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
> I know that UNIX does it so that normal users can't seem like legit and
> important services, but there surely must be some better way of delegating a
> port below 1024 to a deamon.
Well, at least on Linux, and with the right set of
from the secret journal of Sunny Dubey ([EMAIL PROTECTED]):
> Hi
>
> I know that this might sound like a stupid question, but its one that has
> been bugging me.
No such animal.
>
> Why does UNIX continue to give root access to all deamons below port 1024?
Other way around. In order to bind t
Ummm.. you got it a bit backwards... UNIX does not *give* root access to
daemons below 1024... The program (not necessasarily a daemon) must HAVE
root access before it can bind to a port below 1024.
That said, you may be on to something. It sounds like a good idea to
me... but that doesn't necessa
Hi
I know that this might sound like a stupid question, but its one that has
been bugging me.
Why does UNIX continue to give root access to all deamons below port 1024?
I know that UNIX does it so that normal users can't seem like legit and
important services, but there surely must be some bet
On Sun, Apr 29, 2001 at 07:19:06AM -0400, Sunny Dubey wrote:
> I know that UNIX does it so that normal users can't seem like legit and
> important services, but there surely must be some better way of delegating a
> port below 1024 to a deamon.
Well, at least on Linux, and with the right set of
from the secret journal of Sunny Dubey ([EMAIL PROTECTED]):
> Hi
>
> I know that this might sound like a stupid question, but its one that has
> been bugging me.
No such animal.
>
> Why does UNIX continue to give root access to all deamons below port 1024?
Other way around. In order to bind
Ummm.. you got it a bit backwards... UNIX does not *give* root access to
daemons below 1024... The program (not necessasarily a daemon) must HAVE
root access before it can bind to a port below 1024.
That said, you may be on to something. It sounds like a good idea to
me... but that doesn't necess
Hi
I know that this might sound like a stupid question, but its one that has
been bugging me.
Why does UNIX continue to give root access to all deamons below port 1024?
I know that UNIX does it so that normal users can't seem like legit and
important services, but there surely must be some be
36 matches
Mail list logo
