Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

On Fri Mar 12 15:17:28 JST 2004, lucio@proxima.alt.za wrote:
> If you're trying to lock out certain users from a standalone CPU
> server, you must make sure that they have no presence in /adm/users.

If users don't have their uid listed in /adm/users,
standalone cpu servers still permit them to log in.
The users' file accesses are treated as `none' in that
situation.

How shall I lock out certain users on cpu server, I wonder?
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[lucio]

> How shall I lock out certain users on cpu server, I wonder?

Presumably, you have authenticated users, but you don't want them to
access one or more standalone CPU servers.  Then I think you'll need
to list them in /adm/users and make sure their namespace locks them
out.

In my opinion, being aware of the users' identity is preferable to
relying on defaults, as long as the authentication and users lists are
managed together.  There may be a different approach, but I'd be happy
with the above.

++L

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

> > The cheese is a blue one?
> c'est une ENIGME

Since it *SOUNDS* like french, Roguefort might be it.
# Goolgle had told me what the joke is, I think ;)
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

> > > Only the cheese stands alone.
> not being japanese won't help you understand the joke.

really!?...  excuse me to start ask questions to understand the joke.
The cheese is a blue one?
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[boyd, rounin]

> really!?...  excuse me to start ask questions to understand the joke.
> The cheese is a blue one?

c'est une ENIGME

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[Bruce Ellis]

someone must have a "cheese stands alone" poster,
or a picture at least.  dennis might like to comment.

brucee
----- Original Message ----- 
From: "YAMANASHI Takeshi" <uncover@beat.cc.titech.ac.jp>
To: <9fans@cse.psu.edu>
Sent: Sunday, March 14, 2004 2:55 PM
Subject: Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.


> > > > Only the cheese stands alone.
> > not being japanese won't help you understand the joke.
> 
> really!?...  excuse me to start ask questions to understand the joke.
> The cheese is a blue one?

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

> Keeping people out of a machine is another problem altogether.
: 
> Perhaps we could do something similar on a per service basis,
> i.e., a servicesdb that each service (or listen itself) can
> consult to determine yay or nay for the service.  For example,
> you could make /lib/ndb/common:
> 
> tcp=cpu port=17013 uid=!presotto uid=*

I thought of similar control, but based on the idea of tcpwrappers, like:

/lib/ndb/local:
ipnet=xxx.xx.xx.xx ipmask=xxx.xxx.xxx.xxx
	permit=tcp10
	permit=tcp20
	deny=all

using ndb/ipquery to determine if a connection is allowed or not.
ndb is so powerful, isn't it?


P.S
	Thank you for all who helped me to understand the speaksfor
	relationship.
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[boyd, rounin]

> I thought of similar control, but based on the idea of tcpwrappers, like:

tcpwrappers was written to 'fix' the non-existant IP security.

if you don't want to listen on the port, don't listen on the port.

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

> Only the cheese stands alone.

Nihonjin dakara, kono joke ga wakaranai.... :)
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[boyd, rounin]

> > Only the cheese stands alone.
> 
> Nihonjin dakara, kono joke ga wakaranai.... :)

not being japanese won't help you understand the joke.

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

On Fri Mar 12 14:57:38 JST 2004, lucio@proxima.alt.za wrote:
> Not that I can see.  To be able to execute a process on a CPU server,
> you need to be authenticated on the file server that holds the
> executable.

But what if the CPU server stands alone?
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[lucio]

> But what if the CPU server stands alone?

At the risk of sounding facetious, it is not a CPU server, then, is
it?

If you're trying to lock out certain users from a standalone CPU
server, you must make sure that they have no presence in /adm/users.
I don't believe they will be able to access the CPU services in that
situation.

++L

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[boyd, rounin]

> But what if the CPU server stands alone?

Only the cheese stands alone.

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[YAMANASHI Takeshi]

On Fri Mar 12 14:32:41 JST 2004, lucio@proxima.alt.za wrote:
> Well, /lib/ndb/auth indicates the speaksfor relationship.  Surely uid
> X can be assumed to speakfor uid X?

Then, every users in a domain can start their processes on
arbitary cpu servers whose host owners aren't allowed to speak
for the user?  Is this the way that the speaksfor relationship
works?

