Date: Fri, 09 Apr 1999 22:19:57 -0600 From: Wes Peters <wes@softweyr.com> To: Brett Glass <brett@lariat.org> Cc: security@FreeBSD.ORG Subject: Re: Interesting problem: chowning files sent via FTP Message-ID: <370ED16D.582E4F19@softweyr.com> References: <4.2.0.32.19990409184654.045424d0@localhost> <4.2.0.32.19990409223443.0451c100@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote:
>
> 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?
I just gave it a try here, by adding myself to the "xten" group and
logging in freshly. I changed a directory under my home to group
xten, cd'd into it, and touched a file. Sure enough, it was owned
by group xten. I ftp'd to localhost, cd'd to that directory, and
put a file, which ended up owned by xten as well.
It looks like this will work for you.
> >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.
Yet another design for an ACL filesystem was bandied about a month ago,
but as usual everyone went hog-wild with unlimited lists of ACLs, and
disk blocks scattered all over hell and back, and then went nowhere with
it. And they wonder why I get pissed and tell them "do the simple one
first, then expand it if it needs expanding." Five or eight ACLs is
better than none, and is probably better than thousands of ACLs that
never get implemented, too.
> >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.
I'd suggest using a dedicated NIC on both the ftp server and the
printers workstation, if at all possible. A single crossover wire
would make it VERY difficult to abuse that interface for hacking
purposes, at least without being noticed. You could script a
simple monitor that would warn of any disruptions in service if you're
really concerned about the link.
> 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.)
FSP? I never really looked into it that much, it seemed like it was
doomed before it got out of the chute. Seems a shame, too, given that
it was supposedly more reliable than NFS and easier to control than
either NFS or FTP.
> >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.
One of these days somebody needs to actually implement a mailer that
supports the "external reference" capability of MIME. You know, you
attach a huge file to a mail message, and rather than sending the
file base64 encoded through the email system it sticks it on a secure
public server along with a list of who you've sent it to and an expiration
date. The public server will allow only those who were sent the file to
retrieve it. Once everyone has accessed the file OR the expiration date
has been reached, the file is quietly deleted from the public server.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
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?370ED16D.582E4F19>