getpeercred() on the Hurd

[Arthur de Jong-2]

Hello list (I'm not subscribed so please keep me in Cc).

I'm the maintainer of nss-ldapd. I saw that the package was recently
built for GNU Hurd. I haven't tested the package on Hurd but there is
one (not very critical) thing that shows up while compiling.

What is the best way on the Hurd to get information about
clients that connect through a named socket?

I currently use this code:
http://arthurenhella.demon.nl/viewcvs/nss-ldapd/nss-ldapd/compat/getpeercred.c?view=markup
which works on a number of platforms but uses the fallthrough code at
the end on the Hurd.
http://buildd.debian-ports.org/fetch.php?pkg=nss-ldapd&arch=hurd-i386&ver=0.6.3&stamp=1213622648&file=log&as=raw

--
-- arthur - adejong@... - http://people.debian.org/~adejong --

[Neal H. Walfield]

At Tue, 17 Jun 2008 22:49:16 +0200,
Arthur de Jong wrote:

>
> Hello list (I'm not subscribed so please keep me in Cc).
>
> I'm the maintainer of nss-ldapd. I saw that the package was recently
> built for GNU Hurd. I haven't tested the package on Hurd but there is
> one (not very critical) thing that shows up while compiling.
>
> What is the best way on the Hurd to get information about
> clients that connect through a named socket?
>
> I currently use this code:
> http://arthurenhella.demon.nl/viewcvs/nss-ldapd/nss-ldapd/compat/getpeercred.c?view=markup
> which works on a number of platforms but uses the fallthrough code at
> the end on the Hurd.
> http://buildd.debian-ports.org/fetch.php?pkg=nss-ldapd&arch=hurd-i386&ver=0.6.3&stamp=1213622648&file=log&as=raw

One question you should consider is: why do you need this information?
Identity based access control (IBAC) is quite insecure relative to
authorization based access control (ABAC).  The idea behind ABAC is
that if a subject has the "key" (in this case, if the subject has
access to a file descriptor designating the unix domain socket), then
it most likely got it through an authorization channel.  Perhaps it
was delegated as the program using it uses privilege separation.  So
the actor's identity does not matter and may inhibit such useful
structuring.  On all modern Unixes that I know of, opening a unix
domain socket respects the access bits on the file.  Thus, the file
descriptor should be sufficient proof that the caller has the right to
use the object.

Neal


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Arthur de Jong-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> One question you should consider is: why do you need this information?
[...]

I agree with your point in general and think there are better ways to
do access control.

nss-ldapd is an NSS module that does lookups in an LDAP database. The NSS
module does not do the lookup itself (this causes a lot of headaches) but
offloads it to a deamon (nslcd). Most NSS calls should be no problem but
shadow calls pose an exception to that. The server (nslcd) will only
return shadow information if it can determine that the caller runs as
root.

So I would like to keep one socket for all requests and not mess with
permissions of sockets.

- --
- -- arthur - adejong@... - http://people.debian.org/~adejong --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIWOFdVYan35+NCKcRAiENAKCSR2Uz8FL/MEu7nwYWM5Rjx5gQOwCeMyv3
S9uSuXFiixTL3EhEM2mIEkM=
=D17I
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neal H. Walfield]

At Wed, 18 Jun 2008 12:20:10 +0200 (CEST),
Arthur de Jong wrote:

> > One question you should consider is: why do you need this information?
> [...]
>
> I agree with your point in general and think there are better ways to
> do access control.
>
> nss-ldapd is an NSS module that does lookups in an LDAP database. The NSS
> module does not do the lookup itself (this causes a lot of headaches) but
> offloads it to a deamon (nslcd). Most NSS calls should be no problem but
> shadow calls pose an exception to that. The server (nslcd) will only
> return shadow information if it can determine that the caller runs as
> root.
>
> So I would like to keep one socket for all requests and not mess with
> permissions of sockets.

Sounds broken.  Good luck.


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neal H. Walfield]

At Wed, 18 Jun 2008 12:41:48 +0200,
Neal H. Walfield wrote:

