Re: ld.so and LD_PRELOAD
On Sat, 7 Jun 2003 07:38, Emile van Bergen wrote:
> > 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?
No. Firstly it makes no reference to file names at all in the enforcement
process, it's all based on protections that are based on the security context
which is stored in the Inode. If you rename all the files in the file system
you still will have the same protections applied to them all (although it
will be quite a trick to rename /lib/ld-linux.so.2).
> 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?
I don't think that there is a FAQ. But the reason is that it is difficult to
enforce everything at syscall level. For example in systems such as systrace
where syscall access is controlled it's common to control file access by
denying file open. However a file handle to an open file can be passed
between processes and this can grant inappropriate access. This is one
trivial example.
> 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.
The concept of "user" is not enough for a full MAC scheme. When gpg creates a
directory under your home directory then files under that directory need a
very different level of protection than files created by Netscape when you
are downloading files.
Then there are system programs such as passwd which recreate system files such
as /etc/shadow (which are not attached to any particular user).
> 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.
No. It requires complete lockdown of the system if you want to grant root
access to the world. If you run things like a regular Linux system (no
untrusted users with root access) then it provides much more protection for
the root account (among other things), and the problem we are discussing here
does not occur.
> (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).
If you run SE Linux in the recommended manner (IE don't give out root access
to the world) then the worst-case scenario is that you make it as (in)secure
as a standard Linux install. If you don't give away root access and don't
completely stuff up the SE Linux configuration then it will be much more
secure than a standard Linux install.
LSM (which SE Linux is built on) does not support permissive controls. So SE
Linux can only deny operations that would otherwise be permitted by regular
Unix controls. So for a recommended configuration you can not make it any
more insecure than a standard Linux system no matter what you do.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: