Hello,
Consider two following cases:
1. On production systems on television stations, a sysadmin give teens (remaja group, age 13 and older) full administrator privileges by adding this line to sudoers:
%remaja ALL=(ALL:ALL) ALL
Rationale: Almost all programs on the system can only be run by teens as root.
2. On production systems on tobacco factories, a sysadmin also give adults (age 18 and older, dewasa group) full administrator privileges by adding this line to sudoers:
%dewasa ALL=(ALL:ALL) ALL
Also, the sudo lecture file configured in sudoers (/etc/sudo.lecture) contain the following:
WARNING: I BROKE MY SYSTEM BECAUSE OF SUDO. CUSTOMER SERVICE: ($a_random_phone_number)
Rationale: All programs on system can only be run by adults, because such programs might break system. However, instead of calling sysadmin when something breaks the system, adults can call customer service instead, which isn't qualified for system maintenance.
Based on above cases, is it OK to give group of random users full administrator privileges using sudo, by adding them to sudoers with ALL privileges? Should sudoers call customer service number instead of sysadmin when something breaks?
Cheers, Bagas
Le 16/08/2019 à 07:04, Bagas Sanjaya a écrit :
Based on above cases, is it OK to give group of random users full administrator privileges using sudo, by adding them to sudoers with ALL privileges?
Short answer : this is VERY wrong.
Cheers,
Niki
Why did you say it is wrong to give full admin privileges to random users?
On Fri, Aug 16, 2019 at 8:39 PM Bagas Sanjaya bagasdotme@gmail.com wrote:
Why did you say it is wrong to give full admin privileges to random users?
$ sudo rm -rf /
$ sudo <install keylogger of choice>
$ sudo cp /etc/{passwd,shadow} $home; (run john-the-ripper against passwd/shadow files).
etc etc etc.
On Aug 16, 2019, at 11:12 PM, John Pierce jhn.pierce@gmail.com wrote:
On Fri, Aug 16, 2019 at 8:39 PM Bagas Sanjaya bagasdotme@gmail.com wrote:
Why did you say it is wrong to give full admin privileges to random users?
$ sudo rm -rf /
I like this one. Long-long ago it was one of the “tricky” questions at the UNIX admin test (exam). Basically, no matter how devastating that may sound, the command only will remove what is (alphabetically it was that time) before /dev/[root_device]. Once the device root filesystem lives on is removed from /dev, no further damage is done. So, you will be able to mount drive on another machine and get your /etc, /home, /var, /usr/local intact ;-) Asking that question other people gave me (an them usually) a lot of fun.
Valeri
$ sudo <install keylogger of choice>
$ sudo cp /etc/{passwd,shadow} $home; (run john-the-ripper against passwd/shadow files).
etc etc etc.
-- -john r pierce recycling used bits in santa cruz _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Aug 17, 2019, at 9:25 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I like this one. Long-long ago it was one of the “tricky” questions at the UNIX admin test (exam). Basically, no matter how devastating that may sound, the command only will remove what is (alphabetically it was that time) before /dev/[root_device]. Once the device root filesystem lives on is removed from /dev, no further damage is done. So, you will be able to mount drive on another machine and get your /etc, /home, /var, /usr/local intact ;-) Asking that question other people gave me (an them usually) a lot of fun.
I’m not sure what UNIX systems where that’d actually happen, but on Linux systems, removing the device in /dev/ would not deter rm from being able to delete everything else on the mounted filesystems.
Certainly if you were using some sort of automount system, and the filesystems hadn’t unmounted, it would be fine.
-- Jonathan Billings billings@negate.org
On 2019-08-17 08:42, Jonathan Billings wrote:
On Aug 17, 2019, at 9:25 AM, Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
I like this one. Long-long ago it was one of the “tricky” questions at the UNIX admin test (exam). Basically, no matter how devastating that may sound, the command only will remove what is (alphabetically it was that time) before /dev/[root_device]. Once the device root filesystem lives on is removed from /dev, no further damage is done. So, you will be able to mount drive on another machine and get your /etc, /home, /var, /usr/local intact ;-) Asking that question other people gave me (an them usually) a lot of fun.
I’m not sure what UNIX systems where that’d actually happen, but on Linux systems, removing the device in /dev/ would not deter rm from being able to delete everything else on the mounted filesystems.
Certainly if you were using some sort of automount system, and the filesystems hadn’t unmounted, it would be fine.
Thanks, everybody, for confirming that on Linux
rm -rf /
does lead to devastating result. Just for fun I tried the same on FreeBSD (12.0 RELEASE - which is latest release):
root@point:/home/valeri # cd root@point:~ # whoami root root@point:~ # rm -rf / rm: "/" may not be removed
Somebody is really clever in this World ;-) Well, FreeBSD folks made my day (again!). Note, that that I did on my live workstation (yes, I did test it on throw-away system first ;-) - so I can copy and paste what I got to this email.
Valeri
-- Jonathan Billings billings@negate.org
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, Aug 29, 2019 at 10:25:50AM -0500, Valeri Galtsev wrote:
root@point:/home/valeri # cd root@point:~ # whoami root root@point:~ # rm -rf / rm: "/" may not be removed
Somebody is really clever in this World ;-) Well, FreeBSD folks made my day (again!). Note, that that I did on my live workstation (yes, I did test it on throw-away system first ;-) - so I can copy and paste what I got to this email.
GNU coreutils also has that feature, you can't run 'rm -rf /' there either, you need to run it with --no-preserve-root. This was added to Coreutils in 2003. Be careful in FreeBSD, if you have POSIXLY_CORRECT defined, it will let you rm -rf /.
On 2019-08-29 10:53, Jonathan Billings wrote:
On Thu, Aug 29, 2019 at 10:25:50AM -0500, Valeri Galtsev wrote:
root@point:/home/valeri # cd root@point:~ # whoami root root@point:~ # rm -rf / rm: "/" may not be removed
Somebody is really clever in this World ;-) Well, FreeBSD folks made my day (again!). Note, that that I did on my live workstation (yes, I did test it on throw-away system first ;-) - so I can copy and paste what I got to this email.
GNU coreutils also has that feature, you can't run 'rm -rf /' there either, you need to run it with --no-preserve-root. This was added to Coreutils in 2003. Be careful in FreeBSD, if you have POSIXLY_CORRECT defined, it will let you rm -rf /.
Yes, I know... and I'm far from "admiring foolproofness" of which there is none... as [on FreeBSD]
rm -rf /*
does remove everything but "immutable" files, directories,... You can not make anything fool proof (unless it is android that is actually not owned by that fool no matter that the fool thinks it does ;-)
Valeri
On Thu, Aug 29, 2019 at 6:05 PM Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On 2019-08-29 10:53, Jonathan Billings wrote:
On Thu, Aug 29, 2019 at 10:25:50AM -0500, Valeri Galtsev wrote:
root@point:/home/valeri # cd root@point:~ # whoami root root@point:~ # rm -rf / rm: "/" may not be removed
Sometimes the worst commands are those done not intentionally but due to human error or underestimation: I remember one time on 1994 I executed deltree from c:\ on a Win 3.1 system and I had to reinstall the box... perhaps a subliminal desire to install Linux... So coming back to the initial question you can give sudo for all and the user can be in / thinking to be in another directory and run a command like $$$$ sudo find . -type f -exec rm -f {} ; and the effects would not be nice at all Or he/she can create a script that executes a change directory and then remove/manipulate contents inside the destination directory and if he/she doesn't test the return code of the "cd" command, and then actually the removal actions will run from the current directory where the user is when running the script...
Just to give two examples not to give unlimited / uncontrolled power to anyone..
Gianluca
On Fri, Aug 16, 2019 at 10:13 PM John Pierce jhn.pierce@gmail.com wrote:
$ sudo rm -rf /
Just for fun, I cloned a C7 VM and ran rm -rf. I then examined the disk image with guestfish. Everything was gone except for a few empty directoriers: /dev, /etc, /proc, /sys, and so on.
Jim
On Aug 19, 2019, at 4:53 PM, James Szinger jszinger@gmail.com wrote:
Just for fun, I cloned a C7 VM and ran rm -rf. I then examined the disk image with guestfish. Everything was gone except for a few empty directoriers: /dev, /etc, /proc, /sys, and so on.
Yeah, rm can’t delete mountpoints and anything that was protected by a namespace mount (since they’re basically mountpoints too).
-- Jonathan Billings billings@negate.org
On Aug 15, 2019, at 11:04 PM, Bagas Sanjaya bagasdotme@gmail.com wrote:
Based on above cases, is it OK to give group of random users full administrator privileges using sudo, by adding them to sudoers with ALL privileges? Should sudoers call customer service number instead of sysadmin when something breaks?
sudo is a tool for expressing and enforcing a site’s policies regarding superuser privilege.
If your sudo configuration expresses and enforces those policies the way you want it to, then the configuration is correct. If it does not, then fix it.
sudo doesn’t tell you what your policies should be.
We can suggest policies to you, but not based only on the information you’ve just given us. To properly advise you, we’d need to know your threat models, the risk assessments, and more. In short, we’d have to become your system administrators.
On Aug 16, 2019, at 6:21 AM, Warren Young warren@etr-usa.com wrote:
On Aug 15, 2019, at 11:04 PM, Bagas Sanjaya bagasdotme@gmail.com wrote:
Based on above cases, is it OK to give group of random users full administrator privileges using sudo, by adding them to sudoers with ALL privileges? Should sudoers call customer service number instead of sysadmin when something breaks?
sudo is a tool for expressing and enforcing a site’s policies regarding superuser privilege.
If your sudo configuration expresses and enforces those policies the way you want it to, then the configuration is correct. If it does not, then fix it.
Incidentally, sudo stands for substitute user do. Meaning: executing something as a different user. I keep repeading it to proficient Linux users who sometimes need my help too, amazingly they all percieve it as a super user do, not as a substitute user do. Even though “man sudo” says in the first line: - execute a command as another user…
Just mentioning.
Valeri
sudo doesn’t tell you what your policies should be.
We can suggest policies to you, but not based only on the information you’ve just given us. To properly advise you, we’d need to know your threat models, the risk assessments, and more. In short, we’d have to become your system administrators. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On Fri, Aug 16, 2019 at 08:01:56AM -0500, Valeri Galtsev wrote:
On Aug 16, 2019, at 6:21 AM, Warren Young warren@etr-usa.com wrote:
On Aug 15, 2019, at 11:04 PM, Bagas Sanjaya bagasdotme@gmail.com wrote:
Based on above cases, is it OK to give group of random users full administrator privileges using sudo, by adding them to sudoers with ALL privileges? Should sudoers call customer service number instead of sysadmin when something breaks?
sudo is a tool for expressing and enforcing a site’s policies regarding superuser privilege.
If your sudo configuration expresses and enforces those policies the way you want it to, then the configuration is correct. If it does not, then fix it.
Incidentally, sudo stands for substitute user do. Meaning: executing something as a different user. I keep repeading it to proficient Linux users who sometimes need my help too, amazingly they all percieve it as a super user do, not as a substitute user do. Even though “man sudo” says in the first line: - execute a command as another user…
Just mentioning.
Valeri
Hear, hear, +1.
And if I may add, a similar comment may be applied to "su".
jl
-
Bagas Sanjaya -
Gianluca Cecchi -
James Szinger -
John Pierce -
Jon LaBadie -
Jonathan Billings -
Nicolas Kovacs -
Valeri Galtsev -
Warren Young