tip: disable root and gain su/sudo with no password

z4ziggy · 2004-10-18 17:23:55

disable root and gain su/sudo with no password

after my previous post about local security (http://bbs.archlinux.org/viewtopic.php?t=7509) and the informative replies, i searched a bit further into the subject and learned it might be more secure, since root will be disabled thus will prevent hackers from ever gaining root control on your pc - via the net. from local security point of view, disabling root and allowing su/sudo with no password achieves same level of security since :

1. user password strength is same as root's password, and one must 1st login inorder to use su/sudo
2. root password will be disabled - thus anyone who will try login using root user will get denied... this will require anyone who wants to login to be familiar with the user name prior...
3. once local security is compromised, a root password is meaningless if a live-cd (etc) is in hands, or as a wise user added - a baseball bat...

anyway, to achieve this behavior one should do the followings :

1. allow user to sudo :
a. /etc/sudoers : add "<user> <machine_name/ALL>=(ALL) ALL". must use visudo to edit. example :

  > visudo
  #allow user ziggy sudo from local machine only (machine name = HOSTNAME in rc.conf):
  ziggy   my_machine_name=(ALL) ALL
  #allow user arch sudo from anywhere (local/net):
  arch    ALL=(ALL) ALL

2. disable root and gain su/sudo with no password :
a. add group 'wheel' to installed accounts:

    usermod -G wheel <user_which_will_use_su>

b. allow members of 'wheel' group to use su (it will be passwordless since root will be disabled) by adding the following line to BOTH /etc/pam.d/su & /etc/pam.d/sudo :

    auth           sufficient      pam_wheel.so trust use_uid

c. to allow wheel users login via local ONLY, add the following line to /etc/security/access.conf :

    -:wheel:ALL EXCEPT LOCAL

d. disable the root account by changing the 2nd field ('x') to space (' ') for user root in /etc/passwd.

---
hope someone might find this usefull too
z4ziggy

hcman · 2004-10-18 18:19:15

1. Consider, using a traditional system:
- I have user passwd: I now need another passwd to execute root commands.
- I have root passwd: situation is the same as you describe.

2. If you have a strong password, what's the problem? Besides you can disallow root logins for ssh and if your box is otherwise secure there isn't much of a problem.

3. All software security becomes useless when faced with a baseball bat :-)

I get the impression you get tired of typing root's passwd eh?

Arjan

phrakture · 2004-10-18 18:29:53

here's the thing - if i'm trying a brute-force method I do the following:
login as "root", try password, fail and try another password, etc etc...
if root is disabled, not only am i required to bruteforce the password, but also the username - effectively doubling the time required. seeing as dictionary attacks are almost useless if you follow proper *nix username/password guidelines - this could take ages, and you arent even guarenteed a wheel group login.
now disable remote su/sudo and you get the following:

remote root access is disabled (almost the same as disabling ssh root login, yet the user can still su/sudo if a login is gained)
local root access is disabled, which you do not have using the ssh method

I think this is an interesting trick for vamping up local (physical) security, but you could always just lock the machine up - in public places, this may be a good idea....

if you're only concerned about remote root logins, don't do this - deny root login through ssh...

hcman · 2004-10-18 18:49:10

Dunno much about bruteforcing passwords but if if bruteforcing a decent password takes long, is the added value of this of much significance?

Arjan

z4ziggy · 2004-10-18 18:53:35

be hold of the all mighty power basebell bat...

yes, as hcman mentioned - i got tired of typing my root's pass every time... its useless! from local security point of view, once a user has access to the machine, he can do whatever - starting from using grub to boot kernel in single mode to booting a live cd or as we all like to think - using the all mighty basebell bat... so protecting root from local attacks is useless. however, as phrakture stated, its the networking doors which should be kept closed (ive edited the 1st post to show how, using /etc/security/access.conf).

regarding the brute-force - thats the idea this actually gives more security if someone is trying to hack the pc locally by guessing root's password (without using live-cd, etc), although, as mentioned earlier, local security by usual means (ie, root password) is useless...

phrakture · 2004-10-18 19:03:32

