PAM Service Name Patch

[Christer Bernérus]

Andrew Bartlett wrote:

> Christer Bernerus wrote:
> >
> > What I, as a sysadmin would like to see is the possibility of not only
> > having different service names for different programs, but also have them
> > different depending on authentication method.
> >
> > One reason for this is that I would like to control who logs on to which
> > machine, and *how*. Using passwords and using e.g. kerberos or AFS ticket
> > transfers have results in different security exposures in the light of
> > trojan horses, or user population on the machines.
> >
> > Consider the situation of university teachers logging in to student machines.
> > In that case, we wouldn't like them to give their passwords, regardless of
> > whether the passwords are encrypted in transfer or not. However doing Kerb5
> > ticket transfers probably is a different story since these tickets have
> > time limits on their validity, something that passwords generally don't have,
> > or at least have much longer validity.
> >
> > If there were an OTP password authentication method, there would be yet another
> > method that would represent a different security risk, and could call for
> > another policy vs who may log on. PAM is a good framework that not only can
> > be used for selecting authentication policies, but also can be used for
> > controlling authorization policy, regardless of the method of authentication.
> >
> > One way of enabling that kind of authz policy-making is to have different
> > PAM service names for different authn-methods.
> >
> > Please forgive me if this have been discussed before. I'm new to this list.
> > In that case, I'd be interested looking at som archived mail if available.
> >
> > Chris.
> >
> > <bernerus at cs.chalmers.se>
>
> I may be misunderstanding your situation - but this looks like a client
> rather than a server issue:  Do you administer your student machines?

Well, yes. However I don't administer all of the ssh clients that my students or
teachers/researchers use, as these use their laptops, home PC's, or log in from
other universities while being somwhere else in the world. This leaves me with
administering the servers.

>
> The ssh client can be quite easily configured as to what degree it will

Well, the problem is that I cannot do that. See above.

>
> trust various servers - but if you don't trust the server its not really
> worth hoping it will keep a sign up "I'm not to be trusted" after its
> been rooted/reconfigured.

No, I'm sure it won't do that. That's why I want to distrust the student's
machines all the time, and force the teachers not to use password based
authentication when entering the student machines. I can of course create
separate accounts for them, but that creates a lot of administration and also
lots of potentially unused accounts lying around.

>
> Certainly having a more flexible pam framework might be useful - i.e.
> with OTP actually in PAM or with a different PAM configuration depending
> on the client's name.  For the vast majority of users the existing setup
> actually works surprisingly well.

Yes, sure. It has worked for us for several years, but the hacker/sysadmin war
forces us to reconsider things that has beeen taken for granted for years. The
future might call for new methods.

>
> Just make sure your doing it for the right reasons,

Well, there are reasons, as you see, but it doesn't hurt having other people
scrutinizing the lines of thinking, so I'm grateful for any opinions.

I'm not at all sure that this is *the* way to go,
but the change is a fairly simple one, and with a nice implementation there
wouldn't be a need for everyone to adapt their installations.


Cheers!

----

Chris.