On Mon, Nov 08, 2004 at 01:31:51PM +1100, O Plameras wrote: > Ken Foskey wrote: > >I am unsure how this would have prevented the attack on the kernel that > >was applied? Please explain. > > With the intruder having acquired unprivileged access to system, he/she > could > have been confined to limited sets of functions because that is one of > the things > that SELinux does. Because he/she is restricted in what can be done it will > take a bit longer to figure out ( I assume ) how to escalate privileges > to root. In
Only if the set of privileges granted to the program didn't include access to the flawed function. It was ptrace(), so an "allow only that which is really required" policy would have probably blocked the access, there's no guarantee. > the meantime the SysAdmin who does what he does will notice unusual > activities within his system and so, the intruder could have been > detected before > doing damage to the Servers. Potentially. Depends on how many tripwires the attacker managed to hit. > >>2. Would 'kerberos' have prevented this sort of break-in ? > > > >The initial attack was by social engineering. One developers key was > >compromised due to their lack of security thought. With one weak link in > >the chain then it all comes down. > > Now, I posed the problem without really knowing the complete details of > the circumstances > because 'kerberos' is meant to be the strongest security protection > against this sort of > attacks. Where the hell did you pick that up from? "This sort of attacks" could be one of: 1) Sniff the entry of a password on a previously compromised host: hmm, no, Kerberos doesn't protect against r00ted boxen. 2) Exploitation of a kernel vulnerability to obtain escalated privileges: riiight. 3) Use of a stored authentication credential to gain access to a system account on another system: probably not, and Kerberos is a real pest in this situation. > I gather that 'ssh' which I noticed is the cryptographic > security procedure used > at these Debian sites has not prevented the attacks. Hoo boy. > I note here some differences between ssh and kerberos: > > 1. SSH needs local identity files whilst kerberos does not You mean known_hosts? No, kerberos just restricts you to a small set of hosts which you can access (without setting up cross-domain trust relationships). And after all, if an attacker has just sniffed your password, he'd be very, very unlucky not to get the hast you connected as well. > 2. SSH does not impose time restrictions on a session whilst kerberos > does (Prevents > replay attacks) From memory, SSH uses some form of challenge/response to set things up, so a replay attack wouldn't be feasible. > 3. In SSH the client decides what tools and application to run on the server I call 'horseshit'. Should have done it two days ago, but there you are. > whilst in kerberos, the server may restrict the clients from running > certain tools and > applications (Ease and simplicity of management as to who and what to > allow or > disallow) You've never actually administered, or even smelt, a Kerberos system, have you? "Ease and simplicity of management" is not something I hear often in connection with Kerberos. > This is my understanding of SSH and Kerberos so correct me if I'm wrong. You're wrong. - Matt
signature.asc
Description: Digital signature
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
