ld.so and LD_PRELOAD
Russell Coker
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?
--
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
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Collins
> 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?
I don't know too much about SE Linux, but what keeps someone who has
root from dropping their own ld-linux.so.2 in there?
I assume that SE Linux has some higherlevel traps than just root and
not-root. What keeps them from doing:
./myld.so /bin/program-to-exploit
though? Is /lib/ld-linux.so.2 given some filesystem based attributes
that gives it higher capabilities than some copied ld.so?
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
Emile van Bergen
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 em...@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Russell Coker
> > 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?
>
> I don't know too much about SE Linux, but what keeps someone who has
> root from dropping their own ld-linux.so.2 in there?
The same thing that stops them from replacing /etc/shadow and other important
files. Merely having root does not grant you much access on a SE Linux
system, see http://www.coker.com.au/selinux/play.html .
> I assume that SE Linux has some higherlevel traps than just root and
> not-root. What keeps them from doing:
>
> ./myld.so /bin/program-to-exploit
It's the same as doing "./myld.so /bin/passwd". Sure you can run that
command, it will run the program, but the program will get the same access as
determined by ./myld.so not that which would be granted by running
/bin/passwd (so therefore you can't modify /etc/shadow or do any other fun
things.
> though? Is /lib/ld-linux.so.2 given some filesystem based attributes
> that gives it higher capabilities than some copied ld.so?
It's exactly the same as the default Linux situation regarding SUID files.
Run "./ld.so /bin/passwd" as non-root and the passwd program will attempt to
do it's thing, but it won't have any access to /etc/shadow and won't be able
to do anything. The same thing applies in SE Linux if you use the "./ld.so"
method to run a program that triggers a domain transition (the SE equivalent
of being SUID), as far as the kernel is concerned you are running the program
./ld.so and the program /bin/passwd (or whatever you are running) is just a
shared object that the program reads.
--
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
Russell Coker
> > 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
Anthony DeRobertis
> 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.
Sure you can. When you're deciding if you want offer some service on a
box, for example, you weight the costs, including security, against the
benefits. If you've installed SELinux, you probably think it provides
security benefits. So you're going to include it in calculating the
security costs, which will be less because of it. Thus, you are more
likely to offer services.
If it turns out that SELinux doesn't really provide the security bonus
you thought it did --- either due to a bug or wanton misconfiguration
--- you have a less secure box than a standard Linux one would of been
(because you wouldn't of offered the service)
Brian May
> I don't know too much about SE Linux, but what keeps someone who has
> root from dropping their own ld-linux.so.2 in there?
>
> I assume that SE Linux has some higherlevel traps than just root and
> not-root. What keeps them from doing:
>
> ./myld.so /bin/program-to-exploit
>
> though? Is /lib/ld-linux.so.2 given some filesystem based attributes
> that gives it higher capabilities than some copied ld.so?
IIRC this is not a problem.
/lib/ld-linux.so.2 won't have the same file label as
/bin/program-to-exploit (which causes the domain to change).
So execing /lib/ld-linux.so.2 won't cause the domain to change.
I am not sure how /lib/ld-linux.so.2 runs the program, but it doesn't
fork or exec, so the domain will remain the same.
--
Brian May <b...@debian.org>
David B Harris
I certainly agree with the sentiment (having witnessed it myself
routinely). However, LSM/SELinux is complex enough that most of the
people who would be affected by this will choose another solution
(grsecurity being the most prelevant, I believe). Those who don't have
the requisite experience necessary to understand that false security is
no security won't likely choose SELinux. I have also witnessed this
happen rarely, though. In those cases, they chose it primarily because
it was the most complex solution they could find.
Frankly, if you can solve that "problem" without removing options to
skilled administrators, you'll have done the world a big favour :)
Russell Coker
> > If it turns out that SELinux doesn't really provide the security bonus
> > you thought it did --- either due to a bug or wanton misconfiguration
> > --- you have a less secure box than a standard Linux one would of been
> > (because you wouldn't of offered the service)
If there is some particular program that you want to run but would not run
without the added protection of SE Linux (such as Sendmail) then you only
need to make sure that the SE Linux policy for that program is doing the
right thing. The protection for the rest of the system is merely an added
bonus.
> I certainly agree with the sentiment (having witnessed it myself
> routinely). However, LSM/SELinux is complex enough that most of the
> people who would be affected by this will choose another solution
> (grsecurity being the most prelevant, I believe). Those who don't have
Other solutions are less capable. For example the Gentoo policy in the gradm
package (which is more comprehensive than the Debian policy) has policy for
xauth which permits it to write to all files under /home.
The SE Linux policy for xauth permits it to create new files of a different
type which it has full access to (and the X applications can read) but can't
write to other files.
Also the grsec sample policy seems to have /bin/bash hard-coded into the
configuration in many places. With SE Linux files are given a type, so you
assign every shell the type shell_exec_t and things will work as expected no
matter which shell a user chooses. The shell is only a trivial example,
there are many other situations where having access based on file name will
bite you.
The case for SE Linux will be stronger when Linux 2.6.0 is released. The LSM
framework will be in the standard kernel (and probably the SE Linux code
too).
Is anyone offering root access to any machine running any security system
other than SE Linux?
Brian May
> Sure you can. When you're deciding if you want offer some service on a
> box, for example, you weight the costs, including security, against the
> benefits. If you've installed SELinux, you probably think it provides
> security benefits. So you're going to include it in calculating the
> security costs, which will be less because of it. Thus, you are more
> likely to offer services.
>
> If it turns out that SELinux doesn't really provide the security bonus
> you thought it did --- either due to a bug or wanton misconfiguration
> --- you have a less secure box than a standard Linux one would of been
> (because you wouldn't of offered the service)
Running more services on a computer just because you are using SE-Linux,
is, IMHO a poor argument. SE-Linux isn't a complete security solution in
itself, it simply is a tool that can be used, and combined with other
security mechanisms to make your computer more secure.
Your argument is like the one "My car has {antiskid/ABS brakes, air
bags, etc} so it is OK if I drive more aggressively".
Both are similar in that just having the better technology does not
excuse making poor decisions elsewhere.
--
Brian May <b...@debian.org>
Anthony DeRobertis
>
> Your argument is like the one "My car has {antiskid/ABS brakes, air
> bags, etc} so it is OK if I drive more aggressively".
Well, I'd say it's more like saying: It's snowing today, there is some
ice on the roads, but I really need to get somewhere. If I had a car
with two-rear-wheel drive, no ABS, etc., I'd be stuck missing it. But
because the car has four-wheel drive, ABS, air bags, etc., I can go
(though slowly and carefully, of course).
It's like saying I'd never run, e.g., a shell server on Windows ME. But
with the additional security of a Unix system, I can.
With the additional security of SE-Linux, I can do things that I
couldn't do without it.
It's silly to treat security (or safety, for that matter) as an
absolute. There is a non-zero risk of a security breach. That risk is
increased by running services and decreased by, e.g., pulling the
network plug. To decided if you want/can run a service, you compare the
risk of security breach with the benefits of running that service.
SELinux decreases the risk of a security breach (at least we hope it
does!). Therefor, a reasonable person may choose to run more services.
That's not a poor decision. It's a reasonable decision guided by the
goal of getting the most out of computing resources by carefully
balancing the convenience of additional services against the security
risks of the same.
Russell Coker
> Well, I'd say it's more like saying: It's snowing today, there is some
> ice on the roads, but I really need to get somewhere. If I had a car
> with two-rear-wheel drive, no ABS, etc., I'd be stuck missing it. But
> because the car has four-wheel drive, ABS, air bags, etc., I can go
> (though slowly and carefully, of course).
Yes, some 4WD owners over-estimate the capabilities of their vehicle (or their
ability to drive it) and get stuck. But the same happens with 2WD vehicles,
I've had a near-miss doing 4WD stuff in a 2WD vehicle, I almost drove a Ford
Falcon (for the EU people - that's much like a Ford Mondeo but quite a bit
larger, http://www.ford.com.au will show you pictures) into a river that was
deep enough to destroy the vehicle. (*)
> SELinux decreases the risk of a security breach (at least we hope it
> does!). Therefor, a reasonable person may choose to run more services.
> That's not a poor decision. It's a reasonable decision guided by the
> goal of getting the most out of computing resources by carefully
> balancing the convenience of additional services against the security
> risks of the same.
Yes. If you add extra services without adequate consideration then you can
get yourself into trouble. But I don't think this is a valid criticism of SE
Linux. Home users may offer extra services because of having SE Linux, but
they should be in a good position to make an informed choice about whether
their goals exceed their skills. Corporate sys-admins usually don't get a
choice, their boss tells them to provide a service regardless of the risk,
for them SE Linux only has benefits for security.
(*) I guess this will reveal whether my parents do google searches on me,
they haven't heard of what almost happened to their car. ;)
--
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
Anthony DeRobertis
On Monday, Jun 9, 2003, at 07:22 US/Eastern, Russell Coker wrote:
> Yes. If you add extra services without adequate consideration then
> you can
> get yourself into trouble. But I don't think this is a valid
> criticism of SE
> Linux.
It's not a criticism of SE Linux. Originally, it was just a reminder to
people that SE Linux changes the security tradeoff, and that if the
calculation turns out to be wrong, your box is less secure than it
otherwise would of been.
IOW, in theory SE Linux can make a box no less secure. In practice,
people not behaving with due caution (due to them relying on SE Linux
too much) can.
That's true of any security product, of course.
>
> (*) I guess this will reveal whether my parents do google searches on
> me,
> they haven't heard of what almost happened to their car. ;)
LOL.