New Years Resolution

[Tom London]

On Sat, Jan 2, 2010 at 11:10 AM, Steve Blackwell <zephod at cfl.rr.com> wrote:
> On Sat, 2 Jan 2010 10:10:27 -0800
> Tom London <selinux at gmail.com> wrote:
>
>> On Sat, Jan 2, 2010 at 9:39 AM, Steve Blackwell <zephod at cfl.rr.com>
>> wrote:
>> > OK, here is one of my New Year's resolutions:
>> >
>> > Get a better understanding of SELinux.
>> >
>> > I'm running a F11 box in permissive mode and I get hundreds of AVCs.
>> > Let start with this one.
>> >
>> > SELinux is preventing dbus-daemon (system_dbusd_t) "search"
>> > unconfined_t.
>> >
>> > node=steve.blackwell type=AVC msg=audit(1262408462.863:1162): avc:
>> > denied { search } for pid=1613 comm="dbus-daemon" name="23667"
>> > dev=proc ino=584443
>> > scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023
>> > tcontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=dir
>> >
>> > Now, if I'm reading this correctly, the dbus-daemon process tried to
>> > search a directory called 23667 but didn't have permission to do so.
>> >
>> > The problem with that is that I don't have a directory called 23667.
>> > At least there isn't one now but I suppose it could have existed at
>> > the time the AVC was generated which was just after midnight. I'm
>> > getting one of these every hour with different numbers for the
>> > target directory. I thought that it might be related to a cron job
>> > but it seems that the hourly crom job just calls anacron to check
>> > to see if the daily, weekly or monthly cron job needs to be run.
>> > The other possibility is that it has something to do with BackupPC.
>> >
>> > One thing I don't understand is why SELinux is flagging this in the
>> > first place. Since the target context is unconfined_t, should
>> > anything be able to search it?
>> >
>> > Steve.
>>
>> If you notice, the AVC says "dev=proc".  That, and the name of the
>> directory suggests that the target directory in question is
>> '/proc/23677'.  So, dbus-daemon (pid=1613) is attempting to search for
>> some information about a running unconfined_t process (in this case,
>> 23677) and the policy is not allowing it.
>>
>> Since the attempted accesses are directed at running processes, they
>> would almost certainly be different and/or change with time, reboots,
>> etc.
>>
>> I believe the policy does not allow unrestricted access by arbitrary
>> domains to unconfined_t targets.
>>
>> Hope this helps....
>>
>> tom
> Thanks Tom, it does help.
>
> This is interesting. I just got another of the same type of AVC while I
> was watching and so I was able to look at the process and:
>
> # ls -Zd /proc/29899
> dr-xr-xr-x. steve steve
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 /proc/29899
>
> # ps -ef | grep 29899
> steve    29899     1  2 13:55 ?        00:00:04 /usr/bin/python
> -E /usr/bin/sealert -s
>
> so SELinux is complaining about sealert!?
>
> # ps -Z 29899
> LABEL                             PID TTY      STAT   TIME COMMAND
> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 29899 ? S
> 0:04 /usr/bin/python -E /usr/bin/sealert -s
>
> Is that context correct?
>
> Steve.
>

Does 'audit2allow -al' give you any useful information?  (Or you can
look at /var/log/audit/audit.log for the "raw" AVCs).

Also, you can put the system in to "permissive mode" (via 'setenforce
0').  This will allow the accesses, but log any access violations.

You may also want to check if there are any updates to the
selinux-policy packages.

tom
-- 
Tom London