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). -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
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 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, Hrmm... Chris> Sorry for being vague. Ok, I have these in /etc/sudoers for joeuser. Chris> joeuser is also in the wheel group. [...] Chris> I am finding that I need to add joeuser to use pkg_* tools, tcpdump as Chris> well. Chris> Chris> Is this the right way to do this? Um, these are a *lot* of privileges for a bunch of random users on a multi-user system. These should not generally be given to users like this. How many users are you running on these systems? Why do they need control of the daemons, your startup scripts, and many other important files? When you give a setup like this, it looks to be more about a single user trying to work (say, on a laptop) using OpenBSD as a workstation? I can not recall if you already provided this information, but, here are some questions: 1) How many users are on this system? 2) How many need to run these commands? 3) In what environment is this system running [server room, multi-user workstation, laptop, personal computer]? Most of these are commands that should only be run by specific groups of users, who are dealing with isolated parts of the system. If this is a single-user workstation or roaming machine, then one group, wheel, and the appopriate user thrown into that group, given permissions to run anything as root, will probably suffice, because one expects this user to treat his own account as securely as the root account. On the other hand, if you have multiple admins, who are in charge of different areas of the machine, then you probably want to set up groups for each of these classes of users, and then set sudo permissions based on this. Another suggestion is to always require a password when running a sudo command. After the first entry, you can have a delay before asking for the password again if the system goes idle, but this helps on two counts: the user has a chance to double check his work, and if the user leaves his computer logged in for some reason, someone else getting into it probably won't readily have the password, and may save a bit of trouble. It looks like a lot of these commands have to do with the web server. The way I have it setup on my machine is that I have a few users given permissions (because they belong to the webadmin group), to edit web files, do various things. I could give them permissions as well to edit select system files, but I'm afraid that's not my goal. It might be yours, though. Bottom line, I only expect a single-user workstation/laptop to require an user to run all these various commands, and that user would be the main administrator anyways. Hence, wheel group will work fine, and why not grant any command? -- ((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/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 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 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 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
> 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 Sun, Sep 16, 2007 at 10:33:59PM -0400, Matthew Szudzik wrote: | /sbin/halt | 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
* 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 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 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=
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
> 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. Similar issues have been bugging me for a while, so let me chime in. I'm using OpenBSD on a laptop, and I find there are actually quite a few commands that require superuser privileges from an ordinary laptop user, namely /sbin/dhclient /sbin/halt /sbin/ifconfig /sbin/mount /sbin/umount /usr/local/bin/cdrecord /usr/local/bin/dvd+rw-mediainfo /usr/local/bin/gphoto2 /usr/local/bin/growisofs /usr/sbin/vnconfig Note that all of these commands are associated with access to the hardware, such as establishing an internet connection, shutting the computer down, mounting a USB flash drive, burning a CD/DVD, interacting with a digital camera, mounting an iso image, and so on. Some of the man pages (namely growisofs) warn against running these commands with sudo. What's a laptop user to do? 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?
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
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
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 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
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
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
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
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
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
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]