[Don't Cc me, I'm the list FFS] On Mon, Nov 08, 2004 at 09:08:23PM +1100, O Plameras wrote: > Matthew Palmer wrote: > >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. > > I cannot comment on this because I do not know what you are talking about. > If you can be clearer.
SELinux works by by restricting access to what can be done by a program. If the exploit program couldn't run the flawed code, then no exploit would be possible. If SELinux allows access to the flawed code, then the flaw can still be exploited to obtain elevated privileges. > >>>>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: > > I got it from people who should know. Care to name names? "Voices in Oscar's Head" don't count, by the way. > >1) Sniff the entry of a password on a previously compromised host: hmm, no, > >Kerberos doesn't protect against r00ted boxen. > > > > > > > Can you elaborate how kerberos and r00ted boxen works and where the > latter will be > able to trick kerberos ? Does that sound like something from Eliza to anyone else? "tricking Kerberos" has nothing to do with it. If I've got a keylogger on your computer, logging every keystroke you type, whether you type the password into a Kerberised application or not, you're toast. Kerberos is nothing, and I do mean *nothing*, more than a heavily overengineered (though still probably the best-of-breed) untrusted-network authentication system. > >2) Exploitation of a kernel vulnerability to obtain escalated privileges: > >riiight. > > > I do not quite follow this. You probably did not read the circumstance > surrounding > the Debian Break-In. (http://www.wiggy.net/debian/explanation/) "ptrace vulnerability" -- ring any bells? And yes, I read the circumstances surrounding the Debian Break-in. Quite closely. > >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. > > You are saying things about kerberos without knowing what kerberos is, > what it is not, > and what it can do. I did the initial setup and 3 years of ongoing maintenance of a 400 user Kerberos realm. Whilst I will profess to not be an almighty god on the issue, I think it's fair to say I've got some degree of experience with it. > >>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. > > > > > > > Everything in ~/.ssh directory. Which is, in the basic case, just known_hosts. That keystroke logger got the login command as well as the password, you know. > >>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. > > > > > > > From this response, it appears you do not understand what is a 'replay > attack'. If > you can explain perhaps. Your not as clear as can be. Replay attack: a means of doing unpleasant things by resending previously captured information in the hope it will continue to elicit the same response as the initial transmission of the captured information. > >>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. > > > What you have above is the real 'horseshit' because in SSH once a client > connects there > is no mechanism to restrict the user to a subset of commands or functions. > > Whereas with Kerberos, there is a mechanism to do this. Do tell. Tell us all how an authentication mechanism can restrict what commands a user can execute in a shell (for bonus points, only use those features that can't also be used by SSH). > >>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 another example of 'saying without knowing'. In kerberos, the > SysAdmin > simply goes to the one Server (Master Server and make changes for a user > for example) > and that change will be implemented in each servers within the realm. > > In SSH the SysAdmin will have to connect to each Server the user is > connecting to , > to effect the changes. Imagine if you have a Farm of Servers consisting > of 500 Servers. > > So, I suggest you send yourself back to the drawing board as far as > Kerberos is concerned. You can restrict users from doing certain things by fiddling with host service keys and whatnot, but I can get the same thing (in fact, far more fine-grained protections) out of LDAP. Or screwing with the master copies of config files on my gold server. No need to go to my "500 servers" and change anything on all of them. Tell us how you configure Kerberos to restrict a user to running 'ls' and not 'cp' in their login shell. > So, I suggest you send yourself back to the drawing board as far as > Kerberos is concerned. I'll definitely take your advice, oh wise and benevolent master. - 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
