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

Re: chrooted accounts

> 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:

	jailbird:x:1234:98:John JailBird:/special/jail:*

		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:

jailbird:x:1234:98:John JailBird:/special/jail:/usr/local/bin/jaillogin

	Where jaillogin was a program that did (in psuedo-code):

		cd ~jailbird
		chroot . 
		exec /bin/login

	(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
	right there).

> Cristian
> --
> UNIX is user friendly. It's just selective about
> who its friends are.

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