Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 Apr 1999 22:56:52 -0600
From:      Brett Glass <brett@lariat.org>
To:        Wes Peters <wes@softweyr.com>
Cc:        security@FreeBSD.ORG
Subject:   Re: Interesting problem: chowning files sent via FTP
Message-ID:  <4.2.0.32.19990409223443.0451c100@localhost>
In-Reply-To: <370EC49F.1A020B9D@softweyr.com>
References:  <4.2.0.32.19990409184654.045424d0@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
At 09:25 PM 4/9/99 -0600, Wes Peters wrote:

>An interesting problem you have there, Brett.  I can think of one quick
>solution: if the ftp server is dedicated to this task, you could make
>ftpd sgid to the "printer" group.

An interesting idea. However, other users who used FTP (including
administrators!) would wind up creating files that were owned
by the "printer" group instead of their own group. We wouldn't
want that as the default behavior. The responses about the "setgid"
bit on directories suggest a possible way to make this work, but
I'll have to test the behavior to see if it really happens. It's
not documented, but who knows? It just might work. Do you have
experience with this?

>It's too bad that the exports file does not support "mapgroup" commands
>orthogonal to the "maproot" command.  Arbitrary user mappings might be
>of value too, but I can see how they could quickly grow completely out
>of reason.

Well, any sort of access control to a UNIX server really ought to include
both user and group permissions. Otherwise, you've lost the control that
UNIX affords over file access.

Groups in UNIX are far from ideal, though, because a file can have only one
owning group. And the number of groups of which a user can be a member
is limited and implementation-dependent. (FreeBSD squawks when a user
is a member of more than 16 groups.) The number of members of a group
is likewise limited. (I believe that in FreeBSD the limit's 200.) All of 
these constraints make implementing any security scheme a bit awkward.

>I'm thinking you can probably do this by exporting the filesystem from
>the ftp server ONLY to the printer's workstation, and exporting with
>-mapall=printeruid:printergid.

I'm looking at something like this. If we use a dedicated Ethernet
interface for the link to the printer's workstation and only allow
Subnet 10 IP addresses on that link, we'll be able to restrict mounts
to the one Subnet 10 address. It'd be tough to penetrate this,
especially with ipfw configured properly and a firewall router on
the other interface.

Y'know, it'd be really nice if NFS had "accounts" and "passwords" per se, 
but as far as I know the only version that had anything like this was a
proposed "standard" for file transfers that went nowhere. (What was 
the name again? I forget.)

>Best of luck, and write back if you have specific questions.  I'm a little
>intrigued by this.  I know several print shops around here that try, and
>often fail, to have clients email them large postscript or pre-ripped print
>files, and they may be able to benefit from your experience also.  ;^)

Well, FTP isn't an ideal solution, because it sends passwords in the clear.
But if you place disk space quotas on the users and chroot them, the damage 
that can be done with a sniffed password is at least limited. A VPN protocol 
or secure sockets would be preferable, and I'm moving them to such things as
fast as I can.

--Brett




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.32.19990409223443.0451c100>