Ralph Shumaker wrote: > David Brown wrote: >> On Mon, Aug 04, 2008 at 02:20:10AM -0700, Ralph Shumaker wrote: >> >>> The manuals have enlightened me on some things, but confused me on >>> many others. I want rafael to have full sudo access, but only if he >>> is at this keyboard I am using right now, regardless of whatever IPv4 >>> (or IPv6) address is currently assigned to eth0 by my DSL ISP. I >>> don't know if the IPv6 address ever changes. I haven't paid >>> attention. If it doesn't, perhaps I can somehow use that to lock it in? >> >> This is not what the Host field in the sudoers file is for. This is so >> that multiple machines can share a single sudoers file, and you can >> restrict a particular user to performing sudo on certain machines. But, >> it doesn't care how that user logged in. >> >> What is an acceptable method for that user to log in? Do you want them >> to have to be logged into a terminal console, or is an X connection >> acceptable. > > Acceptable would be any of the six consoles, F1 thru F6, and > gnome-terminal. I might be willing to accept other terminal windows > even though I rarely use the others, but preferably limited to this > machine. > >> >> The thing is that there is very little difference in the environment >> between a user logged in locally and one logged in remotely, especially >> if the local user is using X. This is part of what makes Unix/Linux so >> useful. > > I guess I got a bit confused. Somewhere along the way, I thought sudo > could be restricted to physical access on the machine. > >> >> You can set 'requiretty' which will at least require the remote user to >> have acquired a tty. This doesn't completly solve things, although it >> would catch simple cases of a remote user exploit that wasn't a login. >> >> You could check ownership of /dev/console, but I'm not sure how you >> could do that in sudo. Well, one ugly way would be to only allow the >> user to sudo 'wrapper' and have the wrapper program check ownership of >> console and then either deny it or execute the command. >> >> Do you plan on not allowing remote logins for this user? > > That is correct. I want this user to have sudo access, while limiting > vulnerability. If I'm not mistaken, a remote user who somehow gains > access to a regular user is limited to damaging that users files. But > if that user has full blown sudo access, then the cracker now has free run. > > It's not that I don't want to be able to log in from somewhere else. I > just don't see the need and figured it would be safer if that access > were denied. But that's when I thought such a thing was the design of > it. Now, I just want to give rafael full sudo usage, but limit > vulnerability. > > I've never done remote access. In fact, I would like to set up remote > access for myself for my friend's computer (perhaps my mom's also) for > whenever there is a problem so that I can try to fix it from home via > the interweb. But I have _no_ clue how to set that up. I don't know if > I would want full blown sudo access, but I would want to reduce > vulnerability. >
Perhaps this thread is a good place to echo a well-known security mantra. Start with nothing allowed, then explicitly open up only those capabilities you need. If you have no remote access (eg ssh, vnc, ftp, telnet(!),..) then you don't need to worry about differentiating non-local from local users. Thus, your sudo question becomes simplified, I think. It's still good you asked though, because it gave (Greg, I think) a good chance to explain what those host fields are for. And BTW, what do you want to allow your user to do, anyway? It did sound like you trusted him/her implicitly, but didn't trust remote access security mechanisms, or maybe didn't trust your users' ability to do remote access securely? Regards, ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