i agree that it's nice for local security.... the next trick would be to deny physical access to the hardware - except keyboard/mouse/monitor and maybe a cd rom which cannot be booted from (some BIOSes support shutting this off - or just put HDD before cdrom in the boot order)... then password the bios and lock the tower in a cage....
physical securtity wins this round, unless it's playing against bolt cutters or something

cactus · 2004-10-19 04:23:44

or, use selinux, and post your root user/pass on the net.
Watch people get all silly with it...and be able to do nothing. People actually try root kits...um...you already have root! *gasp*

selinux really rocks. I wish I knew how to use it well enought to put it into something production oriented.
The guy that handed out root access (but not selinux policy setting access) to his box is one of the guys working on selinux.
Can't recall his name offhand....

zeppelin · 2004-10-19 09:54:45

someone WIKI WIKI it!

kth5 · 2004-10-19 12:23:03

i don't feel safe running selinux (NSA *uck*) nor letting certain users su passwordless. here's what i did:

1) set up my production box (using arch of course)
2) set up another GNU/Linux on a seperate partition, still leaving space for a copy of the 1st (backup)
3) installed vserver tools [1]
4) applied KBrown's patches [2] to 2.4.27 which includes grsec & vserver support
* logs any command executed
* no executable stack
* and some genereic exploit detection things
5) no icmp & input traffic via iptables on host server
6) syslog & ssh (non-standard port above 16000) runs on the host server which boots and surveils the vserver
7) the vserver runs everything else (+ ssh on 22 ) but syslog w/ root disabled completely
8) disabled all getties on hostserver
9) pwd protected bios and boot from 1st HDD only

i must say that both run on the same ip an share the "port-space". and just because u can't scan here it's nearly impossible to find out where to do *real* damage using the hostserver.
additionally logs can be audited from the outside, never visible from the inside of the vserver.

unfortunately this is a bit like m$ is doing it: security through obscurity. oh, and this thing is not meant as a desktop system, that is because local sockets are denied for users in certain groups which prevents for example X11 from working.

[1] http://linux-vserver.org
[2] http://www.sandino.net/parches/vserver/

z4ziggy · 2004-10-19 13:57:39

whow, thats a nice and heavy duty configuration...

what u r doing is too hardcore for me :oops:
im still just a newie trying to find the correct path to walk in the linux world... but im gonna google now for KBrown's patches...

btw - bios password is useless too - u have defaults passwords u can override the password, or remove the battery and other ways...

kth5 · 2004-10-19 14:13:19

z4ziggy wrote:

but im gonna google now for KBrown's patches...

i posted the link in[2].

z4ziggy wrote:

btw - bios password is useless too - u have defaults passwords u can override the password, or remove the battery and other ways...

true, but think of it this way: whenever someone gets by the bios protection he will most likely have to reboot the machine. since no automated user-process should ever do that you can expect that the machine was compromised by someone. that is if you didn't reboot the machine by yourself. *hinthint*

cactus · 2004-10-20 02:16:17

Well, as for it being NSA, here are some additional points.

