Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] chroot over ssh with pam_chroot

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: "Mathieu L." <lejatorn AT smgl.homelinux.net>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] chroot over ssh with pam_chroot
  • Date: Sun, 19 Dec 2004 23:34:33 -0800

On Mon, Dec 20, 2004 at 02:04:46AM +0100, Mathieu L. wrote:
> On Sun, Dec 19, 2004 at 04:33:34PM -0800, Seth Alan Woolley wrote:
> > Correct me if I'm wrong, but users in a chroot won't be able to change
> > their own password easily. One would need a special setuid program that
> > not only switches to root to edit /etc/passwd, but they would have to
> > break out of the chroot before editing /etc/passwd, unless, of course,
> > you're using some other finer-grained permission system such as that
> > proposed by hans reiser where areas within a file can have their own
> > permissions (and a hardlink could be created to a location inside the
> > chroot). I believe dossen's other email should, however, get you hooked
> > upon the username issue, though.
> >
> > I suppose you could copy the line from their chroot environment to the
> > main passwd file with a cron script that checks for chroot passwd
> > changed. However, I'm not sure exactly how you have things setup.
> >
> > Seth
> >
> > P.S. Personally, I would never allow a user the ability to change and
> > create their own passwords without some password-hardness checks. I
> > prefer issuing passwords that are changed annually. The old
> > administrator where I work had passwords changed every month with a
> > two-week warning of "password is about to expire". People just got into
> > the habit of cycling numbers on the end of a very common word like the
> > name of their pet or son/daughter. I had to put a stop to that.
> >
> > Most breakins I've seen are due to 1) unpatched software, 2)
> > misconfigured software, and 3) social engineering passwords, and 4)
> > guessing passwords. You'd be amazed how well guessing a password works,
> > but more importantly telling people you will never ask for their
> > password, ever.
>
>
> Thanks for the reply.
> This mailserver is only intended to host a few of my friends accounts
> but I didn't want them to be able to wander all around the tree and I
> thought the least they should have is a way to change their pass, as one
> can do on a webmail.
> As I don't want this to become too much of a hassle would you advise me
> just to chroot them in their home with minimal power and to change
> myself the pass and send it through gpged emails (to an alternate address
> of course) when they require so?

I was going to suggest your latest idea but I didn't because I wasn't
going to assume the intelligence of the user enough to use gpg.
However, if they use gpg, then that's the best easy way I can see.

You can also use dsa public keys directly to log them into ssh. That
way their password is really the passphrase on their private key and
changing their password is a lot simpler.

I prefer public key authentication because then the user doesn't have to
create ten different passwords for ten different providers, and thus the
quality of their passphrase can be exceptionally high. Moreover, a
break-in on one service doesn't render another service broken if used
properly.

Seth

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id EF10E21A = 36AD 8A92 8499 8439 E6A8 3724 D437 AF5D EF10 E21A
http://smgl.positivism.org:11371/pks/lookup?op=get&search=0xEF10E21A
Security Team Leader Source Mage GNU/Linux http://www.sourcemage.org

Attachment: pgpFR9mYfT3v2.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page