monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Google Summer of Code 2006


From: Ethan Blanton
Subject: Re: [Monotone-devel] Google Summer of Code 2006
Date: Fri, 21 Apr 2006 13:29:36 -0400
User-agent: Mutt/1.5.9i

Richard Levitte - VMS Whacker spake unto us the following wisdom:
> In message <address@hidden> on Fri, 21 Apr 2006 11:29:00 -0400, Ethan Blanton 
> <address@hidden> said:
> eblanton> Richard Levitte - VMS Whacker spake unto us the following wisdom:
> eblanton> > I'm sorry, why can't usher *be* the master server?  Adding
> eblanton> > a master server in between would just add a layer of
> eblanton> > complexity that gives nothing extra in return.
> eblanton> 
> eblanton> I for one would much rather the listening daemon didn't have
> eblanton> to run with root privileges, such that it could execute
> eblanton> servers as other users...
> 
> So your listening server would basically be a proxy that sends bit
> back and forth between a remote client and a local master server
> process.  In what way does that give you extra security?

No, not at all like that.  I would rather, as the previous poster
suggested, usher received the incoming data, and rather than spawning
the monotone server directly (as it does now), it requested a
privileged process to spawn the monotone server on its behalf and then
communicated with that server.

The extra security comes in in that the usher server which listens to
the outside world and the privileged server cooperate in a very simple
and well-defined manner (e.g., perhaps the listening server sends
simply a tuple of {hostname, collection} to the privileged server, and
receives a port number in return).  I believe netsync cannot be
considered a simple and well-defined manner.

> I trust you don't run sshd, apache or any other server that requires
> authentication and authorisation or is capable thereof, btw :-).

For one, sshd and apache have a *lot* more eyeballs looking at them
than monotone does.  For another, most of these types of services use
a very similar plan to what I just outlined -- perhaps you remember
the sshd privsep push a few years back?  What about, for example,
courier using a dedicated process for authentication?  I don't know
about you, but my apache processes which serve pages run as www-data,
not root.

In the very example the previous poster mentioned, postfix has a
"master" process which runs as root and spawns child processes with
the appropriate user ID and privelege level -- for example, opening
the (privileged) port 25 and then handing the handling of that port
off to a process named smtpd which runs as the postfix user.

There is no need to introduce a *new* system which shares the same
fundamental security flaws we have learned to correct in old systems.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]