Re: rexec as root
On Fri, 12 May 2000, Nick Sayer wrote: I would like to gather some opinions in regards to _very slightly_ backing off on rexec's security. rexec makes the following checks, and refuses to allow usage if any are true: uid == 0 I turned off this check at sarnoff six years ago. rexec allows you to quickly run lots of commands across a cluster, given the right tool (see http:/www.acl.lanl.gov/~rminnich and look at vex). Using rexec I could run commands across a 128-node cluster in less than a second. Nothing I have ever seen is nearly as fast. A secure low-overhead remote exec is the right thing; rexec with uid == 0 disabled is the next-best thing. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
rexec as root
I would like to gather some opinions in regards to _very slightly_ backing off on rexec's security. rexec makes the following checks, and refuses to allow usage if any are true: uid == 0 password is blank user is in /etc/ftpusers I put it to everyone that the first and third checks are equivalent and redundant. Moreover, since the first check can be done by the third check (and is at install time by default) without recompiling rexecd, removing the first check results in no real loss of security, while slightly increasing flexibility for those who have some need for it. Yes, the r commands are deprecated. But they are still there, and I am all for allowing the administrator to decide to override defaults rather than forcing them to alter the source and recompile it. Comments? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rexec as root
On Fri, 12 May 2000, Nick Sayer wrote: I would like to gather some opinions in regards to _very slightly_ backing off on rexec's security. Don't do it? rexec makes the following checks... [ uid==0, password blank, uname in /etc/ftpusers ] I put it to everyone that the first and third checks are equivalent and What you say is correct, but personally I think deprecated really should mean deprecated. There are better alternatives to rexec (ssh - open or otherwise) and they ought to be pushed. If admins _really_ want this functionality, patching the source isn't so much of a hardship. But it makes the path f least resistance the installation of a better alternative :-) jan -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] Spreadsheet through network. Oh yeah. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rexec as root
What you say is correct, but personally I think deprecated really should mean deprecated. There are better alternatives to rexec (ssh - open or otherwise) and they ought to be pushed. FreeBSD provides tools for people, we don't enforce our policy on them. I think the proposed change makes sense. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rexec as root
In message [EMAIL PROTECTED] Nick Sayer writes: : I put it to everyone that the first and third checks are equivalent and : redundant. They are not redundant. They provide a little (although not much) extra security for those sites that have had a root account added by intruders which the admin know nothing of. In the absense of this test, machines in a yp netowrk would be extremely vulnerable to root uid penetration when an intruder can hack the yp database, or spoof replies. OK, so that's a weak wall for a weak protocol, but I'm pretty sure why the extra check for uid 0 is in there. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
