All--
su cannot be run without trusting the shell. The shell cannot be
trusted without trusting any instructions the shell uses, from library calls
to rc scripts. Hell, the instructions the shell uses can't even be trusted,
since they're all living in userspace memory.
By contrast, SSHD is generally a root owned, highly secure environment
with no unpriveledged userspace dependancies.
So: For what possible reason would I want to su to root, or any other
account, instead of simply authenticating with the correct UID in the first
place?
What comes to mind is the concept that only certain users might be
allowed to su to root, and that by forcing to users to log in as themselves,
an accounting of *who* went to root may be done. This seems to me an
instance where accounting is being valued higher than authorization--a
broken model, since a flaw in authorization will create misleading
accounting logs.
There are a couple solutions that allow us to retain such accounting,
and do it *securely*, but I'd like to achieve some kind of consensus that
depending on su causes root access to be dependent upon unpriveledged
security, and is thus something to be engineered against.
Yours Truly,
Dan Kaminsky, CISSP
www.doxpara.com
On Fri, 23 Feb 2001, Dan Kaminsky wrote:> So: For what possible reason would I want to su to root, or any other > account, instead of simply authenticating with the correct UID in the first > place?If you're bulk-installing systems for customers, it's nice to block root logins if they don't remember to change a default (/null) password. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Hi, On Fri, Feb 23, 2001 at 06:12:31PM -0800, Dan Kaminsky wrote:> su cannot be run without trusting the shell. The shell cannot be > trusted without trusting any instructions the shell uses, from library calls > to rc scripts. Hell, the instructions the shell uses can't even be trusted, > since they're all living in userspace memory. > > By contrast, SSHD is generally a root owned, highly secure environment > with no unpriveledged userspace dependancies.I can't really follow that reasoning. - su is a root owned, suid program, which is much smaller than sshd, so it is less prone to have errors - sshd needs to run a user shell after login, so the shell dependency is there as well. What am I missing? gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert.doering at physik.tu-muenchen.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> So: For what possible reason would I want to su to root, or any > other account, instead of simply authenticating with the correct UID > in the first place? > > What comes to mind is the concept that only certain users might be > allowed to su to root, and that by forcing to users to log in as > themselves, an accounting of *who* went to root may be done.This reminds me that there was some discussion a while ago about logging the fingerprint and/or comment associated with a key when that key was used to log in. Has anyone does this yet? If not, is there any reason it wouldn't be desired?> This seems to me an instance where accounting is being valued higher > than authorization--a broken model, since a flaw in authorization will > create misleading accounting logs.Not necesarily - if you're really paranoid about your logging (eg, you log to an ultra-secure remote host, or to a line printer, etc), then you can probablly be reasonably sure that you'll have good logs. Moreover, there are many business types who feel that things like due dilligence and liability (and hence good logging) are more important than actually protecting your machines and your data. I'm not one of theses people, but I've been employed by such people in the past.... -Jason --------------------------- If the Revolution comes to grief, it will be because you and those you lead have become alarmed at your own brutality. --John Gardner -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE6l5MGswXMWWtptckRAi+/AJsFm7GOCkyd1WIvkDLE9dLDp5DDigCfUehp b16o6xbKp9ycen1QEdmExUk=qJER -----END PGP SIGNATURE-----
On Fri, 23 Feb 2001, Dan Kaminsky wrote:> All-- > > su cannot be run without trusting the shell. The shell cannot be > trusted without trusting any instructions the shell uses, from library calls > to rc scripts. Hell, the instructions the shell uses can't even be trusted, > since they're all living in userspace memory. > > By contrast, SSHD is generally a root owned, highly secure environment > with no unpriveledged userspace dependancies. >hmm... Too many assuptions...> So: For what possible reason would I want to su to root, or any other > account, instead of simply authenticating with the correct UID in the first > place? > > What comes to mind is the concept that only certain users might be > allowed to su to root, and that by forcing to users to log in as themselves, > an accounting of *who* went to root may be done. This seems to me an > instance where accounting is being valued higher than authorization--a > broken model, since a flaw in authorization will create misleading > accounting logs. >A flaw in authorization in sshd could cause a user to login without root's password (see 2.3.1 OpenSSH bug). A flaw in the AES encryption could allow replay attacks like RC4. A flaw in a PAM module could allow a user to login with higher user rights. If there is a flaw in the authorization aspect of the OS. It may not be localized to just 'su' thus sshd provides no addition security unless it implements it's own authorization method independant of the OS.> There are a couple solutions that allow us to retain such accounting, > and do it *securely*, but I'd like to achieve some kind of consensus that > depending on su causes root access to be dependent upon unpriveledged > security, and is thus something to be engineered against. >Hmm.. A few things you have to ask yourself. 1) Is limiting su to a smaller subset of users, and auditing su against known attacks engineered enough to protect you? 2) What additional security risks do you take on when you allow 'root' logins from remote (Or over localhost loopback)? 3) Is the solution worth the overhead of encryption or complex protocol exchange? 4) If there is a fatal flaw in libc that allows 'su' to be compermised what are the chances that the same flaw may spill over to 'sshd' (Refer to glibc debaco recently)? Or for that matter a function call that was added to 'sshd' to provide platform support (refer to my f---up with setenv(). Which luckly looks harmless outside the fact it messed up a few platforms). Personally, I don't think the use of 'sshd' as a form of local authentication is really any more secure then a well written 'su' on a good solid audited OS. Once a cracker with half a brain has compermised your system (via su, sshd, etc) you'll never see the log files unless you are doing remote logging. But I'm not dead sure where you are heading with this, but I perfer the idea of 'keeping things simple' (Even if I fail to do so sometimes). The simplest solution with the least amount of 'edge' cases tends to win compared to complex systems with large amounts fo 'edge' cases. Please note 'simplest solution' is really defined as the 'simplest correct solution', since there are 'incorrect' solutions that are simple.=) If you have a case which shows that 'sshd' can/will/is more secure then 'su' for the same task. Then by all means present it. I'm open to change if it's in the right direction. I think it's written into my work contract that I need to be flexible. =) - Ben
mouring at etoh.eviladmin.org wrote:> > 1) On a fully secure system 'root' should *NEVER* be allowed to be logged > in remotely. This includes localhost because it's possible to spoof such > things (Granted this is my view, but it's a view that has been drilled > into me since I first started in the UNIX community in 92).And me since 1988.> This also has no useful bearing on OpenSSH project. So this thread is at > at an end so useful work can be done. =)I disagree. I'm finding it very useful as an administrator (granted it's noise to developers). The discussion here has caused me to review my reasoning behind modifying the default sshd_config to disable root logins as I build our internal RPMs. This is not a bad thing to do every so often. Both sides have made good points, but a consensus has not been reached yet. Can we reach a consensus and update the default configuration files (if necessary) to reflect it? -- John Hardin Internal Systems Administrator Apropos Retail Management Systems, Inc. <johnh at aproposretail.com> - (425) 672-1304
I agree that it is desirable to login as root. In our environment we have 12 admin's looking after around 750 workstations/servers. Our ideal is to use openssh with keys and the Openssh patch which identifies which key has been used to login as root. This gives a degree of security and accountability. But when somebody leaves/starts then somebody has to go around all the boxes and add/remove userids or keys, so logging in directly as root is necessary with password as well unless we get into complex expect scripts etc. I realize that this may not be the "most secure" method, but I think we need to trade off risk against operational effectiveness. John (John.Phillips at calanais.com) Unix Support, Calanais Ltd Internal Phone: 700 2643 External Phone: 0141 568 2643> -----Original Message----- > From: John Hardin [mailto:johnh at aproposretail.com] > Sent: 27 February 2001 16:38 > To: OpenSSH Development List > Subject: Re: SU vs. ssh root at host > > > mouring at etoh.eviladmin.org wrote: > > > > 1) On a fully secure system 'root' should *NEVER* be > allowed to be logged > > in remotely. This includes localhost because it's possible > to spoof such > > things (Granted this is my view, but it's a view that has > been drilled > > into me since I first started in the UNIX community in 92). > > And me since 1988. > > > This also has no useful bearing on OpenSSH project. So > this thread is at > > at an end so useful work can be done. =) > > I disagree. I'm finding it very useful as an administrator > (granted it's > noise to developers). The discussion here has caused me to review my > reasoning behind modifying the default sshd_config to disable root > logins as I build our internal RPMs. This is not a bad thing > to do every > so often. > > Both sides have made good points, but a consensus has not been reached > yet. Can we reach a consensus and update the default > configuration files > (if necessary) to reflect it? > > -- > John Hardin > Internal Systems Administrator > Apropos Retail Management Systems, Inc. > <johnh at aproposretail.com> - (425) 672-1304 >