I thought the relationship can be used to restrict which users
are allowed to run their process on cpu servers.  I am still
confused with the relationship... :)
-- 

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[lucio]

> On Fri Mar 12 14:32:41 JST 2004, lucio@proxima.alt.za wrote:
>> Well, /lib/ndb/auth indicates the speaksfor relationship.  Surely uid
>> X can be assumed to speakfor uid X?
> 
> Then, every users in a domain can start their processes on
> arbitary cpu servers whose host owners aren't allowed to speak
> for the user?  Is this the way that the speaksfor relationship
> works?
> 
Not that I can see.  To be able to execute a process on a CPU server,
you need to be authenticated on the file server that holds the
executable.  If the CPU server can't speakfor you, then you are
blocked from using it.

> I thought the relationship can be used to restrict which users
> are allowed to run their process on cpu servers.  I am still
> confused with the relationship... :)

I found it hard to grasp too, the mailing list archives will bear
witness of that :-) But I suspect it is simpler than one expects,
which is what confuses one.  I have no doubt whatsoever that the
speakfor relationship is quite sufficient as a security measure.

++L

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

You got it.

The speaksfor relationship is used to allow a user that has
cpu'ld (or ssh'd or telnet'd...) into a cpu server to access
resources off of that cpu server.  Assume you've telnet'd in
but the file server is on another machine.  In order to have
any files at all to continue, your process (via the factotum
on the cpu server) must authenticate to the file server.
However the only keys in that factotum are those of the cpu
server's owner.  Therefore, that owner must be able to
'speak for' you to the file server.  It does that by getting
a ticket from the auth server, encrypted in the file server
owner's key, that identifies the caller as you.

Keeping people out of a machine is another problem altogether.
In our world, having a key in a host's domain is equivalent to
having access to the host.  The way we lock people out of a
host is to not give them a key into its domain.  We run a
number of authentication domains at the Labs for that reason.

This was a lack of forsight on my part.  Putting a system in
a separate auth domain can be a pain for all the users involved.
Some flavor of ACL would be nicer; i.e. the ability to say, user
Alice can only do the following things on host X.  We already
have something like that in the form of /lib/ndb/consoledb.
Perhaps we could do something similar on a per service basis,
i.e., a servicesdb that each service (or listen itself) can
consult to determine yay or nay for the service.  For example,
you could make /lib/ndb/common:

tcp=cpu port=17013 uid=!presotto uid=*

That way, stand alone servers could control who cold use
its services.

I'm not sold yet on the form it should take, but I think it is
necessary.

[-- Attachment #2: Type: message/rfc822, Size: 2727 bytes --]

From: YAMANASHI Takeshi <uncover@beat.cc.titech.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.
Date: Fri, 12 Mar 2004 14:47:14 +0900
Message-ID: <ab51c3099cbdee26e297242e5c2193f6@orthanc.cc.titech.ac.jp>

On Fri Mar 12 14:32:41 JST 2004, lucio@proxima.alt.za wrote:
> Well, /lib/ndb/auth indicates the speaksfor relationship.  Surely uid
> X can be assumed to speakfor uid X?

Then, every users in a domain can start their processes on
arbitary cpu servers whose host owners aren't allowed to speak
for the user?  Is this the way that the speaksfor relationship
works?

I thought the relationship can be used to restrict which users
are allowed to run their process on cpu servers.  I am still
confused with the relationship... :)
-- 

[9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[9nut]

In an earlier post titled "rm /lib/ndb/auth?", YAMANASHI Takeshi
reported a behavior that looks inconsistent: basically, in authsrv.c,
it appears that if the hostid and the uid in the ticket request are the
same, /lib/ndb/auth is not consulted.

Is this right? Is it working as designed?

Re: [9fans] If hostid==uid, then /lib/ndb/auth is not checked.

[lucio]

> In an earlier post titled "rm /lib/ndb/auth?", YAMANASHI Takeshi
> reported a behavior that looks inconsistent: basically, in authsrv.c,
> it appears that if the hostid and the uid in the ticket request are the
> same, /lib/ndb/auth is not consulted.
> 
> Is this right? Is it working as designed?

Well, /lib/ndb/auth indicates the speaksfor relationship.  Surely uid
X can be assumed to speakfor uid X?

++L