It started out as a project internal to NSA, kinda. It was a joint effort with Trustix (I think that is the one) working on the Fluke system. Fluke was a specification system..Not sure if it was ever fully implemented. Then they and they ported it to Flask (might be the other way, can't recall...i get fluke and flask mixed up).
Trustix (again, not sure about the name..might be recalling wrongly) got the patent on something called "Type Enforcement". It is basically a permissions engine that ties into kernel space. They decided to play nice with it, and basically promise (contractual most likely) the NSA to hold the patent on their behest, and allow anyone to use it (just patent it so that nobody else could, and then keep them from using it...at least this is my understanding).

Then the NSA began patching the linux kernel with the type enforcement stuff, implementing mandatory access controls in Linux. This was a stack on top of linux's existing discretionary access controls. It worked much like iptables. Permissions went from top to bottom (discretionary to mandatory), and if they reached an impasse, they were denied. If they were accepted by everything, then the kernel would reply to the request.

Well, they presented this all at some big conference, and the kernel devs decided they wanted it in 2.6. They called it the LSM (linux security module). The LSM was basically a framework, and a series of kernel hooks, that allowed you to stack an arbitrary permission engine on top of it.
SE-Linux can be used, as well as others (LIDS for instance). In fact, you can even stack SELinux on LIDS on SELInux if you so desired (man, think of the administration overhead though..lol). Permissions still are "fall-through", with discretionary being on the top most layer at all times. If regular permissions (discretionary) don't allow access (like no read bit set), then no need to go further.

Well, that is my current understanding of the beast. I did quite a bit of research into it for my undergrad work, but it was when SELinux was still in a great deal of flux. It was before 2.6 was out, and the LSM hadn't even been finalized.

Cool stuff nonetheless. Someday I should really pick it back up and start working on studying the access control matricies. One of my fellow students basically mathematically proved that the resultant matricies were decidable, and discreet (finite). Good stuff to know when talking about computability of things, and how "complete" a mathematical model is. It was over my head, but at least I could appreciate what he was telling me.

Eeeek. sorry for the long post. Like I said, some of the stuff in the beginning might be mixed up a bit. It has been a while since I did my research, and much new info has come in and replaced what was in the two bit fifo buffer that is my brain!

phrakture · 2004-10-20 14:46:08

wow, great post +++karma (he he)

LB06 · 2005-04-15 04:54:06

Is it also possible to completely disable su'ing to root instead of making it passwordless? Just like they did with Ubuntu. I mean, what if someone who is not in wheel and therefore not authorised to become root/sudo? Can't this user just su to root with root having an empty password?

z4ziggy · 2005-04-15 05:31:31

yes he can, but its been discussed to death how much "local" security is usable (the well known "baseball bat" technique). u can do same as ubuntu - check their forums for exact instructions.

Moo-Crumpus · 2005-04-29 06:04:03

LB06 wrote:

Is it also possible to completely disable su'ing to root instead of making it passwordless? Just like they did with Ubuntu. I mean, what if someone who is not in wheel and therefore not authorised to become root/sudo? Can't this user just su to root with root having an empty password?

You can by changing /etc/pam.d/su from

# Uncomment the following line to implicitly trust users in the "wheel" group.
auth        sufficient    pam_wheel.so trust use_uid

to

# Uncomment the following line to implicitly trust users in the "wheel" group.
# auth        sufficient    pam_wheel.so trust use_uid

and by console command

sudo passwd -l root

Result:
wheel users are no longer trusted to do su without a password. As root's password is deleted, you can't su. There is still the possibility to type

sudo su

to enter a root session.

Hm, I think it could be worth a wiki section ...

Kern · 2005-04-29 09:49:59

ignoring attempts to protect against illicit local access/control, on the baseball bat principles etc.

a lot of problems arise from running services that allow limited external access to a box, like running a webserver, ftp, private filespace etc

all the password protection in the world wont protect you from a service that has been found to be weak, and can be encouraged to drop a user into root shell by accident, or admin accidentaly allows users into unallowed areas.

Most Crackers start by exploring a system for vulnerabilities to exploit, rather than a direct access attack on root login.

eg, if users can check /etc/passwd . If this hasnt beed Shadowed, then its almost trivial to crack other user accounts, as the username list is available.
Its possible that root user has been stupid enough to use his own personal access password also as root password. once you have *any* other access, next step is to explore/elevate the privileges.

Maybe too much focus is spent on the Lock not enough on the gate or fence around it. Run Nessus against a box. see whats what.

Dunno much about bruteforcing passwords but if if bruteforcing a decent password takes long, is the added value of this of much significance?

Yes it is, should a password attack be chosen.
True Bruteforcing, aa ab ac ... aaaaab aaaaac is the long way around. Too long to be of any real use as the permutations are huge for anything but the simplest of passes, and then you are limited further by bandwidth limitations.

usually its a wordlist dictionary attack as most users take a name or word as a pass, not A4r6Y0uu3 types. If your the admin u should *ensure* that users choose a good pass. better still , issue one to them yourself.

but yes, as Phrakture said, if you have to guess a username, the task is much harder, squared i think, not doubled.
root is a known name, so in principle you only need a single wordlist. (known name) x (huge list) not (huge list) x (huge list)

"disable root and gain su/sudo with no password" looks good. added another layer of protection by removing a known name ie "root"

z4ziggy · 2005-04-30 09:23:55

wikied : Disable root password and gain su_sudo with no password

LB06 · 2005-04-30 11:48:07

Pink Chick wrote:

LB06 wrote:
Is it also possible to completely disable su'ing to root instead of making it passwordless? Just like they did with Ubuntu. I mean, what if someone who is not in wheel and therefore not authorised to become root/sudo? Can't this user just su to root with root having an empty password?
You can by changing /etc/pam.d/su from
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth        sufficient    pam_wheel.so trust use_uid
to
# Uncomment the following line to implicitly trust users in the "wheel" group.
# auth        sufficient    pam_wheel.so trust use_uid
and by console command
sudo passwd -l root
Result:
wheel users are no longer trusted to do su without a password. As root's password is deleted, you can't su. There is still the possibility to type
sudo su
to enter a root session.
Hm, I think it could be worth a wiki section ...

Hmm, I did the

sudo passwd -l root

part only. I found it on the Ubuntu fora/wiki. It works for me .

TheRaginAsian · 2005-05-01 22:42:28

After following the wiki guide if I attempt to "su" with my user account it will still ask for a password. It doesnt matter if I give it one or not it will not let me su. I had to use sudo to restore my root account is the only fix ive been able to use so far.

EDIT: NVM, I understand now, thanks a billion! I was about ready to calculate how many times I typed my root pw in per day... it was definetly going to be a carpel-tunel inducingly high numer!

stonecrest · 2005-05-08 03:14:45

Maybe it's just me but it seems that when you

usermod -G wheel <user_which_will_use_su>

it removes you from any other groups you were assigned. My user ended up getting removed from the audio group at some point during this process anyway.

LB06 · 2005-05-08 10:18:36

Yes, it should be: usermod -G wheel,(other,groups) <user>

z4ziggy · 2005-05-16 18:00:59

sorry for that, will fix this asap with the following :

USERNAME=<user_which_will_use_su>; usermod -G wheel,`id -Gn $USERNAME | sed 's/ /,/g'` $USERNAME

unless someone has a simpler fix.

Arch Linux

#1 2004-10-18 17:23:55

tip: disable root and gain su/sudo with no password

#2 2004-10-18 18:19:15

Re: tip: disable root and gain su/sudo with no password

#3 2004-10-18 18:29:53

Re: tip: disable root and gain su/sudo with no password

#4 2004-10-18 18:49:10

Re: tip: disable root and gain su/sudo with no password

#5 2004-10-18 18:53:35

Re: tip: disable root and gain su/sudo with no password

#6 2004-10-18 19:03:32

Re: tip: disable root and gain su/sudo with no password

#7 2004-10-19 04:23:44

Re: tip: disable root and gain su/sudo with no password

#8 2004-10-19 09:54:45

Re: tip: disable root and gain su/sudo with no password

#9 2004-10-19 12:23:03

Re: tip: disable root and gain su/sudo with no password

#10 2004-10-19 13:57:39

Re: tip: disable root and gain su/sudo with no password

#11 2004-10-19 14:13:19

Re: tip: disable root and gain su/sudo with no password

#12 2004-10-20 02:16:17

Re: tip: disable root and gain su/sudo with no password

#13 2004-10-20 14:46:08

Re: tip: disable root and gain su/sudo with no password

#14 2005-04-15 04:54:06

Re: tip: disable root and gain su/sudo with no password

#15 2005-04-15 05:31:31

Re: tip: disable root and gain su/sudo with no password

#16 2005-04-29 06:04:03

Re: tip: disable root and gain su/sudo with no password

#17 2005-04-29 09:49:59

Re: tip: disable root and gain su/sudo with no password

#18 2005-04-30 09:23:55

Re: tip: disable root and gain su/sudo with no password

#19 2005-04-30 11:48:07

Re: tip: disable root and gain su/sudo with no password

#20 2005-05-01 22:42:28

Re: tip: disable root and gain su/sudo with no password

#21 2005-05-08 03:14:45

Re: tip: disable root and gain su/sudo with no password

#22 2005-05-08 10:18:36

Re: tip: disable root and gain su/sudo with no password

#23 2005-05-16 18:00:59

Re: tip: disable root and gain su/sudo with no password

Board footer