Subject: Homedir matching in Upload line

From: Charles Bruneteau <[email-masked]>
Date: Thu, 29 Jul 1999 10:33:50 +0200

hi,

i've set up a chroot'ed environment in /opt/ftp. 
in.ftpd is launched with the argument "-r/opt/ftp". Every user is
declared in /opt/ftp/etc/passwd & /opt/ftp/etc/shadow. We have two type
of users: let's say minor and major. A minor user "belongs" to a major
one. The home directory of a major user will be /majoruser1, and a minor
user will have /majoruser1/minoruser1. Thus we will have this type of
tree :

/majoruser1/minoruser1
/majoruser1/minoruser20
...
/majoruser3/minoruser4
/majoruser3/minoruser6

every user is considered as a real user and is restricted to his
homedirectory (restricted-gid clause).

then comes my problem : i want to distinguish minor and major user
upload rights. so i add these two lines: 

upload relative /*/* /*/* yes * majorgroup 0600 nodirs
upload relative /* /*/* yes * minorgroup 0640 nodirs

when i log in as minoruser1 and i upload a file, the second upload line
is taken and rights will be 640 although the homedir is
/majoruser1/minoruser1. 

I think the best match for this homedirectory should be /*/* ? 

my purpose is that i don't want to allow minoruser1 to read a file he
has uploaded (minor users are considered insecure...).

i tried with 2.5.0 and 2.4.2vr17.

regards 

Charles Bruneteau

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 29 Jul 1999 10:38:00 -0400

> has uploaded (minor users are considered insecure...).

Some comments:

 - Your users are all 'real' in the sense they exist in the Unix
   environment.  For WU-FTPD, you should make them all 'guest'; they're
   still Unix-real, but cannot leave their restricted area.

   All users shoul be considered insecure.  The question is their level of
   hostility.  From what you're saying, you consider minor users
   potentially more hostile than major users.

 - The restricted-uid/restricted-gid clause should not be considered secure
   unless used within a chroot'd environment.  There simply is not enough
   history for this feature to know if there may be problems with it.

 - The "relative" phrase could be getting in the way.

 - If you're using wildcards in the pathname parameters you need to be VERY
   VERY carefull.  They will match a lot more than you probably intended.

Here's how I'd set this up:

drwxr-xr-x root     root     /home/users
d--x--x--x root     root     /home/users/bin
d--x--x--x root     root     /home/users/dev
d--x--x--x root     root     /home/users/etc
drwxrwx--t maj1     maj1     /home/users/maj1
drwxr-xr-x root     root     /home/users/maj1/users
drwxrwx--- maj1min1 maj1     /home/users/maj1/users/maj1min1
drwxrwx--- maj1min2 maj1     /home/users/maj1/users/maj1min2
drwxrwx--- maj1min3 maj1     /home/users/maj1/users/maj1min3
drwxrwx--t maj2     maj2     /home/users/maj2
drwxr-xr-x root     root     /home/users/maj2/users
drwxrwx--- maj2min1 maj2     /home/users/maj2/users/maj2min1
drwxrwx--- maj2min2 maj2     /home/users/maj2/users/maj2min2
drwxrwx--- maj2min3 maj2     /home/users/maj2/users/maj2min3
drwxrwx--t maj3     maj3     /home/users/maj3
drwxr-xr-x root     root     /home/users/maj3/users
drwxrwx--- maj3min1 maj3     /home/users/maj3/users/maj3min1
drwxrwx--- maj3min2 maj3     /home/users/maj3/users/maj3min2
drwxrwx--- maj3min3 maj3     /home/users/maj3/users/maj3min3

### /etc/passwd
maj1:XXXXX:10000:10000::/home/users/maj1:bin/sh
maj1min1:X:10001:10001::/home/users/maj1/users/min1:/bin/sh
maj1min2:X:10002:10002::/home/users/maj1/users/min2:/bin/sh
maj1min3:X:10003:10003::/home/users/maj1/users/min3:/bin/sh
maj2:XXXXX:20000:20000::/home/users/maj2:bin/sh
maj2min1:X:20001:20001::/home/users/maj2/users/min1:/bin/sh
maj2min2:X:20002:20002::/home/users/maj2/users/min2:/bin/sh
maj2min3:X:20003:20003::/home/users/maj2/users/min3:/bin/sh
maj3:XXXXX:30000:30000::/home/users/maj3:bin/sh
maj3min1:X:30001:30001::/home/users/maj3/users/min1:/bin/sh
maj3min2:X:30002:30002::/home/users/maj3/users/min2:/bin/sh
maj3min3:X:30003:30003::/home/users/maj3/users/min3:/bin/sh

### /etc/group
maj1::10000:maj1
maj1min1::10001:maj1,maj1min1
maj1min2::10002:maj1,maj1min2
maj1min3::10003:maj1,maj1min3
maj2::20000:maj2
maj2min1::20001:maj2,maj2min1
maj2min2::20002:maj2,maj2min2
maj2min3::20003:maj2,maj3min3
maj3::30000:maj3
maj3min1::30003:maj3,maj1min3
maj3min2::30002:maj3,maj3min2
maj3min3::30003:maj3,maj3min3

### /home/users/etc/passwd
maj1::10000:10000::/maj1:
maj1min1::10001:10001::/maj1/users/min1:
maj1min2::10002:10002::/maj1/users/min2:
maj1min3::10003:10003::/maj1/users/min3:
maj2::20000:20000::/maj2:
maj2min1::20001:20001::/maj2/users/min1:
maj2min2::20002:20002::/maj2/users/min2:
maj2min3::20003:20003::/maj2/users/min3:
maj3::30000:30000::/maj3:
maj3min1::30001:30001::/maj3/users/min1:
maj3min2::30002:30002::/maj3/users/min2:
maj3min3::30003:30003::/maj3/users/min3:

### /home/users/etc/group
maj1::10000:
maj1min1::10001:
maj1min2::10002:
maj1min3::10003:
maj2::20000:
maj2min1::20001:
maj2min2::20002:
maj2min3::20003:
maj3::30000:
maj3min1::30001:
maj3min2::30002:
maj3min3::30003:

### etc/ftpaccess

class user guest *
guestuser *
restricted-uid *
guest-root /home/users

noretrieve core
# Everyone is restricted-uid and cannot get here, but just to be sure...
noretrieve /home/users/bin/
noretrieve /home/users/dev/
noretrieve /home/users/etc/
upload /home/users/*         /        no
upload /home/users/*         /bin     no
upload /home/users/*         /dev     no
upload /home/users/*         /etc     no
upload /home/users/*/users/* /        no
upload /home/users/*/users/* /bin     no
upload /home/users/*/users/* /dev     no
upload /home/users/*/users/* /etc     no
upload /home/users/*/users/* /*/users no

