Sudo

  • SpooF
  • ٩๏̯͡๏۶
  • Bronze Member
  • User avatar
  • Joined: May 22, 2004
  • Posts: 3415
  • Loc: Richland, WA
  • Status: Offline

Post January 21st, 2008, 12:28 pm

I've been reading around and alot of people seem to believe that using sudo introduces bad practive when running linux, whats your opinion?

I'm a novice when it comes to linux, over the years I've played around with it and I have really only touched two distributors, Ubuntu and Fedora Core. I've installed CentOS once but never went back to it.

I tried running linux on my main machine but I couldnt get away from my favorite IDE, PHP Designer by MPSOFTWARE. (I still have it on my HDD but after installing windows I lost Grubs, so I will have to reinstall grubs sometime.)

I'm currently looking at setting up a small machine to run a server release of linux from some distributor, been leaning towards Ubuntu just because I have the most practice with it.

However, before I do it I would like to know your option on Sudo.
#define NULL (::rand() % 2)
  • Anonymous
  • Bot
  • No Avatar
  • Joined: 25 Feb 2008
  • Posts: ?
  • Loc: Ozzuland
  • Status: Online

Post January 21st, 2008, 12:28 pm

  • kc0tma
  • o|||||||o
  • Web Master
  • User avatar
  • Joined: Jul 20, 2007
  • Posts: 3318
  • Loc: Trout Creek, MT
  • Status: Offline

Post January 21st, 2008, 1:47 pm

Sudo is handy because if you log in as root, it is easy to screw something up pretty bad.

But on the other hand, one of our red hat servers at work has an application for payroll stuff, and the people basically telnet to the server to run it. If they found out about sudo, they could execute commands we don't want them to do.

So in my own opinion, I don't particularly like sudo. I tolerate it because o my mac os x, but if I had a choice I would stay away from it.
Like Mr Spork, I also write about my interest in alcoholic beverages.
  • AnarchY SI
  • Web Master
  • Web Master
  • User avatar
  • Joined: Oct 30, 2004
  • Posts: 2521
  • Loc: /usr/src/MI
  • Status: Offline

Post January 21st, 2008, 6:10 pm

sudo is handy if the only person accessing the server (/computer) is you. it's not connected to the internet, its not serving a company, etc. but if your server is connected to the internet and a regular user account gets hacked because it has a weak password and that account is part of the sudoers group, your server is effed =[
you CAN disallow sudo'ing in ubuntu, however, if you still wanted to use that OS..
Image
"In a world without walls and fences, who needs Windows and Gates?"
  • joebert
  • Sledgehammer
  • Genius
  • No Avatar
  • Joined: Feb 10, 2004
  • Posts: 13458
  • Loc: Florida
  • Status: Offline

Post January 21st, 2008, 8:05 pm

As long as there's only one person who can use it, it's great.
Strong with this one, the sudo is.
  • AnarchY SI
  • Web Master
  • Web Master
  • User avatar
  • Joined: Oct 30, 2004
  • Posts: 2521
  • Loc: /usr/src/MI
  • Status: Offline

Post January 21st, 2008, 9:34 pm

Quote:
..., it's great.

eh.. i'd disagree. for me, its less annoying to enter su, password, all the commands i want to execute with elevated privileges than to have to remember to preface every single command with sudo..
Image
"In a world without walls and fences, who needs Windows and Gates?"
  • spork
  • Brewmaster
  • Silver Member
  • User avatar
  • Joined: Sep 22, 2003
  • Posts: 6134
  • Loc: Seattle, WA
  • Status: Offline

Post January 21st, 2008, 10:33 pm

http://xkcd.com/149/

:lol:

And I have to agree with SI on this one:
AnarchY SI wrote:
for me, its less annoying to enter su, password, all the commands i want to execute with elevated privileges than to have to remember to preface every single command with sudo..
The Beer Monocle. Classy.
  • SpooF
  • ٩๏̯͡๏۶
  • Bronze Member
  • User avatar
  • Joined: May 22, 2004
  • Posts: 3415
  • Loc: Richland, WA
  • Status: Offline

Post January 22nd, 2008, 8:54 am

lol, my new favorite comic.

http://xkcd.com/123/
#define NULL (::rand() % 2)
  • joebert
  • Sledgehammer
  • Genius
  • No Avatar
  • Joined: Feb 10, 2004
  • Posts: 13458
  • Loc: Florida
  • Status: Offline

Post January 22nd, 2008, 10:41 am

AnarchY SI wrote:
Quote:
..., it's great.

