Bug 444670

Can you grab the output of lshal?

I have been able to reproduce this I've actually been meaning to get some more info on this.  Out of 
interest, does your iPod appear on: http://banshee-project.org/files/podsleuth/ipod-model-table ?

Created attachment 304202 [details]
lshal output

The requested lshal output.

My iPod does appear on that list and strangely this used to work earlier in the
F9 cycle.

(In reply to comment #3)
> Created an attachment (id=304202) [edit]
> lshal output
> 
> The requested lshal output.
Very helpful
> 
> My iPod does appear on that list and strangely this used to work earlier in the
> F9 cycle.
Compared to my F8 machine, this output is very bland!  There *should* be a good 15 odd entries 
starting with org.podsleuth.ipod with the serial number, colour, model name, capabilities etc.

I'm going to test on rawhide in a few minutes.

I am tempted to think this is a dbus/ndesk-dbus issue. Now I don't even get the
report back that there are no ipods in the hal tree.

I did manage to trick it into telling me that 

Unhandled Exception: System.Exception: org.freedesktop.DBus.Error.NoReply:
Message did not receive a reply (timeout by message bus)
  at IManagerProxy.FindDeviceStringMatch (System.String value, System.String )
[0x00000] 
  at Hal.Manager.FindDeviceByStringMatch (System.String key, System.String
value) [0x00000] 
  at Hal.Manager.FindDeviceByStringMatchAsDevice (System.String key,
System.String value) [0x00000] 
  at PodSleuth.HalFrontend.HalClient.Run (System.String[] args) [0x00000] 
  at PodSleuth.HalFrontend.HalEntry.Main (System.String[] args) [0x00000] 

I tried backing ndesk-dbus down to 0.6.0 using epoch and explicitly telling
podsleuth at compile time to expect the updates in /usr/lib64/podsleuth but had
no luck. It does not appear that ndesk-dbus is interfacing with dbus at all.

And we have the following AVC from SELinux when invoking podsleuth:

host=localhost.localdomain type=AVC msg=audit(1210070168.524:19): avc: denied {
getsched } for pid=2998 comm="mono" scontext=system_u:system_r:hald_t:s0
tcontext=system_u:system_r:hald_t:s0 tclass=process 

host=localhost.localdomain type=SYSCALL msg=audit(1210070168.524:19):
arch=c000003e syscall=145 success=no exit=-13 a0=bb6 a1=7fc42cfd0ba8 a2=d
a3=367e966fac items=0 ppid=2994 pid=2998 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono"
exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null) 

Adding Dan Walsh to CC for input.

Using selinux-policy-3.3.1-44.fc9

(In reply to comment #6)
> And we have the following AVC from SELinux when invoking podsleuth:
> 
> host=localhost.localdomain type=AVC msg=audit(1210070168.524:19): avc: denied {
> getsched } for pid=2998 comm="mono" scontext=system_u:system_r:hald_t:s0
> tcontext=system_u:system_r:hald_t:s0 tclass=process 
> 
> host=localhost.localdomain type=SYSCALL msg=audit(1210070168.524:19):
> arch=c000003e syscall=145 success=no exit=-13 a0=bb6 a1=7fc42cfd0ba8 a2=d
> a3=367e966fac items=0 ppid=2994 pid=2998 auid=4294967295 uid=0 gid=0 euid=0
> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono"
> exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null) 
> 
> Adding Dan Walsh to CC for input.
> 
> Using selinux-policy-3.3.1-44.fc9
Thanks for that I was able to reproduce but I've been so busy that I was unable
to get through all the debugging stages yet.

I've got some more juicy SELinux goodness, I'll attach it soon when I've got all the sealert stuff.

Created attachment 304627 [details]
SELinux AVCs - Enforcing Mode

Created attachment 304628 [details]
SELinux AVCs - Permissive Mode

(In reply to comment #9)
> Created an attachment (id=304627) [edit]
> SELinux AVCs - Enforcing Mode
(In reply to comment #10)
> Created an attachment (id=304628) [edit]
> SELinux AVCs - Permissive Mode

In both instances I have reattached the iPod (unplug, plugin) and issued 'mount
/dev/sdx2 /mnt'.

The reported problem still seems to occur, but I'm wondering if thats a smoke
screen, I don't really feel like turning SELinux off on that install, I might
clone the machine and try again though.  Would really appreciate the assistance
of our SELinux gurus though

I turned SELinux off completely for testing purposes, and Banshee from SVN shows
the iPod correctly but podsleuth still reports no ipod in the device tree. So we
have two bugs, the SELinux one and then once that is resolved figuring out why
podsleuth hates us.

Want to file a bug against the selinux-policy package?

Created attachment 304639 [details]
I just hacked together some podsleuth policy.

If you untar this tar ball and run the .sh script it will compile and install
the selinux policy module then run attempt to use podsleuth,  Send me any
additional avc messages.

With a newly relabelled system and this module installed I get this when
inserting the iPod (thus making the default action dialog pop up).

host=localhost.localdomain type=AVC msg=audit(1210151433.916:20): avc: denied {
getsched } for pid=2931 comm="mono" scontext=system_u:system_r:hald_t:s0
tcontext=system_u:system_r:hald_t:s0 tclass=process 

host=localhost.localdomain type=SYSCALL msg=audit(1210151433.916:20):
arch=c000003e syscall=145 success=no exit=-13 a0=b73 a1=7fc0335a2ba8 a2=d
a3=3b9bd66fac items=0 ppid=2929 pid=2931 auid=4294967295 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mono"
exe="/usr/bin/mono" subj=system_u:system_r:hald_t:s0 key=(null) 

Created attachment 304759 [details]
audit log

An audit log for Dan to play with

Well I don't know how you did it but /dev/null is labeled incorrectly

# restorecon /dev/null

Also you need to relabel your homedir for nsplugin to work better.

restorecon -R -v ~
I got a couple of avc's for nsplugin that I will fix in the next Fedora 9
selinux-policy package

# restorecon -R -v /var/log

Could you attach the corrected podsleuth.te, fc files

Created attachment 304774 [details]
podsleuth.fc

Created attachment 304776 [details]
podsleuth.te

I've performed the requested tasks and attached the files you requested.

I've cloned the original problem as bug #445611

I'll post the updated selinux policy that I have shortly.

Created attachment 304847 [details]
Updated SELinux Policy

After discussions online with the SELinux crew, this policy gets rid of most of
the AVCs, not all, I'll provide an updated RPM when I've managed to get them
all.

You'll want to add:

/usr/libexec/hal-podsleuth	 --	
gen_context(system_u:object_r:podsleuth_exec_t,s0)

To podsleuth.fc too, and run /sbin/restorecon -F -R -v
/usr/libexec/hal-podsleuth

Also the var_run_podsleuth stuff is WIP which I'll be able to concentrate on
later this week

Fixed in selinux-policy-3.3.1-49.fc9.noarch

selinux-policy-3.3.1-49.fc9.noarch not found in koji and so far as I can tell
from CVS no such change has been checked in. Reopening till the bug can be
comfirmed fixed or at least an rpm is available for testing.

Created attachment 305021 [details]
Updated SELinux Policy

Okay, new version with more fixes etc.

Note, testers will need to change the last few lines in
/usr/libexec/hal-podsleuth to:

rm -f $DEBUG_PATH
mkdir /tmp/podsleuth.wapi
MONO_SHARED_DIR=/tmp/podsleuth.wapi $MONO $MONO_ARGS $MONO_EXEC $MONO_EXEC_ARGS
&> $DEBUG_PATH && {
	rm -f $DEBUG_PATH
	rm -rdf /tmp/podsleuth.wapi
}

I'll sort this out later today, but this has 0 AVCs in Enforcing mode.

I am still experiencing problems that relates to this, connecting to the
messagebus times out when SELinux is enforcing. This makes podsleuth not work
and it causes the startup time for banshee to be counted in double digit minutes.

type=USER_AVC msg=audit(1210553612.168:104): user pid=1942 uid=81
auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: 
denied  { send_msg } for msgtype=method_return dest=:1.77 spid=2008 tpid=3440
scontext=system_u:system_r:hald_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_mono_t:s0-s0:c0.c1023 tclass=dbus
: exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'

This is with selinux-policy-3.3.1-49

(In reply to comment #24)
> I am still experiencing problems that relates to this, connecting to the
> messagebus times out when SELinux is enforcing. This makes podsleuth not work
> and it causes the startup time for banshee to be counted in double digit minutes.
> 
> type=USER_AVC msg=audit(1210553612.168:104): user pid=1942 uid=81
> auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: 
> denied  { send_msg } for msgtype=method_return dest=:1.77 spid=2008 tpid=3440
> scontext=system_u:system_r:hald_t:s0
> tcontext=unconfined_u:unconfined_r:unconfined_mono_t:s0-s0:c0.c1023 tclass=dbus
> : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)'
> 
> This is with selinux-policy-3.3.1-49
The policy works with -42 (current rawhide version).

I'd be prepared to bet that 3.3.1-44 broke the policy as the transition is no longer occurring.

Any thoughts Dan?

Created attachment 305238 [details]
New Podsleuth Policy

Okay, here is the latest podsleuth policy that I have, seems to work great.  If
merged upstream, the hald_t line needs to be merged into the hald policy.

Fixed in selinux-policy-3.3.1-51.fc9.noarch

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I've got all the updated pieces including podsleuth-0.6.0-6.fc9.x86_64 and
selinux-policy-targeted-3.3.1-51.fc9.noarch, rebooted and relabeled,  but still get 

SELinux is preventing hal-podsleuth (podsleuth_t) "getattr" to /usr/bin/mono
(mono_exec_t).

when attaching my ipod shuffle. Going to permissive mode allows it to work.

That is strange.  I am seeing that access.

allow podsleuth_t mono_exec_t : file { ioctl read getattr lock execute
execute_no_trans }; 

Could you attach the avc message?

Here you go:

host=raptor.sr.unh.edu type=AVC msg=audit(1210969433.925:302): avc: denied {
getattr } for pid=16961 comm="hal-podsleuth" path="/usr/bin/mono" dev=dm-0
ino=296345 scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:mono_exec_t:s0 tclass=file

host=raptor.sr.unh.edu type=SYSCALL msg=audit(1210969433.925:302): arch=c000003e
syscall=4 success=no exit=-13 a0=1042a00 a1=7fff94b57880 a2=7fff94b57880 a3=0
items=0 ppid=2583 pid=16961 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-podsleuth"
exe="/bin/bash" subj=system_u:system_r:podsleuth_t:s0 key=(null) 

Argh, this is (cuse the pun) really bugging me now.

I get the same AVC with -51 on my desktop now (fresh reinstall with KDE):

# audit2allow
host=localhost.localdomain type=AVC msg=audit(1211276419.133:90): avc: denied
{getattr } for pid=10534 comm="hal-podsleuth" path="/usr/bin/mono" dev=sdb2
ino=1319940 scontext=system_u:system_r:podsleuth_t:s0
tcontext=system_u:object_r:mono_exec_t:s0 tclass=file host=localhost.localdomain
type=SYSCALL msg=audit(1211276419.133:90): arch=c000003e syscall=4 success=no
exit=-13 a0=b42440 a1=7fff9514fce0 a2=7fff9514fce0 a3=0 items=0 ppid=1960
pid=10534 auid=4294967295 uid=0 gid=0euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm="hal-podsleuth" exe="/bin/bash"
subj=system_u:system_r:podsleuth_t:s0 key=(null)


#============= podsleuth_t ==============
allow podsleuth_t mono_exec_t:file getattr;

This package has now been orphaned, hopefully someone will be able to pick it up and resolve the reported bug soon.

This has been fixed for a while.