At 12:45 AM 4/21/98 -0600, seifriedat_private wrote: >> The solution to this configuration error is to stop the rcmd service on the >> server and when you need access use the netsvc command to start it. Since >> only the admin has the permissions to stop and start services I think this >> should pretty much cure the problem. However I'd really like to hear from >> anyone who has ideas on this one. >> >> Geo. > >Several possible solutions to remote UNIX style management of NT machines: > >To solve the RCMD.EXE problem (and quote the MS help files): > >Security is provided in two ways: > >The logged-on user must have interactive logon privileges on the target >computer in order to connect to it. > >Any programs executed on the target computer are executed impersonating >the logged-on user. Any access validation (such as opening files) is performed >as if the user were logged on to the local computer. I'm not sure this is actually true - some versions of rcmd don't impersonate properly. It may be fixed by this version, but I haven't verified that. >So simply tighten up permission on the server, remember by default the >group everyone can pretty much run amuck on the system, so simply remove >the group everyone's (and any other global/local groups or users that do >not need access to the files/etc) permissions from any file/programs you >deem sensitive (which should be most of them), this will keep the FP users >out of trouble. A better solution would be to create a FP users group and >simply give then no access to any sensitive areas. You can cause yourself massive headaches this way. If it is a dedicated IIS server, and provides no other services, this will work OK. If not, things will go wrong. Instead, look for places where everyone has > read access. Also, the FP users group (which isn't a bad idea by itself), will need at least read control (RX) in the system areas. What you want to control is write and delete permissions. >This is from NT Server Reskit Suppliment #2, I didn't bother to check the >original or Suppliment #1, but I suspect the same applies. Using the >.rhosts properly would seem to me to cut the risk down considerably and >be a better alternative in many ways then RCMD.EXE. rsh on NT is a disaster waiting to happen. NT has no way to change user context based solely on user name. It has to have a user-password pair, or a token it can impersonate. This means that any rsh daemon running under NT is going to be either running as LocalSystem (a VERY bad idea, and how the reskit version runs), or you're going to have to kludge up something where you store passwords. I flag the rshsvc on NT as a high risk vulnerability in the ISS scanner just from finding it installed. Even if there aren't any remote machines permitted, it would function as getadmin for a local user. I would strongly urge anyone NOT to use this. If you need to get a remote command line, remote console from the RK update is nice, or there are telnet and rlogin daemons available. Oh - I'd also point out that NT has no concept of denying non-priviledged users access to priviledged ports. Thus any UNIX box which trusts an NT box for rsh, better trust ALL the users on that NT box. David LeBlanc |Why would you want to have your desktop user, dleblancat_private |your mere mortals, messing around with a 32-bit |minicomputer-class computing environment? |Scott McNealy
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:50:11 PDT