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

Re: ld.so and LD_PRELOAD



Hi,

On Sat, Jun 07, 2003 at 04:22:30AM +1000, Russell Coker wrote:

> http://marc.theaimsgroup.com/?l=selinux&m=105492305125090&w=2
> The above URL contains a link to a discussion about LD_PRELOAD in SE Linux.
> 
> It seems that if you can get root access to a SE Linux machine then LD_PRELOAD 
> can be used (it's allowed if your real and effective UIDs match) to exploit 
> system programs.
> 
> The solution to this is to have ld-linux.so do a check for whether the secsid 
> and osecsid of the process are equal in addition to the check for effective 
> and real UIDs.
> 
> Now I don't want to maintain a SE Linux version of libc6 for a special 
> /lib/ld-linux.so.2 if I can avoid it.  Also I think it would be ideal if the 
> functionality in this regard could support multiple security systems.  Would 
> it be practical for /lib/ld-linux.so.2 to load a shared object to determine 
> whether LD_PRELOAD is allowed?

Hm, I don't know much about SE Linux, but from reading the discussion,
doesn't it assign a little too much trust to named files?

Is there a FAQ that explains why SE Linux didn't choose to place all its
protections at the syscall level, and use an authentication server that
can grant capabilities to processes and hand out certificates in
exchange for user credentials? 

Together with a convenient way for data files to be certified by the
processes that created them, forming a certificate path back to the
user's credentials, then this would seem all you need to implement a lot
of MAC schemes.

I'm not proficient in this field though, so I'd appreciate it if you
could point me to something that explains the reasoning begind SE Linux' 
strategy. To me it comes across as almost requiring successful and
complete lockdown of the system, otherwise you loose all trust.

(And aside -- I'd say that a security system that's so complex that few
people will be able to use it and create policies without leaving gaping
holes open, is quite likely to actually decrease overall system
security. I don't know to what extent this applies to SE Linux, but
I've personally heard a very knowledgeable guy, I think it was you,
Russel, say that only a few people in the world completely understand SE
Linux).

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    



Reply to: