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

Re: alternate password file module?

At around Sat, 31 Jul 1999 18:55:13 -0500 (CDT),
 Stephen Langasek <vorlon@netexpress.net> may have mentioned:

> On Wed, 28 Jul 1999, Jesse Off wrote:
> > Is there any PAM module available that can take a different password for a
> > user rather than the ones in /etc/passwd or /etc/shadow?  Specifically, I
> > would like to be able to have imap or pop3 servers use a separate password
> > than the one that is in the /etc/passwd database.
> I've heard talk about such a module in the past, but to my knowledge no one
> has written one yet.


> If, on the other hand, you're authenticating the user in a context where
> they don't need a unique uid for accessing system resources (which is often
> the case with services such as squid, radius, and pop), then the passwd file
> format is overkill, because the only fields you would need are username,
> password, and possibly account expiry information.

imho, whether a passwd file is used is not so much an issue -- what
would be nice is not having to create unix user accounts (for users)
at all -- creating a single user and a single group [1] for the
purposes of running code for a particular service is fine.  which
leads to what you said:

> Once the dependency on a password-file format is eliminated, there are many
> other modules which can handle authentication, and many of them are more
> efficient than a flatfile (especially if you have a lot of users).

which i agree w/ -- further, it would be nicer if one had the option
of not having to create a unix user account when a user is added.
(the word 'user' is too overloaded...)

> A simpler solution, IMHO, would be to put these users in your
> password/shadow files with an invalid shell (and homedir if you like), and
> use PAM to limit access to other services by group.  If properly configured,
> the difference in security is minimal--anyone who could bypass this could
> just as easily add a new user to the system.

i see a few issues w/ this approach:

   -if i want to support multiple domains on one machine, it does not
   seem possible to have both a 'joe@example.com' and a 'joe@example.org'
   on the same machine (where quite likely, the 'accounts' are used by
   different people or for different purposes).  it isn't
   possible, right?  

   on a box i am using, the command 'adduser joe@example.org' gives:

     adduser: Please enter a username consisting of a lower case letter
     followed by lower case letters and numbers.  Use the `--force-badname'
     option to allow underscores, dashes, and uppercase.

   it isn't clear to me that using --force-badname won't have some nasty
   consequences somewhere else -- does anyone have any experience trying
   this out?

  -it may be possible to create files and execute code under real user
   accounts even if they don't have shells -- for example, through
   buffer overflows.  so, even if a particular service doesn't have
   buffer overflows, i need to be concerned about other services which

   of course, if there is a buffer overflow in a particular service,
   i need to be concerned about the damage that can be done, but at least
   if the code for the service is written appropriately [2], it seems like
   the damage can be limited to just that service.  it seems simpler 
   (from a maintenance and administrative pov, perhaps not from a 
   development pov) and better-contained this way.  (in a scenario in
   which a buffer overflow is discovered, at first glance, it seems easier 
   to recover from.)

  -it would be nice to be able to share 'virtual accounts' among
   different services -- if someone has a virtual pop account (e.g. like
   those available in vchkpw) identified by 'joe@example.org', it would be 
   nice if i could refer to this in other contexts -- for example for ftp.

if it were possible to specify that for particular user accounts, code
cannot be executed and files cannot be created in a system-wide manner
[3], i would almost be happy [4] w/ adding users to
/etc/(passwd|shadow).  is this possible?  i'm not aware of any way to
do this.

any comments?

[1] well, not necessarily one account and one group -- multiple is
    fine as long as the number stays fixed.

[2] for starters if the service needed to be setuid root (e.g. for
    binding to some low number port), releasing those priveleges asap,
    chrooting/jailing appropriately, etc.

[3] ... and possibly restrict some other things in addition to executing 
    code and creating file.

[4] the 'adding users to /etc/passwd' approach still appears to suffer 
    from the 'joe@example.org' and 'joe@example.com' problem.

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