>
> At Wed, 18 Jun 2008 12:20:10 +0200 (CEST),
> Arthur de Jong wrote:
> > > One question you should consider is: why do you need this information?
> > [...]
> >
> > I agree with your point in general and think there are better ways to
> > do access control.
> >
> > nss-ldapd is an NSS module that does lookups in an LDAP database. The NSS
> > module does not do the lookup itself (this causes a lot of headaches) but
> > offloads it to a deamon (nslcd). Most NSS calls should be no problem but
> > shadow calls pose an exception to that. The server (nslcd) will only
> > return shadow information if it can determine that the caller runs as
> > root.
> >
> > So I would like to keep one socket for all requests and not mess with
> > permissions of sockets.
>
> Sounds broken.  Good luck.

That wasn't very helpful.  If you are dead set on using IBAC, you
could use the auth protocol to establish the identify of the client.
The interface is described in auth/auth.defs .

Neal


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault]

Neal H. Walfield, le Wed 18 Jun 2008 13:43:41 +0200, a écrit :

> At Wed, 18 Jun 2008 12:41:48 +0200,
> Neal H. Walfield wrote:
> >
> > At Wed, 18 Jun 2008 12:20:10 +0200 (CEST),
> > Arthur de Jong wrote:
> > > > One question you should consider is: why do you need this information?
> > > [...]
> > >
> > > I agree with your point in general and think there are better ways to
> > > do access control.
> > >
> > > nss-ldapd is an NSS module that does lookups in an LDAP database. The NSS
> > > module does not do the lookup itself (this causes a lot of headaches) but
> > > offloads it to a deamon (nslcd). Most NSS calls should be no problem but
> > > shadow calls pose an exception to that. The server (nslcd) will only
> > > return shadow information if it can determine that the caller runs as
> > > root.
> > >
> > > So I would like to keep one socket for all requests and not mess with
> > > permissions of sockets.
> >
> > Sounds broken.  Good luck.
>
> That wasn't very helpful.  If you are dead set on using IBAC, you
> could use the auth protocol to establish the identify of the client.
> The interface is described in auth/auth.defs .

Well, I guess he doesn't have a running Hurd system.

Actually I guess we could easily add SO_PASSCRED to pflocal sockets, by
using auth_user_authenticate/auth_server_authenticate indeed.

Samuel


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Samuel Thibault]

Samuel Thibault, le Wed 18 Jun 2008 12:56:53 +0100, a écrit :

> Neal H. Walfield, le Wed 18 Jun 2008 13:43:41 +0200, a écrit :
> > At Wed, 18 Jun 2008 12:41:48 +0200,
> > Neal H. Walfield wrote:
> > >
> > > At Wed, 18 Jun 2008 12:20:10 +0200 (CEST),
> > > Arthur de Jong wrote:
> > > > > One question you should consider is: why do you need this information?
> > > > [...]
> > > >
> > > > I agree with your point in general and think there are better ways to
> > > > do access control.
> > > >
> > > > nss-ldapd is an NSS module that does lookups in an LDAP database. The NSS
> > > > module does not do the lookup itself (this causes a lot of headaches) but
> > > > offloads it to a deamon (nslcd). Most NSS calls should be no problem but
> > > > shadow calls pose an exception to that. The server (nslcd) will only
> > > > return shadow information if it can determine that the caller runs as
> > > > root.
> > > >
> > > > So I would like to keep one socket for all requests and not mess with
> > > > permissions of sockets.
> > >
> > > Sounds broken.  Good luck.
> >
> > That wasn't very helpful.  If you are dead set on using IBAC, you
> > could use the auth protocol to establish the identify of the client.
> > The interface is described in auth/auth.defs .
>
> Well, I guess he doesn't have a running Hurd system.
>
> Actually I guess we could easily add SO_PASSCRED to pflocal sockets, by
> using auth_user_authenticate/auth_server_authenticate indeed.

(I mean SO_PASSCRED and then use SCM_CREDENTIALS to pass credentials
through the socket)

Samuel


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Neal H. Walfield]

At Wed, 18 Jun 2008 12:56:53 +0100,
Samuel Thibault wrote:
> Well, I guess he doesn't have a running Hurd system.
>
> Actually I guess we could easily add SO_PASSCRED to pflocal sockets, by
> using auth_user_authenticate/auth_server_authenticate indeed.

The problem is which credentials: remember a Hurd process has have
many UIDs and GUIDs.  This decision is context dependent.

Neal


--
To UNSUBSCRIBE, email to debian-hurd-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...