# Major users
upload /home/users/* *          yes nodirs
upload /home/users/* /*/users   no
upload /home/users/* /*/users/* yes * * 0460 nodirs

# Minor users
upload /home/users/*/users/* *          no
upload /home/users/*/users/* /*/users/* yes * * 0260 nodirs

-- 

Gregory A Lundberg              WU-FTPD Development Group
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Charles Bruneteau <[email-masked]>
Date: Thu, 29 Jul 1999 17:14:28 +0200

>    still Unix-real, but cannot leave their restricted area.

but with the '-r' option  there is already a chroot; that's why i choose
a 'real' class. As guests there would be 2 chroot.

>    potentially more hostile than major users.

that's it; in fact major users are identified (company employee).

>    history for this feature to know if there may be problems with it.

as i said we have a chroot'd environment ( -r option); nevertheless i do
not want users to go outside their home directories (and subdirectories
for major users)

>  - The "relative" phrase could be getting in the way.

i tried without this one ; no difference.

>    VERY carefull.  They will match a lot more than you probably intended.

actually i was wondering wether i would modify extensions.c : add 
FNM_PATHNAME option to fnmatch ; thus '*' would stop matching  any
'/'...

> upload /home/users/*/users/* /*/users/* yes * * 0260 nodirs

Thanks for this example and you answer.

i dind't tried yet, but there seems to be the same problem than i have
with these lines : 
 # Major users
 upload /home/users/* *          yes nodirs

 # Minor users

why a minor user wouldn't match the first line ?

IMO chrooting with the '-r' option is very interesting : passwd & shadow
will be in the chroot'd environment. Only ftpaccess will be in /etc.

---

From: Charles Bruneteau <[email-masked]>
Date: Thu, 29 Jul 1999 18:51:56 +0200

Gregory A Lundberg wrote:
> 
> On Thu, Jul 29, 1999 at 05:14:28PM +0200, Charles Bruneteau wrote:
> 
> I missed that.  I put it in, but I don't use it.  If I'm going to that much
> work, I do it in a shell script before starting the daemon.
> 
> Blech!  Um, yeah.  And you probably want to set FNM_LEADING_DIR as well.
> And, of course, none of it will work because the fnmatch() provided with
> 2.5.0 is buggy and the fnmatch() on most systems is either not POSIX 2 or
> is POSIX 2 but didn't correct the design oversight.
> 
> You probably want to get with me personally to get a CVS snapshot of the
> under-development code ...
> 

oh, i was not meaning i'm a great code writer ! I'm just able to hack
part of functions... i even hadn't notice that wuftpd was using its own
version of fnmatch !! 
Back in May, i added another "path_compare" function in extensions.c
(2.4.2vr17), this time with the FNM_PATHNAME flag. If i remember well it
seemed to work. However i had to stopped my tests there because of
higher priorities... 

i 'm going to detail what i was hoping to achieve, in case you have
ideas about it :

- overall purpose : exchange of files between employees and external
people (on the internet for example)

- any external guy depends on an employee (the accounts are created when
an employee asks for it). Accounts are temporary (ttl is given by the
employee). 

- no exchange between 2 employees, or between 2 external guy, that is
only in->out or out->in (with relation to the company). Furthermore
external people (who i was calling minor users) shouldn't be allowed to
read what they upload. 

- authentication with user/password, and if possible one time password
for permanent users. (i was the one who asked you about PAM on solaris,
if you remember...)

- no anonymous connection

- employees should be able to connect from outside the company, but may
not be allowed to upload file. This point is not fixed yet.

- etc/ftpaccess should not be modified when adding any user. And of
course a chroot'd environment.

That's it !

Regard 

Charles Bruneteau

PS : during my tests i had another problem : using restricting-gid
clause for minor users, and a tree such as :
	/majoruser1/minoruser1/incoming
	/majoruser1/minoruser1/outgoing
minoruser1 was able to cd to incoming (or outgoing), but ls in this
directory reported an error :
	550 Permission denied on server.  You are restricted to your account
what am i mssing ?

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 29 Jul 1999 14:09:19 -0400

> > Blech!  Um, yeah.  And you probably want to set FNM_LEADING_DIR as
> > well.  And, of course, none of it will work because the fnmatch()
> > provided with 2.5.0 is buggy and the fnmatch() on most systems is
> > either not POSIX 2 or is POSIX 2 but didn't correct the design
> > oversight.
> > 
> > You probably want to get with me personally to get a CVS snapshot of
> > the under-development code ...
> 
> version of fnmatch !!   Back in May, i added another "path_compare"
> function in extensions.c (2.4.2vr17), this time with the FNM_PATHNAME
> flag. If i remember well it seemed to work. However i had to stopped my
> tests there because of higher priorities... 

What I meant was .. "Yes, you probably should add that flag.  And you'll
probably want the corrected function since your OS-provided one is probably
broken like the BSD version which came with the daemon."  So, I offer the
CVS snapshot so you can use the corrected/debugged fnmatch() function.

> i 'm going to detail what i was hoping to achieve, in case you have ideas
> about it :
> 

I've just had someone else ask me to look at his web-based management
system for this.  was cool, but I don't think it's somehting the daemon
should include .. if he doesn't pipe up, I'll send you his email address
privately.

> external people (who i was calling minor users) shouldn't be allowed to

restricted-uid will keep employees apart.  it'll probably also solve your
problems everywhere.  take a look at my example i sent earlier, it should
do what you want in this respect.

> for permanent users. (i was the one who asked you about PAM on solaris,

which should all be working for you.  might need to do a little hacking to
get PAM going on soalris .. I onlt could do it for Linux.  Or, use OPIE.

> - no anonymous connection

config it, test it, disable it with 'defaultserer private' then when
management changes their mind, remove the one line and you're a god.

> not be allowed to upload file. This point is not fixed yet.

use classes and class= on uploads

> course a chroot'd environment.

chroot, it won't be there at all

> PS : during my tests i had another problem : using restricting-gid clause
> for minor users, and a tree such as :

Probably a mismatch between the chroot-local etc/passwd and the fiesystem
visible to the daemon after the chroot() occurs.  The homes in the local
etc/passwd are what are important for this feature.

The user shouldn't have been able to cd to begin with, so I'd guess you
should start using guest-root instead of the /./ hack so the local
etc/passwd is also used for the initial cwd setting upon guest login.

--

---

From: Charles Bruneteau <[email-masked]>
Date: Fri, 30 Jul 1999 10:15:32 +0200

> CVS snapshot so you can use the corrected/debugged fnmatch() function.

Great! So please send me it to my email (there is a 2Mb limit, but i
guess that it will not be that big).

> should include .. if he doesn't pipe up, I'll send you his email address

that's funny; i wrote one too... and i'm still updating it : i forgot
about apache mod_perl when i wrote the first version, so it's a cgi. 

> do what you want in this respect.

But what did you mean with :
   " - The restricted-uid/restricted-gid clause should not be considered
secure
   unless used within a chroot'd environment.  There simply is not
enough
   history for this feature to know if there may be problems with it."

can i be certain that a minor user won't be allowed to browse any other
account, and that a major user won't be able to browse any other major
homedir.

> get PAM going on soalris .. I onlt could do it for Linux.  Or, use OPIE.

it was working with 2.4.2vr17, but not with the chroot'd environment. I
hadn't time to analyse this a lot.
i will try again.

> management changes their mind, remove the one line and you're a god.

do you mean : set the ftp account in passwd, allow anonymous in a class,
etc. then just add 'default server private' ?

> etc/passwd are what are important for this feature.

here are 2 lines of my chroot-local etc/passwd :
----
minor1:x:15001:502:ftp out:/major1/minor1:/bin/false
major1:x:5001:501:ftp in:/major1:/bin/false
----

> etc/passwd is also used for the initial cwd setting upon guest login.

has you see above i'm not using '/./' in the homedir (users are 'real'). 
I'm surprised that restricted user should not be allowed to go in
subdirectories of their homedirectory. Did i understand well what you
said ?
That would be a problem for me because i want major user to cd to their
minor users' homedir... (exchanges occurs in the minor user 's homedir).

---

From: Charles Bruneteau <[email-masked]>
Date: Fri, 30 Jul 1999 10:22:38 +0200

> minor users' homedir... (exchanges occurs in the minor user 's homedir).

i've found my problem : /major1 was not readable by minor1 ! i hope
restricted-uid/gid will do its job !

regards

charles bruneteau

---

From: Gregory A Lundberg <[email-masked]>
Date: Fri, 30 Jul 1999 09:18:25 -0400

On Fri, Jul 30, 1999 at 10:15:32AM +0200, Charles Bruneteau wrote:

>    secure unless used within a chroot'd environment.  There simply is not
>    enough history for this feature to know if there may be problems with
>    it."
> 

We don't _think_ a user would be able to browse to other's directories.
But the feature is so new, nobody's seriously attacked it yet.

> hadn't time to analyse this a lot.  i will try again.

You need to be sure to grab all the PAM parts, some of which are
non-obvious.  Took me about three days to figure them all out for Linux,
and that was by trial-and-error.

> etc. then just add 'default server private' ?

yep.  well, 'defaultserver' is one word here.  the idea is to ensure
anonymous ftp is safely done now, while you're thinking about it, then just
disable it until management changes their mind (sic).

> minor users' homedir... (exchanges occurs in the minor user 's homedir).

You using symlinks?

Restricted-uid will allow access down the tree inside you home, but it
won't let you jump out, even with a symlink.

--