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.
--
Ralph
--------------------
Once you have had a successful intrusion, you obviously didn't have enough.
If you never have a successful intrusion, do you have too much?
--Stewart Stremler, 2006 09 07 [regarding system security]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
