LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   sudo safety (https://www.linuxquestions.org/questions/linux-newbie-8/sudo-safety-4175485871/)

Fred Caro 11-25-2013 07:57 PM

sudo safety
 
system (peppermint) uses sudo but I was daft enough to do:

sudo groupmod -G <me> <another_group>

(should have preserved sudo priv with -a)

From live cd using chroot did:

# groupmod -o -g 1000 sudo

I have sudo priv back but is this security risk?

Fred.

Kustom42 11-26-2013 01:20 PM

I am really confused by what you did. I have never seen a -G switch for any version of groupmod. There is a lower case, -g where you can specify the numerical ID of a group instead of a name but all this really does is rename a group. How in any way would it have affected sudo?

It is possible that you changed the group name that existed in your sudoers file and then lost your sudo access, but all you would need to do in that case is rename the group back to its original name.


What are the contents of your /etc/group and /etc/sudoers?

Fred Caro 11-28-2013 05:48 PM

sudo safety
 
Kustom42,
thanks. Sorry made mistake in question, I ran usermod not groupmod and missed the -a to preserve the primary group memberships and add secondary memberships with the -G option.
results from asked for files are as follows:

Hope that worked.

Note that my id output mow reads:

uid=1000(patti) gid=1000(sudo) groups=1000(sudo),1003(project)

Me being "patti".

What I basically did was try to create a folder with exclusive users, i.e., set group id to a folder with users. I am the only "sudoer" but my primory rights were striped when I forgot to add -a to the usermod command.
I got them back by chroot from a live cd, when I added myself to the group 'sudo'.
I wondered if this was a security risk?

Fred.

PTrenholme 11-29-2013 12:18 AM

I'm still somewhat puzzled by your id output. If I read what you posted, you just renamed the "patti" group to "sudo." That, by itself, should have made no change, whatsoever, in anything since the numeric value, not the display name, is what is used by the kernel.

Typically what one does is edit /etc/sudoers to change access settings. Here, for example, is my setup on my one-user system:
Code:

$ id
uid=1000(Peter) gid=1000(Peter) groups=1000(Peter),10(wheel),500(peter) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
$ sudo egrep '(wheel)|([Pp]eter)' /etc/sudoers
## Allows people in group wheel to run all commands
#%wheel ALL=(ALL)      ALL
%wheel  ALL=(ALL)      NOPASSWD: ALL

Warning: The use of the NOPASSWD option on a multi-user system is a real security risk.

Oh, if you're interested, the peter group is there because I (at one time) dual-booted Ubuntu, and Ubuntu did not allow user names to start with upper case letters, and restricted system ids to [0..499]. That setting allowed me to access the Ubuntu partition(s) more easily.)

In any case, if you're the only member of the group with gid=1000 (no matter what you named it), then your security concerns are unchanged by the change of the group's name.

Fred Caro 11-30-2013 04:10 PM

Sudo safety
 
1 Attachment(s)
PTrenholme,
thanks for your reply, I too am puzzled.
My /etc/sudoers file contains:- will have to paste it:
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

#########################################################################

I tried your egrep command but it (different names of course) returned nothing. Perhaps because I am no longer a member of admin?

Shortened version of /etc/group:

rtkit:x:122:
snort:x:123:
joe:x:1001:
sue:x:1002:
project:x:1003:joe,sue,patti
###########################################################################
and id for sudo:
id: sudo: No such user
############################################################################

At least other users all have different id numbers.
id for root returns "uid=0(root) gid=0(root) groups=0(root)"
Which begs the question of where is root on a sudo system? But that is an aside.
If user and group "patti" =1000 and group "sudo" =1000 then anyone joining group "patti" will have sudo privaleges but you might have assumed that you would have to join group "sudo" to do that. Does that make any sense?

Fred.

PTrenholme 12-03-2013 04:54 PM

There is no reason that the gid needs to be equal to the uid of a user. The two sets of numbers are, essentially, independent. By convention when a new user is created, that user is assigned the "next available" uid and a group, with the same name as the new user's user name, is created with a gid equal to the new user's uid. But both of those conventions do not need to be followed when the user is created.

From what you've shown, above, you have deleted (or renamed) the default "patti" group, and now have a sudo group of which "patti" is a member. Since the sudo group has the same gid that the default patti group would have had, and the patti group is not listed, it seems likely that you just renamed the default patti group to sudo.

Now the sudoers file you posted assigns permissions by name, not number, so any member of the sudo group will have permission to run an unrestricted sudo command. But, if you are the only member of that group, and you're the system administrator, there is no additional risk (or benefit) you incurred by renaming your personal group to sudo.

I.e., I believe you neither gained nor lost anything by renaming your personal group to sudo instead of just adding yourself to the sudoers file.

However, if you add anyone else to the sudo group, then you will incur a major security risk. Not only will that new group member be able to run any command using sudo, that person will also have access to almost every file in /home/patti, since those files, by default, will have been created with rw permission to all members of the group with gid=1000.

<edit>
By the way, there is no restriction on the number of groups of which a person may be a member. See the gpasswd and newgrp commands for details of managing group membership.
</edit>

Fred Caro 12-04-2013 04:05 PM

Sudo safety
 
PTrenholme,
thanks, that's a great explaination and mostly clears things up.
I wanted a quick fix using chroot and had lost membership of the admin group but from what you say (and output of /etc/sudoers) I would have been better editing /etc/sudoers.d and rejoining the 'admin' group from chroot?

Fred.

wstewart90 12-05-2013 02:48 AM

You should have only needed to add yourself back to the sudo group the same way you deleted yourself. By using usermod with the -aG flags. If the patti group is still in the /etc/group file then I would recommend changing the sudo group to an unused gid and just adding yourself to that group and any other secondary groups you may have deleted yourself from. If this is just a personal computer, that only you log onto then there's no real risk but personally, I'm picky about my stuff being configured a certain way.

Fred Caro 12-06-2013 07:08 PM

wstewart90,
it seems to me that, since my primary group is now sudo, I would loose sudo use if I changed the sudo gid number and then be unable to add myself to the admin group?

Fred.

PTrenholme 12-07-2013 12:25 PM

So, add yourself to the admin group before you make the change. To reiterate: There is no (practical) limit to the number of groups of which you (or anyone) can be a member.


All times are GMT -5. The time now is 02:58 PM.