[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: chrooted accounts
- From: Jim Dennis <jimd starshine org>
- To: pam-list redhat com
- Subject: Re: chrooted accounts
- Date: Thu, 11 Sep 1997 16:55:58 -0700
> On Thu, 11 Sep 1997, A Bruce in the Land of the Bruces wrote:
>> *chuckle* Doesn't work under Linux, Digital Unix or FreeBSD. Been there,
>> done that etc...
>> You'd think a copy of the device file would work, which it does for
>> most applications, but certain things do want the real device file.
This is not true. At the kernel level Unix has not need
for device nodes to exist in the /dev directory -- that just
happens to be where all of the utilities and applications
expect to find them. To nodes (directory entries) which
refer to the same major/minor device are indistinguishable
from one another so far as the kernel is concerned.
> I'd bet you were having a /proc problem
I, too, would lay money on that.
When I configure CLUE systems (chrooted login user environments)
I find that I hae to mount /proc twice -- once in the "attic"
(true root) and again in the "jail." This is needed for
most sorts of shell access to the CLUE -- but is not needed
for the jails you create for smtpd/smapd, httpd, syslog, or
any of the wu-ftpd chroot trees. They don't need access to
'ps' and similar commands.
The orginal question, regarding the :home/./jailtop: convention
in the home directory field of the /etc/passwd file applies
to wu-ftpd "guestgroups." I don't know of any other
authentication system and session/protocol service that
honors it. (Of course, I don't know all that much -- so I'd
love to hear about others).
There is a different SysV login convention for user-specific
chroot -- where the *shell* field is specified as "*"
This is supposed to be standard (for SVR4 systems?) and is
documented in Garfinkel and Spafford's _Practical_Unix_and_
Internet_Security_ (O'Reilly & Associates, pp 232-234).
I've never used this -- but it appeared (when I tested in once
on a non-PAM system) that it did attempt to behave as described
(I just didn't bother with setting up the jail properly).
Here's how it's supposed to work:
You create the passwd entry like so:
When John JailBird logs in and correctly enters
his password the login program does a chroot() to
the /special/jail (in this example) and execs a
new login (which can authenticate him again).
Clearly it's handy if you set one or the other of these
passwords to null (and have null_password_O.K._ enabled) --
However there is nothing to prevent you from requiring two
different passwords. A substantially similar behavior might
be emulated if you were to create an account like:
Where jaillogin was a program that did (in psuedo-code):
(naturally you wouldn't make this a shell script as I've
shown it -- that would be insecure).
One interesting note about this model is that you don't
need to run PAM at both levels. You could run a traditional
or custom login at one level and use PAM at the other.
Whatever you run in the chroot environment won't know or care
about how your process got there.
The PUIS is one of several books that describe this. I've
recently been doing research (occasionally) on chroot jails
(for my paper on CLUE -- hopefully to be submitted to USENIX
or SANS within a few months). I think I found about half
dozen references to this (the methodology for that part of the
literature search was very simple -- grab every book at the
library and store that had Unix and Security in the title,
look in the index for words like chroot, jail, restricted tree,
restricted directory, etc).
I discussed this briefly with Andrew via private e-mail and
I think he wrote a chroot PAM module. However, I don't think
it works as I've described. I think it would be nice if we
support this convention as described (however I'm not a
programmer -- so I can't help much with the coding). I'll
be happy to test any attempts that are made to it.
Although I personally haven't used this yet I'd like to
see us implement this as has been described in those books.
This method seems relatively straightforward and clean --
it is as good a way to denote special login shells as any
I've heard of -- and will ultimately cause less confusion
when people are reading books and trying to use this. I'll
grant that it's also a bit obscure and baroque. Most of
the SA's I know haven't read these books cover-to-cover
(I've only read a few of them that way, myself) and I
haven't had anyone actually use this technique. However
it seems like a great way to implement a BBS or interative
Kiosk account (like the "telnet to lynx" gateway for users
who don't have a good copy of lynx at their site).
* (CLUE works by doing a single chroot in the rc scripts
and running inetd inside the jail. Any getty processes that
you wanted in that jail are accomplished with a slightly
hacked getty -- so each of those terminals is listed with
"jailgetty" in the inittab while any "secure, administrative"
terminal get the old, normal getty. The principal advantage
is that the "attic" and plenty of administrative functions
can be run of of read-only hardware -- like a hard disk with
the write-disable pins shorted. I have modified some external
hard disks by adding a keyed switch to provide the ROD --
read-only device for this. That's really most of the paper
> UNIX is user friendly. It's just selective about
> who its friends are.
[Date Prev][Date Next] [Thread Prev][Thread Next]