On Mon, 2006-04-17 at 19:58 +0300, Lauri wrote:
> > On Mon, 2006-04-17 at 18:58 +0300, Lauri wrote:
> >> To try that I enabled SELinux again. It relabelled the system and now
> >> gives new error:
> >>
> >> Apr 17 18:33:08 localhost kernel: [drm] Loading R200 Microcode
> >> Apr 17 18:33:10 localhost kernel: audit(1145287990.371:10): avc:
> >> denied { execmod } for pid=3964 comm="metacity" name="libGL.so.1.2"
> >> dev=hda5 ino=1235892 scontext=user_u:system_r:unconfined_t:s0
> >> tcontext=system_u:object_r:lib_t:s0 tclass=file
> >
> > Hmmm...and /usr/lib is on your ext3 filesystem?
> > # /sbin/restorecon -v /usr/lib/libGL.so.1.2
> >
> > That should be textrel_shlib_t. Looks ok on an up-to-date FC5 system
> > here.
> >
>
> I tried that, but it didn't work. I'll just disable SELinux then and try
> again some other time. :) As a home user, I don't really think I need
> it... Or do I?
If you don't mind, bugzilla the issue first with as much detail as
possible, so that someone can at least try to investigate it further.
Whether or not you "need" it is a matter of (often fiery) debate, and
naturally your call to make. Motivation for having a mandatory access
control (MAC) mechanism in the OS is discussed in the paper available
from the link below.
http://www.nsa.gov/selinux/papers/inevit-abs.cfm
It isn't a panacea or silver bullet for security, but it is a basic
building block necessary for building higher level security guarantees
and countering the threat posed by flawed and malicious applications.
Whether or not SELinux will help you with your specific needs at this
time is another question; it depends on your situation.
The other potential motivation for enabling it and working through
issues is to help the community with improving it for the long term
overall benefit of everyone, but you have to weigh the cost/benefit
tradeoffs there, naturally. Reporting the bug is at least a step in
contributing there.
--
Stephen Smalley
National Security Agency