eh.. i'd disagree. for me, its less annoying to enter su, password, all the commands i want to execute with elevated privileges than to have to remember to preface every single command with sudo..


It helps me remember which commands require super user privledges.
Strong with this one, the sudo is.
  • AnarchY SI
  • Web Master
  • Web Master
  • User avatar
  • Joined: Oct 30, 2004
  • Posts: 2521
  • Loc: /usr/src/MI
  • Status: Offline

Post January 23rd, 2008, 7:21 am

spork wrote:
http://xkcd.com/149/

that ones got my vote. the centrifuge is pretty up there tho..
Image
"In a world without walls and fences, who needs Windows and Gates?"
  • Daemonguy
  • Moderator
  • Web Master
  • User avatar
  • Joined: Jan 23, 2004
  • Posts: 2675
  • Loc: Somewhere outside the box in Sarasota, FL.
  • Status: Offline

Post January 23rd, 2008, 9:24 am

Sudo does not protect you from making the same blunders as root. Effectively everything in the sudoers is done as root (or as the denoted user).

What it does is provide the administrator with a list of who did what command when. If someone can log in as root, then you have no record of who performed which command.

Additionally, you can limit the type, depth and variety of executable sudo has permission to run. Right down to the group level as well.

Every *nix system may employ sudo.

It does not exist to make the user's life easier -- it exists to make admin's life easier. :)

That's the nutshell version. If you really want me to discuss in depth, I will.
"It's always a long day, 86,400 won't fit into a short."
  • kc0tma
  • o|||||||o
  • Web Master
  • User avatar
  • Joined: Jul 20, 2007
  • Posts: 3318
  • Loc: Trout Creek, MT
  • Status: Offline

Post January 23rd, 2008, 9:42 am

Daemonguy wrote:
If someone can log in as root, then you have no record of who performed which command.


But nobody but the administrator(s) should have that root password. If you have people logging in as root instead of with their own credentials, you are asking for trouble.
Like Mr Spork, I also write about my interest in alcoholic beverages.
  • joebert
  • Sledgehammer
  • Genius
  • No Avatar
  • Joined: Feb 10, 2004
  • Posts: 13458
  • Loc: Florida
  • Status: Offline

Post January 23rd, 2008, 9:51 am

Daemonguy wrote:
That's the nutshell version. If you really want me to discuss in depth, I will.


You've got my attention.

There wasn't a single thing in your post that I already knew. :D
Strong with this one, the sudo is.
  • AnarchY SI
  • Web Master
  • Web Master
  • User avatar
  • Joined: Oct 30, 2004
  • Posts: 2521
  • Loc: /usr/src/MI
  • Status: Offline

Post January 23rd, 2008, 10:09 am

kc0tma wrote:
But nobody but the administrator(s) should have that root password. If you have people logging in as root instead of with their own credentials, you are asking for trouble.

thats why you dont add anyone who's not an administrator to the sudoers file..
if you're not in the sudoers file, you can't sudo >.<
Image
"In a world without walls and fences, who needs Windows and Gates?"
  • Daemonguy
  • Moderator
  • Web Master
  • User avatar
  • Joined: Jan 23, 2004
  • Posts: 2675
  • Loc: Somewhere outside the box in Sarasota, FL.
  • Status: Offline

Post January 23rd, 2008, 4:24 pm

joebert wrote:
Daemonguy wrote:
That's the nutshell version. If you really want me to discuss in depth, I will.


You've got my attention.

There wasn't a single thing in your post that I already knew. :D

Heh.

Well what else can I toss out as pearls of wisdom?

'Sudo' stands for one of two things; "Super User Do" or "Substitute User Do" the reasons which will become apparent.

While most folks attribute sudo to running commands a root (or the super user), it is also used to allow privileged use of other account names (i.e. users, instance owners and application ids).
As an example, a process needs to run as a particular access id, say 'widget' in order to properly interact with another process, or to engage a process with proper permission sets employed.

Now in this case, technically, we are sudoing the su command (switch user) so the argument could be made that it (sudo) is merely elevating privilege to yet another executable. It's a subtle difference in semantics, as sudo will ensure a proper log of the su command and note the user id one has become. In other words, allowing the user to act in the capacity of a super user to switch to another userid. I argue that it's more complicated than that, and the two work harmoniously and to a different purpose than stand-alone. That however, is a matter of opinion. ;)

