[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: About how to protect network resources in LDAP environment?



On Saturday, August 28, 2010 20:29:50 you wrote:
>On Sat, Aug 28, 2010 at 3:08 AM, Boyd Stephen Smith Jr.
><bss@iguanasuicide.net> wrote:
>> In <[🔎] 4C77F5CA.6030609@gmail.com>, Min Wang wrote:
>>>(1) does this approach
>>>
>>>prevent user1-> root ( su-> ) user2?
>>>
>> Yes. "su" does not grant Kerberos credentials.
>
>Can't root just read/steal and even use sockets/fifos/pipes owned by
>all other users?  Any Kerberos credentials used on the local system
>would also be usable by root.

From what I understand, properly implemented, strong encryption is used to 
make this impossible.  If you have some example code where root is able to 
access Kerberos resources that they haven't been authenticated and authorized 
for, I'd love to see it.  (Outside of stealing the TGT credentials; example 
below.)

Again, from what I understand, Kerberos was designed to work in an environment 
where the systems authenticating to the Kerberos "domain" where not under 
control of the administrators of the Kerberos domain.

I suppose it is possible for a userA, when authenticating from a system 
controlled by userB, can have their credentials "stolen" by userB -- it seems 
those credentials would be in plaintext for some period of time on userB's 
system.  Kerberos isn't designed against this, you should only get your TGT 
(i.e. do your authentication) from a system your trust or control.  Your TGT 
will be used to generate secure authentication tokens for using a service on 
all the untrusted systems that can speak to the Kerberos "domain".  Those 
authentication tokens time out, and can't be used for generating a TGT (or any 
other service besides the one they were generated for).
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: