[gentoo-user] Permissions of /etc/sudoers

[gentoo-user] Permissions of /etc/sudoers

[Stroller]

Hi there,

I'm just in the process of setting up my lovely new system :D, in the  
very first post-install steps.

I install sudo, give my user wide sudo rights and then set  
"PermitRootLogin no" in /etc/ssh/sshd_config.
(Critique of this measure welcomed).

Anyway, as root I started to edit /etc/sudoers and vim complained  
"editing a read-only file".

Sure enough, /etc/sudoers has permissions 440, so I had to `chmod 640 / 
etc/sudoers` before editing it & changing it back.

I am sure I did not have to do this last time I installed a system,  
although that would have been at least a couple of years ago.

Obviously /etc/sudoers is a security-critical file and one wishes to  
prevent attackers from editing it, but surely if a file belongs to  
root there's not much point (??) in preventing root from writing to  
it, because root can always change the permissions and edit the file,  
just as I have done.

I see from some Googling that sudo complains if the permissions on  
this file are greater than 4xx - can anyone explain why, please?

I'm sure there is something I am not understanding, but my naive  
analysis suggests the only reason for this behaviour is to  
inconvenience administrators!

Stroller.

Re: [gentoo-user] Permissions of /etc/sudoers

[Michael Hentsch]

Stroller schrieb:
> Hi there,
>
> I'm just in the process of setting up my lovely new system :D, in the 
> very first post-install steps.
>
> I install sudo, give my user wide sudo rights and then set 
> "PermitRootLogin no" in /etc/ssh/sshd_config.
> (Critique of this measure welcomed).
>
> Anyway, as root I started to edit /etc/sudoers and vim complained 
> "editing a read-only file".
The file /etc/sudoers should always be edited with visudo. visudo uses 
file locking, provides basic sanity checks and checks for parse errors.

>
> Sure enough, /etc/sudoers has permissions 440, so I had to `chmod 640 
> /etc/sudoers` before editing it & changing it back.

440 is ok.
>
> I am sure I did not have to do this last time I installed a system, 
> although that would have been at least a couple of years ago.
>
> Obviously /etc/sudoers is a security-critical file and one wishes to 
> prevent attackers from editing it, but surely if a file belongs to 
> root there's not much point (??) in preventing root from writing to 
> it, because root can always change the permissions and edit the file, 
> just as I have done.
>
> I see from some Googling that sudo complains if the permissions on 
> this file are greater than 4xx - can anyone explain why, please?
>
> I'm sure there is something I am not understanding, but my naive 
> analysis suggests the only reason for this behaviour is to 
> inconvenience administrators!
>
> Stroller.
>
>
>

Re: [gentoo-user] Permissions of /etc/sudoers

[b.n.]

Michael Hentsch ha scritto:
> The file /etc/sudoers should always be edited with visudo. visudo uses
> file locking, provides basic sanity checks and checks for parse errors.

This always made me crazy.

Why, why, why should I use a specialized editor to edit a system file?
It's not like we have vixorgconf, vifstab. You are welcome to edit these
files with any editor you like. Why is /etc/sudoers special?

m.

[gentoo-user] Re: Permissions of /etc/sudoers

[Nikos Chantziaras]

b.n. wrote:
> Michael Hentsch ha scritto:
>> The file /etc/sudoers should always be edited with visudo. visudo uses
>> file locking, provides basic sanity checks and checks for parse errors.
> 
> This always made me crazy.
> 
> Why, why, why should I use a specialized editor to edit a system file?
> It's not like we have vixorgconf, vifstab. You are welcome to edit these
> files with any editor you like. Why is /etc/sudoers special?

Because it needs to be checked for errors before you save it.

But visudo uses the editor specified in the EDITOR environment variable 
(a lot programs do; EDITOR for editing and VISUAL for viewing).  In 
/etc/env.d/99local, I have:

   EDITOR=kwrite

So here, visudo brings up KDE's text editor.

Re: [gentoo-user] Permissions of /etc/sudoers

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Thu, 12 Feb 2009 00:52:22 +0100, b.n. wrote:

> > The file /etc/sudoers should always be edited with visudo. visudo uses
> > file locking, provides basic sanity checks and checks for parse
> > errors.  
> 
> This always made me crazy.
> 
> Why, why, why should I use a specialized editor to edit a system file?
> It's not like we have vixorgconf, vifstab. You are welcome to edit these
> files with any editor you like. Why is /etc/sudoers special?

It's no more special than /etc/passwd, which should be edited with vipw.
And it's not a specialised editor, these are just wrappers that call
$EDITOR, so you end up using the same program to edit the files, but with
a safety net. Remember that some systems restrict root access, so a
fscked /etc/sudoers could lock you out.

It's not like you HAVE to use the wrapper either, there's nothing to stop
you using any editor you like, directly, and it's the best choice if you
want to be free to screw up the file. 


-- 
Neil Bothwick

Procedure: (n.) a method of performing a program sub-task in an
inefficient way by extensively using the stack instead of a GOTO.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Permissions of /etc/sudoers

[Stroller]

On 12 Feb 2009, at 00:01, Neil Bothwick wrote:
> ...  there's nothing to stop
> you using any editor you like, directly, and it's the best choice if  
> you
> want to be free to screw up the file.

It's the Unix way!

Stroller.

Re: [gentoo-user] Permissions of /etc/sudoers

[Paul Hartman]

On Wed, Feb 11, 2009 at 5:52 PM, b.n. <brullonulla@gmail.com> wrote:
> Michael Hentsch ha scritto:
>> The file /etc/sudoers should always be edited with visudo. visudo uses
>> file locking, provides basic sanity checks and checks for parse errors.
>
> This always made me crazy.
>
> Why, why, why should I use a specialized editor to edit a system file?
> It's not like we have vixorgconf, vifstab. You are welcome to edit these
> files with any editor you like. Why is /etc/sudoers special?

I guess an error in sudoers could allow the whole world to use sudo,
and someone decided to give this special cushion to this program and
none of the others that can also ruin your system in various other
ways. :)

Paul

Re: [gentoo-user] Permissions of /etc/sudoers

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Wed, 11 Feb 2009 18:01:36 -0600, Paul Hartman wrote:

> I guess an error in sudoers could allow the whole world to use sudo,
> and someone decided to give this special cushion to this program and
> none of the others that can also ruin your system in various other
> ways. :)

You could also lock yourself out, and some of the other files also have
editor wrappers.


-- 
Neil Bothwick

"Bother," said Christopher Robin, as Pooh got out the vaseline.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Permissions of /etc/sudoers

[Nikos Chantziaras]

Stroller wrote:
> I install sudo, give my user wide sudo rights and then set 
> "PermitRootLogin no" in /etc/ssh/sshd_config.
> (Critique of this measure welcomed).

Since Hung already answered about the other problem, I'll just comment 
on this.

It's a bad idea if the machine is open to the Internet, especially since 
it's easy to simply "su -" or "sudo" as a normal user.

Re: [gentoo-user] Re: Permissions of /etc/sudoers

[Heiko Wundram]

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

Am Montag 09 Februar 2009 13:37:31 schrieb Nikos Chantziaras:
> Stroller wrote:
> > I install sudo, give my user wide sudo rights and then set
> > "PermitRootLogin no" in /etc/ssh/sshd_config.
> > (Critique of this measure welcomed).
>
> Since Hung already answered about the other problem, I'll just comment
> on this.
>
> It's a bad idea if the machine is open to the Internet, especially since
> it's easy to simply "su -" or "sudo" as a normal user.

Sorry, but I consider that to be BS advice (at least concerning that you want 
to leave password-authentication open).

I'd always recommend disabling root login for ssh (as soon as that is 
possible, i.e. you have an unpriviledged account who is in group wheel who you 
can use to access the machine in question), because root is a "well-known" 
user (and thus lends itself well to a [possibly distributed] ssh brute force).

When someone wants to "hack" your machine, he's always going to try known 
usernames before going on to guess what "additional" (unpriviledged) usernames 
might have been set up on your system. And, even when he gets access to one of 
your user accounts (who happen to be in group wheel), he still has to guess 
the root password (when doing su -) to be able to become root, and hopefully 
this buys you the time to see in your logs that someone tried local "su" with 
invalid passwords, which should always be a high priority alert.

YMMV, but I've felt pretty safe (safer than leaving root open for password-
authentication) like this so far.

-- 
Heiko Wundram
Gehrkens.IT GmbH

FON 0511-59027953 | http://www.gehrkens.it
FAX 0511-59027957 | http://www.xencon.net

Gehrkens.IT GmbH
Strasse der Nationen 5
30539 Hannover

Registergericht: Amtsgericht Hannover, HRB 200551
Geschäftsführer: Harald Gehrkens, Daniel Netzer

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: Permissions of /etc/sudoers

[Nikos Chantziaras]

Heiko Wundram wrote:
> Am Montag 09 Februar 2009 13:37:31 schrieb Nikos Chantziaras:
>> Stroller wrote:
>>> I install sudo, give my user wide sudo rights and then set
>>> "PermitRootLogin no" in /etc/ssh/sshd_config.
>>> (Critique of this measure welcomed).
>> Since Hung already answered about the other problem, I'll just comment
>> on this.
>>
>> It's a bad idea if the machine is open to the Internet, especially since
>> it's easy to simply "su -" or "sudo" as a normal user.
> 
> Sorry, but I consider that to be BS advice (at least concerning that you want 
> to leave password-authentication open).
> 
> I'd always recommend disabling root login for ssh (as soon as that is 
> possible, i.e. you have an unpriviledged account who is in group wheel who you 
> can use to access the machine in question), because root is a "well-known" 
> user (and thus lends itself well to a [possibly distributed] ssh brute force).

Er, didn't I actually say the same?  If other people have network access 
to the machine, disable root.  You misunderstood something.

Re: [gentoo-user] Re: Permissions of /etc/sudoers

[Saphirus Sage]

On Feb 9, 2009, at 8:15 AM, Nikos Chantziaras <realnc@arcor.de> wrote:

> Heiko Wundram wrote:
>> Am Montag 09 Februar 2009 13:37:31 schrieb Nikos Chantziaras:
>>> Stroller wrote:
>>>> I install sudo, give my user wide sudo rights and then set
>>>> "PermitRootLogin no" in /etc/ssh/sshd_config.
>>>> (Critique of this measure welcomed).
>>> Since Hung already answered about the other problem, I'll just  
>>> comment
>>> on this.
>>>
>>> It's a bad idea if the machine is open to the Internet, especially  
>>> since
>>> it's easy to simply "su -" or "sudo" as a normal user.
>> Sorry, but I consider that to be BS advice (at least concerning  
>> that you want to leave password-authentication open).
>> I'd always recommend disabling root login for ssh (as soon as that  
>> is possible, i.e. you have an unpriviledged account who is in group  
>> wheel who you can use to access the machine in question), because  
>> root is a "well-known" user (and thus lends itself well to a  
>> [possibly distributed] ssh brute force).
>
> Er, didn't I actually say the same?  If other people have network  
> access to the machine, disable root.  You misunderstood something.
>
I'd just as soon leave the root account able to be logged in over SSH  
and remove password authentication in preference of a 2048-bit RSA  
key. Just use a script to add failed logins to a deny list. 

[gentoo-user] Re: Permissions of /etc/sudoers

[Nikos Chantziaras]

Saphirus Sage wrote:
> I'd just as soon leave the root account able to be logged in over SSH 
> and remove password authentication in preference of a 2048-bit RSA key. 
> Just use a script to add failed logins to a deny list.

I tend to forget that this isn't Debian, so yeah, that'll work ;D

Re: [gentoo-user] Re: Permissions of /etc/sudoers

[Heiko Wundram]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

Am Montag 09 Februar 2009 14:15:35 schrieb Nikos Chantziaras:
> Heiko Wundram wrote:
> > Am Montag 09 Februar 2009 13:37:31 schrieb Nikos Chantziaras:
> >> Stroller wrote:
> >>> I install sudo, give my user wide sudo rights and then set
> >>> "PermitRootLogin no" in /etc/ssh/sshd_config.
> >>> (Critique of this measure welcomed).
> >>
> >> Since Hung already answered about the other problem, I'll just comment
> >> on this.
> >>
> >> It's a bad idea if the machine is open to the Internet, especially since
> >> it's easy to simply "su -" or "sudo" as a normal user.
> ...
> Er, didn't I actually say the same?  If other people have network access
> to the machine, disable root.  You misunderstood something.

Err, no, you didn't say the same, at least not considering your quote (I 
didn't read the OP):

Reading the above, you said that "PermitRootLogin no" is a bad idea (i.e., 
disabling root login via SSH is a bad idea), whereas I said the exact opposite 
(and you meant the exact opposite).

But, as you meant the same as me, forget what I said or just take my rant as a 
clarification of your point. ;-)

-- 
Heiko Wundram
Gehrkens.IT GmbH

FON 0511-59027953 | http://www.gehrkens.it
FAX 0511-59027957 | http://www.xencon.net

Gehrkens.IT GmbH
Strasse der Nationen 5
30539 Hannover

Registergericht: Amtsgericht Hannover, HRB 200551
Geschäftsführer: Harald Gehrkens, Daniel Netzer

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: Permissions of /etc/sudoers

[Stroller]

On 9 Feb 2009, at 13:05, Heiko Wundram wrote:
> ... even when he gets access to one of
> your user accounts (who happen to be in group wheel), he still has  
> to guess
> the root password (when doing su -) to be able to become root, and  
> hopefully
> this buys you the time to see in your logs that someone tried local  
> "su" with
> invalid passwords, which should always be a high priority alert.

I have been using `sudo` over `su` for a long time because I felt it  
reduces the risk of staying too long logged in as root, doing  
something daft and damaging the system.

However I have now many times found myself typing `sudo` commands  
automatically & sometimes inattentively, so that would seem to  
undermine that argument.

Your point is very persuasive. I guess my remaining objection is that  
I have my .bashrc & .bash_profile just the way I like them, and using  
root would seem to require me to make any changes in two places.

Stroller.

[gentoo-user] Re: Permissions of /etc/sudoers

[Nikos Chantziaras]

Stroller wrote:
> 
> On 9 Feb 2009, at 13:05, Heiko Wundram wrote:
>> ... even when he gets access to one of
>> your user accounts (who happen to be in group wheel), he still has to 
>> guess
>> the root password (when doing su -) to be able to become root, and 
>> hopefully
>> this buys you the time to see in your logs that someone tried local 
>> "su" with
>> invalid passwords, which should always be a high priority alert.
> 
> I have been using `sudo` over `su` for a long time because I felt it 
> reduces the risk of staying too long logged in as root, doing something 
> daft and damaging the system.
> 
> However I have now many times found myself typing `sudo` commands 
> automatically & sometimes inattentively, so that would seem to undermine 
> that argument.
> 
> Your point is very persuasive. I guess my remaining objection is that I 
> have my .bashrc & .bash_profile just the way I like them, and using root 
> would seem to require me to make any changes in two places.

You can instruct sudo to ask for the target user's password instead of 
your own.  In this case, you can make to ask for root's password.  Look 
up "targetpw" in sudo's docs.  To make sudo ask for the target user's 
password by default, put this in /etc/sudoers:

  Defaults targetpw