The history (and you'll forgive my lack of memory and thus missing the exacting specifics I am widely known for) of the command dates back to SUNY in the 80's. It is however currently managed by the OpenBSD dev team -- who exactly escapes me. I do know it is distributed under the BSD license.

Typically the config file lives in /etc/sudoers. It's rather lengthy and can be configured to permit an almost limitless amount of entirely specific permission attributes. It can be as complex or as generic as it needs to be on a user by user basis or group by group basis.

All instances are logged, including failed attempts or attempts to access executables not included in that user's or group's configuration.
Additionally, it does not require foreknowledge of any other system passwords; the user employs their login password to enter this state of elevated access permission.

Here's a run down of some of the flags used when calling the command shell.

Code: [ Select ]
OPTIONS
    sudo accepts the following command line options:

    -V The -V (version) option causes sudo to print the version number and exit. If the invoking user is already root the -V option will print out a list of the defaults sudo
      was compiled with as well as the machine's local network addresses.

    -l The -l (list) option will list out the allowed (and forbidden) commands for the user on the current host.

    -L The -L (list defaults) option will list out the parameters that may be set in a Defaults line along with a short description for each. This option is useful in conjunc­
      tion with grep(1).

    -h The -h (help) option causes sudo to print a usage message and exit.

    -v If given the -v (validate) option, sudo will update the user's timestamp, prompting for the user's password if necessary. This extends the sudo timeout for another 5
      minutes (or whatever the timeout is set to in sudoers) but does not run a command.

    -k The -k (kill) option to sudo invalidates the user's timestamp by setting the time on it to the epoch. The next time sudo is run a password will be required. This option
      does not require a password and was added to allow a user to revoke sudo permissions from a .logout file.

    -K The -K (sure kill) option to sudo removes the user's timestamp entirely. Likewise, this option does not require a password.

    -b The -b (background) option tells sudo to run the given command in the background. Note that if you use the -b option you cannot use shell job control to manipulate the
      process.

    -p The -p (prompt) option allows you to override the default password prompt and use a custom one. The following percent (‘%') escapes are supported:

      %u   expanded to the invoking user's login name

      %U   expanded to the login name of the user the command will be run as (defaults to root)

      %h   expanded to the local hostname without the domain name

      %H   expanded to the local hostname including the domain name (on if the machine's hostname is fully qualified or the fqdn sudoers option is set)

      %%   two consecutive % characters are collaped into a single % character

    -c The -c (class) option causes sudo to run the specified command with resources limited by the specified login class. The class argument can be either a class name as
      defined in /etc/login.conf, or a single '-' character. Specifying a class of - indicates that the command should be run restricted by the default login capabilities for
      the user the command is run as. If the class argument specifies an existing user class, the command must be run as root, or the sudo command must be run from a shell
      that is already root. This option is only available on systems with BSD login classes where sudo has been configured with the --with-logincap option.

    -a The -a (authentication type) option causes sudo to use the specified authentication type when validating the user, as allowed by /etc/login.conf. The system administra­
      tor may specify a list of sudo-specific authentication methods by adding an "auth-sudo" entry in /etc/login.conf. This option is only available on systems that support
      BSD authentication where sudo has been configured with the --with-bsdauth option.

    -u The -u (user) option causes sudo to run the specified command as a user other than root. To specify a uid instead of a username, use #uid.

    -s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified in passwd(5).

    -H The -H (HOME) option sets the HOME environment variable to the homedir of the target user (root by default) as specified in passwd(5). By default, sudo does not modify
      HOME.

    -P The -P (preserve group vector) option causes sudo to preserve the user's group vector unaltered. By default, sudo will initialize the group vector to the list of groups
      the target user is in. The real and effective group IDs, however, are still set to match the target user.

    -r The -r (role) option causes the new (SELinux) security context to have the role specified by ROLE.

    -t The -t (type) option causes the new (SELinux) security context to have the have the type (domain) specified by TYPE. If no type is specified, the default type is derived
      from the specified role.

    -S The -S (stdin) option causes sudo to read the password from standard input instead of the terminal device.

    -- The -- flag indicates that sudo should stop processing command line arguments. It is most useful in conjunction with the -s flag.
  1. OPTIONS
  2.     sudo accepts the following command line options:
  3.     -V The -V (version) option causes sudo to print the version number and exit. If the invoking user is already root the -V option will print out a list of the defaults sudo
  4.       was compiled with as well as the machine's local network addresses.
  5.     -l The -l (list) option will list out the allowed (and forbidden) commands for the user on the current host.
  6.     -L The -L (list defaults) option will list out the parameters that may be set in a Defaults line along with a short description for each. This option is useful in conjunc­
  7.       tion with grep(1).
  8.     -h The -h (help) option causes sudo to print a usage message and exit.
  9.     -v If given the -v (validate) option, sudo will update the user's timestamp, prompting for the user's password if necessary. This extends the sudo timeout for another 5
  10.       minutes (or whatever the timeout is set to in sudoers) but does not run a command.
  11.     -k The -k (kill) option to sudo invalidates the user's timestamp by setting the time on it to the epoch. The next time sudo is run a password will be required. This option
  12.       does not require a password and was added to allow a user to revoke sudo permissions from a .logout file.
  13.     -K The -K (sure kill) option to sudo removes the user's timestamp entirely. Likewise, this option does not require a password.
  14.     -b The -b (background) option tells sudo to run the given command in the background. Note that if you use the -b option you cannot use shell job control to manipulate the
  15.       process.
  16.     -p The -p (prompt) option allows you to override the default password prompt and use a custom one. The following percent (‘%') escapes are supported:
  17.       %u   expanded to the invoking user's login name
  18.       %U   expanded to the login name of the user the command will be run as (defaults to root)
  19.       %h   expanded to the local hostname without the domain name
  20.       %H   expanded to the local hostname including the domain name (on if the machine's hostname is fully qualified or the fqdn sudoers option is set)
  21.       %%   two consecutive % characters are collaped into a single % character
  22.     -c The -c (class) option causes sudo to run the specified command with resources limited by the specified login class. The class argument can be either a class name as
  23.       defined in /etc/login.conf, or a single '-' character. Specifying a class of - indicates that the command should be run restricted by the default login capabilities for
  24.       the user the command is run as. If the class argument specifies an existing user class, the command must be run as root, or the sudo command must be run from a shell
  25.       that is already root. This option is only available on systems with BSD login classes where sudo has been configured with the --with-logincap option.
  26.     -a The -a (authentication type) option causes sudo to use the specified authentication type when validating the user, as allowed by /etc/login.conf. The system administra­
  27.       tor may specify a list of sudo-specific authentication methods by adding an "auth-sudo" entry in /etc/login.conf. This option is only available on systems that support
  28.       BSD authentication where sudo has been configured with the --with-bsdauth option.
  29.     -u The -u (user) option causes sudo to run the specified command as a user other than root. To specify a uid instead of a username, use #uid.
  30.     -s The -s (shell) option runs the shell specified by the SHELL environment variable if it is set or the shell as specified in passwd(5).
  31.     -H The -H (HOME) option sets the HOME environment variable to the homedir of the target user (root by default) as specified in passwd(5). By default, sudo does not modify
  32.       HOME.
  33.     -P The -P (preserve group vector) option causes sudo to preserve the user's group vector unaltered. By default, sudo will initialize the group vector to the list of groups
  34.       the target user is in. The real and effective group IDs, however, are still set to match the target user.
  35.     -r The -r (role) option causes the new (SELinux) security context to have the role specified by ROLE.
  36.     -t The -t (type) option causes the new (SELinux) security context to have the have the type (domain) specified by TYPE. If no type is specified, the default type is derived
  37.       from the specified role.
  38.     -S The -S (stdin) option causes sudo to read the password from standard input instead of the terminal device.
  39.     -- The -- flag indicates that sudo should stop processing command line arguments. It is most useful in conjunction with the -s flag.


How's that?
"It's always a long day, 86,400 won't fit into a short."
  • joebert
  • Sledgehammer
  • Genius
  • No Avatar
  • Joined: Feb 10, 2004
  • Posts: 13458
  • Loc: Florida
  • Status: Offline

Post January 23rd, 2008, 9:11 pm

Man, I was way off in thinking only one person should be able to use it.
Maybe it would be better to think of it as if only one person could configure it.

Also, I just learned somthing else new. It's a bad idea to chown /etc/sudoers to root:yourgroup so you can look at it.
Quote:
sudo: /etc/sudoers is owned by gid 1000, should be 0


// Edit -- A very bad idea. Looks like I'm borrowing a monitor tomarrow.
Strong with this one, the sudo is.
  • Anonymous
  • Bot
  • No Avatar
  • Joined: 25 Feb 2008
  • Posts: ?
  • Loc: Ozzuland
  • Status: Online

Post January 23rd, 2008, 9:11 pm

Post Information

  • Total Posts in this topic: 26 posts
  • Users browsing this forum: No registered users and 73 guests
  • You cannot post new topics in this forum
  • You cannot reply to topics in this forum
  • You cannot edit your posts in this forum
  • You cannot delete your posts in this forum
  • You cannot post attachments in this forum
 
cron
 

© 2011 Unmelted, LLC. Ozzu® is a registered trademark of Unmelted, LLC.