[linux-elitists] pop/ftp and shell

Heather star@betelgeuse.starshine.org
Wed Mar 29 18:08:53 PST 2000


> On Wed, 29 Mar 2000, Heather wrote:
> 
> > Yes, someone who is in under control of the shell'd version has the right to
> > chfn for the other one... 
> 
> Right. But that's kind of the idea. I'm not suggesting that generic
> accounts with this property be created but rather that individual users
> have both accounts, if they need to perform both functions. 
 
But then, they could change their ftp account's shell from /bin/false to
anything legal.  They might even do it accidentally (thus the note on check 
how your instance of chfn behaves) - and that would be a nasty security hole.

> The idea is that you corner off the pop and ftp because they send a
> password in clear text. That way if the pop/ftp account is compromised
> the damage is somewhat limited (i.e. that account can't be used to
> install root kits and the lot).

Use scp, it's good for you. :) Um, but that's not real helpful to Joe Windoze.

Root Kits aren't always for GETTING root, they're more often for KEEPING it
or bragging rights.  
 
> Of course, making sure these users kept separate passwords is an
> issue. The ssh'able account should have full control over the ftp/pop
> side.

admin types should have admin type accounts, and get at least a minima of
requirements to follow good practices like ssh for file copies.
 
> This can alternatively be done with separate user IDs and the use of
> groups and sticky bits. But in my experience that always ends up turning
> into a mess for someone at some point.

Well, we certainly didn't use that method for stuff people -cared- about;
it was just a "toss that over the wall, willya" area.
 
> > You'll have to look at your passwd file family of apps to see if it will
> > control by name or just do the first one or what, but it strikes me as a 
> > big hole.
> 
> Well, since /etc/shadow is indexed by username and not userid it should be
> a non-issue for anything that is coded propely. Pop, ftp, ssh, and passwd
> all deal fine.
> 
> I'm curious as to why it strike you as a big hole? I felt the same way at
> first, but I think that's mostly because replicated user IDs has the
> historical stigma of being a method used by attackers to create a
> secondary root account.
 
	star$  passwd otherstar

	password:  (current password entered)
	new password: (twice of course)

	star$

Otherstar's password was changed.  It means that the "vulnerable" shell
account has direct power over the equivalent ftp account; so if their 
shell is broken or even shoulder-surfed, the badguy no longer has to 
WORK to bust the other one.  Not a little bit.  

It's the flip side of the same coin, always - make life easier for yourself
and regualr users, make it just as much easier for miscreants.

In our protected 3 levels deep corporate environment, we went for ease of
use.  We had other ways of keeping employees in line, and checking for 
damage attempts.  The UNIX box was a privilege, not a right, so if anyone
was just dumb they wouldn't be let back on til they got The Lecture.  Unless
their boss decided to pull the priv.  Then he could give The Lecture and we'd
merrily wipe the account into the "graveyard" area.

> On the other hand safeguarded secondary UID=0 accounts have been used for
> years by sysadmins as a precaution against junior admin types changing
> root passwords by accident.
> 
>> When I had to do the same at McAfee, it was easy to create a small scad
>> of dummy users (just use an alternate skeleton) but one of the skeleton
>> items was a symlink to a more truly shared directory.  SGID sticky of course.
>> It was possible to tell who tweaked a file, but not particularly to defend
>> against them being public.
> 
> I'm more worried about the compromise of plaintext passwords leading to
> the compromise of a shell account. If users who need this functionality
> get their e-mail and web page access compromised then it's their problem
> as there's no reason they couldn't run Linux (or use ssh tunneling under
> Windows).
 
Most exploits for ftp are not about what the password was - they're about
flooding the ability to ask for passwords.  In the normal case, it's the 
*app* that is insecure, not the account.

Having the password is the right to scrag one guy's files as well, which 
they might want.  And to use it as storage - so you might not be a DDOS 
site, or a spamhome, but you could be a pirate den.

And to have the files owned by the same UID is the right to drop in replacement
files to the .ssh directory.  And replace .bash_profile.  And all those 
things about controlling one's own environment, that a power user might do
on his own anyway.  (with an ssh authorized keys entry, they don't care 
about the silly password.)

There are ssh clients for windows, and there are "use the open pipe" style
downloads available too.  Windows people have options, they're just crufty.

What's wrong with just giving them two completely diskoint accounts?  Are 
uid's at a premium on your box?

> +++ath
> Derek Vadala, derek@cynicism.com, http://www.cynicism.com/~derek

* Heather * "The problems you need to avoid are the ones that not only
             give your users the -inclination- to get on a plane, but
             also the time."




More information about the linux-elitists mailing list