root password
in [Setup]
|
From: Arno on 8 Jul 2010 21:26 The Natural Philosopher <tnp(a)invalid.invalid> wrote: > Arno wrote: >> jny0 <jny0(a)hotmail.com> wrote: >>> I'm installing fedora12. I run the CD, which gives me the option to >>> log-in as liver system user. I then lick on the Install to Hard Drive >>> icon, which begins the installation procedure. After setting up a >>> couple of settings (location, etc) I'm asked to enter a root >>> password. I enter it, and continue the installation. Oncompletion, I >>> restart the computer, and am prompted to set up a user account. I >>> then log in with the user account, as this is the only option >>> available. When I then try to login as root (through a terminal), I >>> keep being told that there's authentication failure. I know the >>> password is correct, and have gone though this process many time now. >>> Any ideas? >> >> Some people think that log-in as root is a security risk. >> >> I have been active in the security field for quite some time, >> and I still do not follow the reasoning behind this. In fact, >> it strikes me as the wrong thing to do, because at least I >> am far more careful with my root accounts than with the >> user accounts and to create that mind-set reliably, I need >> an original root log-in. I also believe allowing ssh >> remote root log-in causes less risk than denying it and >> going the su way. >> >> That said, Fedore12 does not agree and forces you to >> log in as user and then do a su. >> >> Arno > I think the reasoning is that typouing su <command> is less likely to > destroy a system than someone who forgets they are root and types > something deeply destructive like rm -r * whilst in /etc when they > thought they were in /home/user/myjunk Hmm. Possibly. That is why I have a clearly different root-prompt and blue background in root-xterms (instead of black). Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Arno on 8 Jul 2010 21:31 Doug Freyburger <dfreybur(a)yahoo.com> wrote: > The Natural Philosopher wrote: >> Arno wrote: >> >>> Some people think that log-in as root is a security risk. >>> >>> I have been active in the security field for quite some time, >>> and I still do not follow the reasoning behind this. In fact, >>> it strikes me as the wrong thing to do, because at least I > One reason is the encryption used during login sessions is stronger than > the encryption used to establish sessions. If you want to snif a > network and crack it you're more able to do so at the point of the > weaker encrypton. That sounds like complete BS to me. And it does not cover console logins at all. Maybe there is a misunderstanding here. Care to elaborate or give a reference? > It turns out this is a very weak argument. Most cracks are done using > bugs in programs than by cracking passwords. Sniffing password is the > *result* of cracking not the method of cracking much of the time. >>> am far more careful with my root accounts than with the >>> user accounts and to create that mind-set reliably, I need >>> an original root log-in. I also believe allowing ssh >>> remote root log-in causes less risk than denying it and >>> going the su way. >>> >>> That said, Fedore12 does not agree and forces you to >>> log in as user and then do a su. >> >> I think the reasoning is that typouing su <command> is less likely to >> destroy a system than someone who forgets they are root and types >> something deeply destructive like rm -r * whilst in /etc when they >> thought they were in /home/user/myjunk > It's a valid disagreement. I wonder if Arno's security work makes him > more cautious with a root session. It definitely does. I have immediately obvious different prompts and a different color background in root xterms. > I've seen a lot of folks login as > root because that's how they login and they damage their hosts all the > time. I've seen folks specifically chose to login as root as Arno > describes and do just fine. But like NP I have ended up prefering the > su route. For that matter doing sudo a command at a time when root is > absolutely needed is even more careful and less likely to damage the > system. It's also a pain in the butt to handle directories that have > resticted permissions. Well. Seems to be a matter of personal preference and work-style. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Arno on 8 Jul 2010 21:32 Matt Giwer <jull43(a)tampabay.rr.com> wrote: > On 07/05/2010 10:55 AM, jny0 wrote: >> I'm installing fedora12. I run the CD, which gives me the option to >> log-in as liver system user. I then lick on the Install to Hard Drive >> icon, which begins the installation procedure. After setting up a >> couple of settings (location, etc) I'm asked to enter a root >> password. I enter it, and continue the installation. Oncompletion, I >> restart the computer, and am prompted to set up a user account. I >> then log in with the user account, as this is the only option >> available. When I then try to login as root (through a terminal), I >> keep being told that there's authentication failure. I know the >> password is correct, and have gone though this process many time now. >> Any ideas? > Remote login as root is a bad idea for security reasons. Why? I have heard the claim frequently, but not a single conlusive explanation so far. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno(a)wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
From: Aragorn on 10 Jul 2010 04:06 On Tuesday 06 July 2010 11:26 in comp.os.linux.setup, somebody identifying as jny0 wrote... > ...and I'm a vege... > > What I meant by "It might be nice to negate this process if it can be > done..." is that it would be nice if I could just login as root, > rather than login in as a user, and su to root. Direct root logins are a security hazard, because the name "root" is known to exist in all UNIX systems, so all an attacker needs to guess next is the root password. If however you're using an unprivileged account to log in, an attacker would have to guess the account's login *and* its password, *plus* the root password for using "su" - which is of course negated if your account has "sudo" privileges, but then typing the correct password may still be difficult for the attacker, since they typically use automated dictionary or brute force attacks, and this fires off passwords and logins so fast that they may miss which one actually got them in. That all said, whether root can log in or not is usually determined via "/etc/securetty". That file contains a list of the consoles/terminals from which root is allowed to log in. If they are commented out, just remove the "#" at the beginning of the line for any given terminal and then root will be able to log in on that terminal. -- *Aragorn* (registered GNU/Linux user #223157)
From: Nico Kadel-Garcia on 10 Jul 2010 04:53
On Jul 10, 4:06 am, Aragorn <arag...(a)chatfactory.invalid> wrote: > On Tuesday 06 July 2010 11:26 in comp.os.linux.setup, somebody > > identifying as jny0 wrote... > > ...and I'm a vege... > > > What I meant by "It might be nice to negate this process if it can be > > done..." is that it would be nice if I could just login as root, > > rather than login in as a user, and su to root. > > Direct root logins are a security hazard, because the name "root" is > known to exist in all UNIX systems, so all an attacker needs to guess > next is the root password. If however you're using an unprivileged > account to log in, an attacker would have to guess the account's login > *and* its password, *plus* the root password for using "su" - which is > of course negated if your account has "sudo" privileges, but then > typing the correct password may still be difficult for the attacker, > since they typically use automated dictionary or brute force attacks, > and this fires off passwords and logins so fast that they may miss > which one actually got them in. > > That all said, whether root can log in or not is usually determined > via "/etc/securetty". That file contains a list of the > consoles/terminals from which root is allowed to log in. If they are > commented out, just remove the "#" at the beginning of the line for any > given terminal and then root will be able to log in on that terminal. It's also modified by "/etc/ssh/sshd_conmfig", which can be set to permit or deny remote root logins via SSH. Channeling root access through user accounts by blocking remote login with it, or enforcing the use of sudo, also provides some accounting of who came in as root and when in the system logs. A remote root access coming in through a NAT gateway at a big site, well, no one can tell who that really was logged in as root when the system crashed. But with sudo logging, or even with forcing people to su locally, you get a hint of whose account jumped up to root access and did something. This can be very handy in a multi-user system. |