This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [ITP] tftp-hpa 5.0
On 10/4/2010 4:24 AM, Gernot Hillier wrote:
> First of all, thanks for your detailed review, response and your
> suggestions!
You're welcome.
> Am 01.10.2010 17:47, schrieb Charles Wilson:
>>>> We'll need to coordinate the release of tftp-hpa
>>
>> Hmmm...now that I think about it, it would be really great if the
>> package name(s) themselves were simply tftp-5.0-N tftp-server-5.0-N
>> Users aren't going to CARE that the implementation/source came from
>> the 'tftp-hpa' distribution.
> Ic. I'm not that of a Cygwin expert so I just trust your opinion here.
> Changing the package accordingly is fine for me. (Keeping inetutils'
> tftp implementation was just a quick idea w/o thinking about the
> conflict resolving stuff).
OK. My revised package does this.
>> So, I really think you should enable IPv6. Now, that means a lot of
>> new porting work, because there are ALWAYS issues with porting IPv6
>> networking to cygwin/win32...see the rsh package's patches (also,
>> xinetd).
>
> Ic.
>
> Well, what I've proposed here was the result of an internal project
> where we just needed bare-bone IPv4 tftpd functionality in an isolated
> environment w/o security concerns. As I ended up in quite some compiling
> errors (and found some posts suggesting that those aren't that easy to
> fix), I simply tried disabling features until tftpd finally worked.
> "Worked for me", you know. :-)
And that's great; obviously your internal team can continue to use what
you have, until the revised version comes along. In fact, it's great
that you have an in-place testing environment; we can easily make sure
that the revised versions don't break anything.
> And as I wasn't sure if the package would be accepted or taken care of
> at all, I also didn't want to invest that much upfront effort, but chose
> to document limitations instead...
That makes sense. However, as we/I are *very* enthusiastic about
deleting inetutils' tftp in favor of tftp-hpa, now's the time to make
that investment.
> We can for sure try to re-enable and fix all these issues, but as for
> you, my time for these tasks is also quite limited and I can't promise
> quick results here...
NP.
>> Now, as far as dropping privileges...that's a tricky one. First,
>> your assumption that most people will run tftpd as a standalone
>> service under cygrunsrv is probably false. I imagine most people will
>> use a superserver (inetd or xinetd) instead.
> [...]
>
> Thanks for all the insights on this complicated topic!
Acquired through PAINFUL experience :-{
>> Now, IMO, you NEVER EVER EVER EVER want to run the tftp server as
>> ANY privileged user at all: cygserver, Administrator, SYSTEM, ...
> [...]
>> tftp is SO incredibly insecure it boggles the mind. Letting random
>> *unauthenticated* users upload to your machine (or download), using
>> the credentials of Administrator? Using client-specified paths? Not
>> just no, but hell no. (Recall that cygwin doesn't *really* jail
>> chrooted processes; they can always use win32 functions to "break
>> out").
>
> Hmmm, anyone running tftpd should know that (s)he should protect it from
> any productive network as it's insecure by design. In my eyes, putting
> tftpd behind an effective firewall is just the right answer here. Any
> effort spent to improve tftpd's security concept *if you don't trust his
> peers* will only raise the security bar from 10 to 12% IMHO.
True. Client IP's CAN be spoofed -- but cygwin's tcp wrappers operates
by default in PARANOID mode, so the attacker would also have to hijack
the local DNS server. Not impossible, but worth more than +2%
difficulty rating.
> That's the reason why I didn't spend any effort on this yet and why I
> personally don't see this as a top-prio.
Well, it should Just Work(tm); tcp_wrappers does all the heavy lifting.
We'll see.
> That's, btw, also the reason why I decided not to provide a
> (postinstall) script which activates a Windows service. People who want
> to use this piece should really know what they're doing...
Well, that's true of most insecure services. However, tftp-hpa DOES
drop privileges (assuming we un-#ifdef-out that stuff), so it NEEDS an
unprivileged user to change to. Since windows doesn't have a default
'nobody' user (other than Guest, and often that account is disabled
entirely), we need a script to create one. Even if it doesn't install
the service.
The problem with NOT making the process relatively turnkey simple, is
that you will spend five times the effort multiply answering FAQs on the
mailing list..."How do I..." This way, your form letter response is:
0) Read the documentation
1) run tftp-config
2) run xinetd-config
3) edit /etc/xinetd.d/tftp
- disabled yes
+ disabled no
4) (re)start xinetd:
cygrunsrv -E xinetd
cygrunsrv -S xinetd
Cut-n-paste as needed...(and note, variations like 'use inetd instead'
or 'install tftpd as a standalone service' are not mentioned; save that
for the documentation that nobody will read.)
>> We should probably take additional discussions offline, just to keep
>> from annoying the list with ongoing development.
>
> Sure. I'll come back to you via private mail as soon as I had a detailed
> look on all your points...
I guess not; see Corinna's reply.
--
Chuck