Thus spake Jeremy Enos ([EMAIL PROTECTED]):
> At 07:31 AM 2/11/2004, Sean Dague wrote:
> >On Thu, Feb 05, 2004 at 05:06:26PM -0600, Jeremy Enos wrote:
> >> No reason why we couldn't do that. (it won't be in the "configurator" as
> >> we now know it, due to the order of operations, but that's not
> >> relevant) I'm fine w/ something like that and defaulting to "yes"...
> >> however, could someone provide at least one solid reason not to simply
> >> setup tftpd all the time? I'm sure we include other tools for a
> >> catch-all/majority-use purpose, in spite of the fact that the user isn't
> >> *guaranteed* to use them. What's the big deal here? Why busy the
> >> interface?
> >
> >Because tftpd is a massive security hole. Unauthenticated file access to
> >the server is something that shouldn't be done to someone's machine without
> >their knowledge. About a year ago you commented that it was pretty bad
> >that
> >we leave it on after install of nodes, so turning it on for people that
> >don't ever need it seems *really* bad.
> >
> >Maybe print the text in BIG RED LETTERS "READ THIS PARAGRAPH OR YOUR
> >CLUSTER
> >WILL NOT INSTALL" kinda thing.
>
> If we're concerned about security of tftpd, I have a few comments.
>
> * concerns are pertinent to the subset that elect not to use pfilter
> * rsyncd is a MUCH greater hole, and it is and is going to continue to be
> on all the time
SystemImager devel code now does (and requires) "hosts allow = "
restrictions in rsyncd.conf on "golden clients" during prepareclient
with the required --server option, limiting access to the server.
The server side rsync header file
"/etc/systemimager/rsync_stubs/10header"
includes the comments below, and perhaps will automate and require the
addition of this in the near future:
#
# For additional security, modify and uncomment this line. See
# "man rsyncd.conf" for details.
#
#hosts allow = 127.0.0.0/24 MY_NET/NETMASK MY_CLIENT/32
As part of the OSCAR install, we could simply add a line like the above,
but with the compute node network information instead of MY_NET/NETMASK.
I know this only addresses one concern, but hey -- there you go.
> * both of these services can and should be tcp wrapped
> * if we can't take steps to secure a running tftpd, we've got serious
> problems. We are apparently comfortable having it running on some
> (arguably most) clusters, then we need a security scheme good enough for
> all anyway
> * It's not uncommon to have tftpd running all the time. You will find
> tftpd running on several large scale production systems (I'm not referring
> to NCSA's alone) as a necessity of design. This is not to mention any
> diskless system.
>
> I've encountered both types of questions/complaints.
>
> Complaint A: Hey... you guys just have tftpd on and waiting all the time
> and you didn't shut it off. I think that's sloppy and I didn't like that
> risk, so I had to shut it off myself.
>
> Complaint B: Arrrgggghhh!!! I've been debugging my network, trying
> different NICs, and playing with for days, because they always hang at
> TFTP.... something. I guess I missed the "Setup Network Boot" step. This
> is so frustrating!!
>
> Let me tell you that Complaint B is far more likely to cause someone to
> give up and abandon OSCAR. They're far more angry about it, and usually
> don't have a cluster installed yet. If we want to solve this with
> documentation, then document that they can shut it off. Our policy in the
> past has been to remove pitfalls if we can... protect the user from the
> user IF we can. Well, we can.
>
> We start several daemons that have security risks (at least one that's much
> worse than tftpd) and we don't throw up a big red letter warning for each
> one. I'll repeat myself that this is *not* a big deal. The implications
> of a user accidentally missing the step to turn it on are worse and more
> widespread than those of having it running w/o needing it. That's not just
> my opinion; there's a history of user feedback to base it on. And we
> haven't even taken steps to secure it yet (assuming the non-pfilter case),
> which will only reduce Complaint A further.
>
> btw- all this is moot in all cases except where floppy boot is used. I'm
> so tired of erroneously putting so much weight/emphasis on the fraction
> that still depends on floppies!!! Will it ever end?
>
> Jeremy
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Oscar-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/oscar-devel
>
--
---------------------------------------------------------
Brian Elliott Finley Argonne, MCS Division
Phone: 630.631.6621 http://thefinleys.com
GPG: 3FF8 D096 0E0C D3F3 29B7 6518 D20B 1931 10F8 EE52
---------------------------------------------------------
Hi! I'm a .signature virus! Copy me into your signature to help me spread!
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
