Re: : sudo wheel group
On Mon, Sep 17, 2007 at 10:49:04AM -0400, Woodchuck wrote: On Mon, 17 Sep 2007, Chris wrote: On 9/17/07, Darrin Chandler [EMAIL PROTECTED] wrote: problem is. This is why people keep asking you to explain the problem more. Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser. joeuser is also in the wheel group. joeuser server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb mount can be leveraged to full root. joeuser server = NOPASSWD: /usr/local/bin/vim /var/www/conf/httpd.conf joeuser server = NOPASSWD: /usr/local/bin/vim /etc/rc.local Both of these commands, if done with vi, probably allow joe to launch a root shell, ex command :!sh I don't think vim has any better protections. I just want to remind about for editing files you can use 'sudoedit' entries. That way you can run any editor, and it runs on a temporary copy of the target file, and the result is copied to the target with the right permissions afterwords. Executing shells from e.g vim is no longer a security hole. It is all in the man pages sudo(8) and sudoers(5). snip -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sudo wheel group
On Sun, 16 Sep 2007, Matthew Szudzik wrote: Does anyone currently use the operator group for anything, or is it just a I do, for backups. -- Antoine
Re: sudo wheel group
Matthew Szudzik wrote:
The fact that you need to provide normal users with these kind of
privileges indicates a possible flaw in your overall scheme. You may
find that, after careful reconsideration, there are precious few
commands that you would actually have to allow the users to run with
superuser privileges.
Personally, I wish that the operator group would give a user full access
to these ordinary hardware resources. But currently, the operator group
is only given read access (but not write access) to a few devices, and
access to the shutdown command (which produces a very annoying beep
that is unsuitable for use in a boardroom or lecture hall).
Does anyone currently use the operator group for anything, or is it just a
historical vestige? Would there be anything wrong with giving the
operator enough hardware access to run the commands above?
I use the operator for dumps, which is a readonly operation.
# su operator -c dump ${DmpLvl}au -f - $dskpart | ssh backupbox dd
of=dumpfile
Re: sudo wheel group
On 9/17/07, Darrin Chandler [EMAIL PROTECTED] wrote: problem is. This is why people keep asking you to explain the problem more. Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser. joeuser is also in the wheel group. joeuser server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb joeuser server = NOPASSWD: /usr/local/bin/vim /var/www/conf/httpd.conf joeuser server = NOPASSWD: /usr/local/bin/vim /etc/rc.local joeuser server = NOPASSWD: /usr/sbin/apachectl joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/access_log joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/error_log joeuser server = NOPASSWD: /usr/local/bin/vim /etc/motd joeuser server = NOPASSWD: /usr/local/bin/vim /etc/pf.conf I am finding that I need to add joeuser to use pkg_* tools, tcpdump as well. Is this the right way to do this? Thanks.
Re: sudo wheel group
* Matthew Szudzik [EMAIL PROTECTED] [2007-09-17 04:41]: Does anyone currently use the operator group for anything sure, taking dump(8)s -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: sudo wheel group
On Sun, Sep 16, 2007 at 10:33:59PM -0400, Matthew Szudzik wrote: | /sbin/halt SNIP | Does anyone currently use the operator group for anything, or is it just a | historical vestige? Would there be anything wrong with giving the | operator enough hardware access to run the commands above? If you're in operator, you can at least shutdown or reboot your system with /sbin/shutdown (which is setuid root and executable by those in operator). That's at least one of your list ;) Cheers, Paul 'WEiRD' de Weerd PS: if you feel you must use halt; alias halt=/sbin/shutdown -h now -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: sudo wheel group
If you're in operator, you can at least shutdown or reboot your system with /sbin/shutdown (which is setuid root and executable by those in operator). But (as I mentioned in the message), shutdown makes a very annoying beep. When shutting down the laptop in a hushed boardroom or lecture hall, the beep is unacceptable. And anyway, the shutdown command is overkill, I don't need to notify other users of the shutdown, since I'm the only user.
Re: sudo wheel group
On 2007/09/17 09:52, Matthew Szudzik wrote: But (as I mentioned in the message), shutdown makes a very annoying beep. You might find this useful: $ grep bell /usr/src/etc/wsconsctl.conf #keyboard.bell.volume=0 # mute keyboard beep
Re: sudo wheel group
On Mon, 17 Sep 2007, Chris wrote: On 9/17/07, Darrin Chandler [EMAIL PROTECTED] wrote: problem is. This is why people keep asking you to explain the problem more. Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser. joeuser is also in the wheel group. joeuser server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb mount can be leveraged to full root. joeuser server = NOPASSWD: /usr/local/bin/vim /var/www/conf/httpd.conf joeuser server = NOPASSWD: /usr/local/bin/vim /etc/rc.local Both of these commands, if done with vi, probably allow joe to launch a root shell, ex command :!sh I don't think vim has any better protections. This was, at one time, a common hole in programs like chpass(1). And, of course, joe can execute arbitrary commands through rc.local. joeuser server = NOPASSWD: /usr/sbin/apachectl Some sort of cleverness with groups might eliminate this one. joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/access_log joeuser server = NOPASSWD: /usr/bin/tail -f /var/www/logs/error_log Just make these readable by group wheel. joeuser server = NOPASSWD: /usr/local/bin/vim /etc/motd joeuser server = NOPASSWD: /usr/local/bin/vim /etc/pf.conf Same comments as about previous vi-as-root. Make these files rw by group wheel, and no sudo is needed. Changes might be needed to /etc, too. Consider making /etc/motd a symbolic link to a file that joe can edit without privilege. This might work with pf.conf, too, but I dunno -- maybe pf chokes if ownership isn't right? Try an experiment. I am finding that I need to add joeuser to use pkg_* tools, tcpdump as well. Is this the right way to do this? No, not unless you trust joe with full root. Dave -- America ... might become dictatress of the world. She would be no longer the ruler of her own spirit. -- John Quincy Adams, July 4, 1821
Re: sudo wheel group
On Mon, Sep 17, 2007 at 09:52:06AM -0400, Matthew Szudzik wrote: If you're in operator, you can at least shutdown or reboot your system with /sbin/shutdown (which is setuid root and executable by those in operator). But (as I mentioned in the message), shutdown makes a very annoying beep. When shutting down the laptop in a hushed boardroom or lecture hall, the beep is unacceptable. And anyway, the shutdown command is overkill, I don't need to notify other users of the shutdown, since I'm the only user. I don't have an openbsd box I can try on right now, but I think that if you mute the beeps you won't be hearing it when shutting down (which means that since it is unacceptable in your lecture hall, you should mute it when your session starts). Also, I don't think that notification of logged in users is that much of an overkill if you compare to what happens when you do the shutdown. Gilles
Re: sudo wheel group
On 9/17/07, Chris [EMAIL PROTECTED] wrote: Ok, I have these in /etc/sudoers for joeuser. joeuser is also in the wheel group. Why are you adding wheel group membership? Root access through sudo(8) does not require the user to be a member of wheel, but su(8) does. Jim
Re: sudo wheel group
On Sun, 16 Sep 2007, Matthew Szudzik wrote: What's a laptop user to do? Run as root -- why not? Be careful. Limit PATH. Keep the cat off the keyboard. (This can be pesky if you're using vi at the time.) Open a root xterm, make the background some weird color, use a font and size you don't normally use. You might try setting a deadman to log it out automatically after N seconds of inactivity at the prompt. (man ksh, see the TMOUT variable). Set window-manager attributes so it's always on top and can't be shaded or iconified if you want to be paranoid. Measure twice, cut once; you know the drill. Dave
Re: sudo wheel group
Chris wrote: I am finding that I need to add joeuser to use pkg_* tools, tcpdump as well. Is this the right way to do this? You might as well give joeuser root password if you give him access to pkg_add and pkg_delete tools. package framework has ability to run scripts as root. All joeuser needs to do is create his own package.tgz and run pkg_add $HOME/package.tgz. I agree with others in this thread: your security design is flawed. * Work towards alternative solutions when possible (i.e. can joeuser run Ethereal from the client machine to get the network traffic instead of tcpdump on the server?) * Give read access if all they need is read-only. * Don't push sysadmin work on the ?web developer (joeuser)? package management is a perfect example. tcp dumps slightly less so. * Mount does not necessarily require root. See mount and sysctl.conf man pages for conditions and sysctl settings. If you still want to go the sudo route after the comments you have received, that is your decision. You can create server, user and command groups in sudoers to help keep your sudoers file sane. See man page for exact syntax. -Keith
Re: sudo wheel group
On 9/16/07, Aaron W. Hsu [EMAIL PROTECTED] wrote: What exactly are you trying to enable users to do? The fact that you need to provide normal users with these kind of privileges indicates a possible flaw in your overall scheme. You may find that, after careful reconsideration, there are precious few commands that you would actually have to allow the users to run with superuser privileges. So what's the ideal way to do things? Adding joeuser in the wheel group and then add - joeuser ALL=(ALL) ALL in sudoers? And when the joeuser account gets cracked, the cracker would be able to run privileged commands? That defies the whole purpose. The other possibility is to login as root (when are where needed, that is) and do what is required. But afterboot(8) doesn't recommend that as an option.
Re: sudo wheel group
Chris wrote: On 9/16/07, Aaron W. Hsu [EMAIL PROTECTED] wrote: What exactly are you trying to enable users to do? The fact that you need to provide normal users with these kind of privileges indicates a possible flaw in your overall scheme. You may find that, after careful reconsideration, there are precious few commands that you would actually have to allow the users to run with superuser privileges. So what's the ideal way to do things? Please define things. Adding joeuser in the wheel group and then add - joeuser ALL=(ALL) ALL in sudoers? And when the joeuser account gets cracked, the cracker would be able to run privileged commands? That defies the whole purpose. The other possibility is to login as root (when are where needed, that is) and do what is required. But afterboot(8) doesn't recommend that as an option. /Alexander
Re: sudo wheel group
Chris wrote: ... user server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb I might suggest using groups rather than individual users in sudoers. On the small scale both are about the same, but using groups scales better (both time and quantity). So the above could be for the group ejanitor: %ejanitor server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb %maintainerALL = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root %web ALL = (ALL) /usr/sbin/apache2ctl [a-z]* (Note: double-check the above before trying yourself.) But it seems like a lot of work as I have around 30 servers then the same configuration could be spread around the 30-odd servers and you just have to adjust which users are members of the appropriate group also take a look at host aliases: http://www.openbsd.org/cgi-bin/man.cgi?query=sudoers#EXAMPLES and not all servers require the exact same command. Please give a little more detail. Are these all variations of mount and locate.updatedb? Or do you mean a small random handful of commands? Is there any easier and secure way of populating the sudoers files? Using groups to grant privileges to users and using host aliases to apply those privileges to specific servers? Regards -Lars
Re: sudo wheel group
On 9/16/07, Chris [EMAIL PROTECTED] wrote: So what's the ideal way to do things? Adding joeuser in the wheel group and then add - joeuser ALL=(ALL) ALL in sudoers? And when the joeuser account gets cracked, the cracker would be able to run privileged commands? That defies the whole purpose. The other possibility is to login as root (when are where needed, that is) and do what is required. But afterboot(8) doesn't recommend that as an option. From ESR's FAQ on asking useful questions (http://catb.org/~esr/faqs/smart-questions.html#goal): If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on. Why are you trying to give some users access to some privileged commands, and can you give more examples of the commands they need access to? There might be a better way to do what you're trying to do, but we won't know that until we understand what it is you're trying to do. (In the big picture sense, not in the how do I make this work with sudo? sense.) As far as adding users to the sudoers file, doing so usually implies a certain level of trust. If you can not trust the user to monitor their account, and if you cannot trust the user to use a strong password and keep it secret, then you cannot trust the user with sudo access. Also, every privileged command that you give the users access to is a resource which they might use in a way that you didn't think of. - R.
Re: sudo wheel group
On Sun, Sep 16, 2007 at 05:14:30PM +1000, Chris wrote: So what's the ideal way to do things? Ok, here's the scoop... there is NO single best way. There are lots of ways to solve these kinds of problems, and ideal changes with what the problem is. This is why people keep asking you to explain the problem more. Possible answers might be: write a special suid script and only give sudo access to that; give sudoers specs for each and every command needed; give full sudo access and imprison the user if they abuse it. There are so many more options it's not even funny, and nobody can tell which one is a good solution to your problem, since we don't know what that problem is. There's even a chance that no special sudo access is needed at all for some of the tasks. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: sudo wheel group
Chris, Thanks for the message... Chris So what's the ideal way to do things? Of course, the ``ideal'' way to do anything really depends on what you want to do. It would help if you could give us some more details about what you are trying to do on the grand scheme of things, so that we could understand what's really necessary and what is not. Usually, there are a specific number of administrators who require privileges to work on the system. They are expected to be knowledgeable and competent staff who will select good passwords and enforce the security of their own accounts. These people will often be given a special group and an entry in the sudoers file to allow them to do what they need to do. Then, there is often another class of users for workstation setups, where there may be less than competent end-users trying to use the system. They are almost guaranteed to never have to run privileged commands if everything is done right. On the other hand, there could be exceptions, and as such, such users may be given very select commands to run for very specific instances. Again, this is just a common case, we need to know more information about your own individual case in order to advise a better way of doing things. -- ((name Aaron Hsu) (email/xmpp [EMAIL PROTECTED]) (phone 703-597-7656) (site http://www.aaronhsu.com;)) [demime 1.01d removed an attachment of type application/pgp-signature]
Re: sudo wheel group
On 9/16/07, Chris [EMAIL PROTECTED] wrote: So what's the ideal way to do things? Adding joeuser in the wheel group and then add - joeuser ALL=(ALL) ALL in sudoers? And when the joeuser account gets cracked, the cracker would be able to run privileged commands? cp /bin/sh /usr/local/bin/xsh chmod u+s /usr/local/bin/xsh then only tell the trusted users about xsh, and you can avoid sudo altogether.
Re: sudo wheel group
Ted Unangst wrote: cp /bin/sh /usr/local/bin/xsh chmod u+s /usr/local/bin/xsh then only tell the trusted users about xsh, and you can avoid sudo altogether. Ohhh... EEEVVVILLL... :) -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salax
sudo wheel group
I been looking for ways to let normal user run privileged commands and after some searching found that adding users to the wheel group is bad and also adding NOPASSWD and ALL = ALL to sudoers for an user is also plain as bad. The only alternative I can think of at the moment is to populate the sudoers file with specific commands the user would be running and thus I am doing this - user server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb But it seems like a lot of work as I have around 30 servers and not all servers require the exact same command. Is there any easier and secure way of populating the sudoers files? Thanks.
Re: sudo wheel group
What exactly are you trying to enable users to do? The fact that you need to provide normal users with these kind of privileges indicates a possible flaw in your overall scheme. You may find that, after careful reconsideration, there are precious few commands that you would actually have to allow the users to run with superuser privileges. In other words, what problems are you trying to solve that require root privileges? -- ((name Aaron Hsu) (email/xmpp [EMAIL PROTECTED]) (phone 703-597-7656) (site http://www.aaronhsu.com;)) [demime 1.01d removed an attachment of type application/pgp-signature]
Re: sudo wheel group
On 9/15/07, Chris [EMAIL PROTECTED] wrote: I been looking for ways to let normal user run privileged commands and after some searching found that adding users to the wheel group is bad and also adding NOPASSWD and ALL = ALL to sudoers for an user is also plain as bad. The only alternative I can think of at the moment is to populate the sudoers file with specific commands the user would be running and thus I am doing this - user server = NOPASSWD: /sbin/mount, /usr/libexec/locate.updatedb But it seems like a lot of work as I have around 30 servers and not all servers require the exact same command. Is there any easier and secure way of populating the sudoers files? Thanks. Very much listen to what Aaron said (normal users needing root == overall flaw) but if you really do need to do this sort of thing, why not just script it? Write a script that generates these 30 sudoers files for you. -Nick
