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

Re: SELinux Attack!

Hash: SHA1

Karl Larsen wrote:
> Matthew Saltzman wrote:
>> On Sat, 2007-10-13 at 09:42 -0600, Karl Larsen wrote:
>>> Matthew Saltzman wrote:
>>>> On Sat, 2007-10-13 at 06:41 -0600, Karl Larsen wrote:
>>>>> Vinayak Mahadevan wrote:
>>>>>> On 10/13/07, Karl Larsen <k5di zianet com> wrote:
>>>>>>>     I have had all those problems in the past years. But this
>>>>>>> problem
>>>>>>> yesterday was in fact caused by SELinux. I say that because
>>>>>>> different
>>>>>>> from your experience when I turned off SELinux all the problems
>>>>>>> went away.
>>>>>> let the machine  run for some days and then let us know your
>>>>>> experience with the machine.
>>>>>> Vinayak
>>>>>     So far so good. But I would like to know why SELinux did this.
>>>>> And what do I need to do to to make SELinux work on this machine?
>>>>> There seem to be others that use it and it works without a problem.
>>>> Karl-
>>>> As I recall, you said earlier in the thread that you had disabled
>>>> SELinux for a while when you were experimenting with spinning a custom
>>>> distribution. 
>>>> SELinux checks the contexts of files (their SELinux security
>>>> information) to see if programs are violating their restrictions,
>>>> but it
>>>> also updates the contexts when files are created and updated.  If you
>>>> turn SELinux off, file contexts stop getting updated.  When you turn it
>>>> back on, the files may suddenly not have contexts that allow their
>>>> applications to access them.  You'll see the things going wrong
>>>> in /var/log/messages (grep for AVC and look for "denied" messages) or
>>>> you'll get that star icon in your notification area when a program. 
>>>> And
>>>> of course, the programs that use incorrectly labeled files will not
>>>> work.
>>>> You also said at some point that you followed instructions to relabel
>>>> your filesystem and things started to work.  That is exactly the
>>>> solution to the problems introduced by turning SELinux off.  So if you
>>>> turn SELinux back on and relabel one more time, you should be OK after
>>>> that (as long as you leave SELinux on).
>>>> Most people don't see (too many) SELinux problems because most people
>>>> don't ever turn it off.  So it maintains itself.
>>>     Well I did get a whole lot of messages like this, every ten
>>> seconds or so:
>>> Oct 11 02:31:08 k5di dbus: Can't send to audit system: USER_AVC avc: 
>>> received policyload notice (seqno=2) : exe="/bin/dbus-daemon"
>>> (sauid=500, hostname=?, addr=?, terminal=?)
>>> I'm not sure what this means but it seems to mean that
>>> /bin/dbus-daemon has a problem with my hostname ect.
>>> I looked at man dbus-daemon and it is a library that any device can
>>> access. It appears it doesn't have what SELinux wants. How do I fix
>>> this I wonder?
>> I found a couple of references to that message by googling.  They seem
>> to suggest a bug related to dbus.
>> I have a handful of these in my logs from the last few weeks, but they
>> aren't frequent and they seem otherwise harmless.  If you are getting
>> lots and lots, that may be an issue, but it may just be an artifact of
>> some other problem.
>> http://www.redhat.com/archives/fedora-selinux-list/2007-June/msg00103.html
>    Well thanks Matt. The web page tells me that other people have had
> this same problem which is a Bug for dbus. They say it was fixed for FC6
> but it is showing up again in F7.
>    I will not turn on SELinux again until I see a update for dbus. It
> appears dbus is used only by SELinux.
THis is a well known bug in dbus.  Dbus can use selinux to govern
communications between processes.  So it uses the kernel SELinux policy
and needs to communicate with it.  Since dbus is used to control
communications, it has to audit all security related data.

When SELinux policy gets reloaded in the kernel.  The kernel sends a
message to dbus telling it that the policy reload happened.  dbus then
attempts to send an audit message that it has received the message.

The problem is the session dbug runs as a normal user, and DAC
permissions prevent the message from being sent to the audit daemon.
The message gets rerouted to /var/log/message and is reported as an error.

In Rawhide the dbus session daemon no longer attempts to send the
message to audit daemon since it knows it is not able to, and sends it
directly to syslog.  So no error is reported.

So this is a long way of saying you can ignore this dbus message.
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


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