Re: New developer

[Marcus Brinkmann]

On Sat, Sep 06, 2003 at 05:31:40PM +0200, Bas Wijnen wrote:
> I read hurd-on-l4.tex from the cvs, and have one remark about it.  In
> section 7.1.1, it says about the proc server: "The thread ID can be
> guessed, so there is no point in protecting it."

This is in the context of a signal thread.
 
> This doesn't seem entirely correct to me.  Guessing a thread ID will give
> you a random thread.

This is not what guessing means.  "Foo can be guessed" means that you can
find the right Foo by simply guessing it.  It doesn't matter if you know
that it is the right Foo or not, it just matters that there is a non-zero
chance that you get the right Foo.  At least this is what I meant to say ;)

The point here is that L4 allows all threads to send messsages to any other
thread directly.  As the authentication can only be checked _after_
accepting the message, there is no point in hding the thread ID.

There is an exception: L4 allows to enforce a redirector thread.  We
purposefully don't want to use it because of the overhead on IPC.

> You can check with the task server if it exists, but
> you don't have any other info about it (not even which PID it belongs to,
> or which user owns it.)  The proc server will reply to a query, probably
> coupling a thread ID to a PID.  This coupling is information that cannot
> be verified when guessed (if I understand it correctly.)  I know the
> grsecurity patch to linux allows you to block other users from getting
> process info (like the PID).

I don't see the point in this.  This is security by obscurity, which is
flawed.  If you don't know the PID, just try all 30000 PIDs or whatever the
number is that Linux uses, one after another.  If you know that a particular
server is started at boot time, you might even be able to pin it down to a
small range, for example.

If you want to disable a user t make arbitrary IPC to other threads, you can
put him behind a trusted redirector.  But this is an advanced security feature
we will not have in a first version.

> I have some questions about what I can do, and how.

First of all, you can become an expert on POSIX, the Hurd and L4.  All of
this is needed to make smart design decisions.

>  I'd like to do some 
> low level things, like the taskserver, or the auth server.

These are high level.  Once the things required for the implementation of
these exists, it will be very straigthforward to implement them, and it is
likely that we will do it ourselves.  But still, there is a lot of work to
be done.  But more important than focussing on a single server or something
like that is to get an overall picture and think about the design as a
whole.

I doubt that much can come out of it in terms of real productivity in these
early stages if you don't become a jack of all trades.

> What should I 
> read so I can start with something, with what should I start, and who 
> should know about it?  And if I'm forgetting an important question, please 
> answer that, too.  And don't forget to tell me the question :-)

Well, you should read and understand the L4 specification, and the glibc and
the Hurd source code.  And you should know the design (not necessarily
implementation) of Mach so you know why and what we want to do differently.

And you should know POSIX well or at least have a copy of it (or SuSv3) and
know how to look up issues, so you know what one of the goals is in terms of
the feature set.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/