sealertd is showing me denials for synce-hal, when I'm testing sync stuff: SELinux is preventing the hal-dccm from using potentially mislabeled files (synce-c6fa6730902c84159e1656f2713170d3.sock). SELinux has denied hal-dccm access to potentially mislabeled file(s) (synce-c6fa6730902c84159e1656f2713170d3.sock). This means that SELinux will not allow hal-dccm to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. If you want hal-dccm to access this files, you need to relabel them using restorecon -v 'synce-c6fa6730902c84159e1656f2713170d3.sock'. You might want to relabel the entire directory using restorecon -R -v 'synce-c6fa6730902c84159e1656f2713170d3.sock'. Source Context: system_u:system_r:hald_dccm_t:s0 Target Context: system_u:object_r:tmp_t:s0 Target Objects: synce-c6fa6730902c84159e1656f2713170d3.sock [ dir ] Source: hal-dccm Source Path: /usr/libexec/hal-dccm Port: <Unknown> Host: adam.local.net Source RPM Packages: synce-hal-0.14-1.fc12 Target RPM Packages: Policy RPM: selinux-policy-3.6.24-1.fc12 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Permissive Plugin Name: home_tmp_bad_labels Host Name: adam.local.net Platform: Linux adam.local.net 2.6.30-6.fc12.x86_64 #1 SMP Fri Jun 12 11:36:05 EDT 2009 x86_64 x86_64 Alert Count: 2 First Seen: Wed 29 Jul 2009 10:03:43 PM PDT Last Seen: Wed 29 Jul 2009 10:03:43 PM PDT Local ID: 553ce6cf-b631-45e6-8b65-ce1cfeafffb0 Line Numbers: Raw Audit Messages : node=adam.local.net type=AVC msg=audit(1248930223.311:324): avc: denied { remove_name } for pid=17200 comm="hal-dccm" name="synce-c6fa6730902c84159e1656f2713170d3.sock" dev=dm-0 ino=2519 scontext=system_u:system_r:hald_dccm_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=dir node=adam.local.net type=AVC msg=audit(1248930223.311:324): avc: denied { unlink } for pid=17200 comm="hal-dccm" name="synce-c6fa6730902c84159e1656f2713170d3.sock" dev=dm-0 ino=2519 scontext=system_u:system_r:hald_dccm_t:s0 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file node=adam.local.net type=SYSCALL msg=audit(1248930223.311:324): arch=c000003e syscall=87 success=yes exit=0 a0=2457872 a1=7ffff30eed00 a2=c000 a3=7ffff30eeaa0 items=0 ppid=3409 pid=17200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-dccm" exe="/usr/libexec/hal-dccm" subj=system_u:system_r:hald_dccm_t:s0 key=(null)
I also get one which looks like it may have the same root cause: SELinux is preventing hal-dccm (hald_dccm_t) "chown" hald_dccm_t. Raw Audit Messages : node=adam.local.net type=AVC msg=audit(1248930223.309:322): avc: denied { chown } for pid=17200 comm="hal-dccm" capability=0 scontext=system_u:system_r:hald_dccm_t:s0 tcontext=system_u:system_r:hald_dccm_t:s0 tclass=capability node=adam.local.net type=SYSCALL msg=audit(1248930223.309:322): arch=c000003e syscall=92 success=yes exit=0 a0=2457df0 a1=1f5 a2=ffffffff a3=7ffff30eed30 items=0 ppid=3409 pid=17200 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="hal-dccm" exe="/usr/libexec/hal-dccm" subj=system_u:system_r:hald_dccm_t:s0 key=(null)
I'm fairly sure that in this case it's synce-hal that's at fault and selinux-policy shouldn't be altered, which is why I've reported against synce-hal, but adding dwalsh to CC just in case I'm wrong! -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Why is synce-hal creating a socket in /tmp? Why is it changing ownership on something?
I don't know. The offending code is helpfully entirely uncommented. I'm not really a hacker so I don't know entirely why it does this, but here's the function: void _synce_connection_broker_take_connection (SynceConnectionBroker *self, GConn *conn) { SynceConnectionBrokerPrivate *priv = SYNCE_CONNECTION_BROKER_GET_PRIVATE (self); GRand *rnd; GIOChannel *chan; guint uid = 0; g_assert (priv->conn == NULL); priv->conn = conn; rnd = g_rand_new (); priv->filename = g_strdup_printf ("/tmp/synce-%08x%08x%08x%08x.sock", g_rand_int (rnd), g_rand_int (rnd), g_rand_int (rnd), g_rand_int (rnd)); g_rand_free (rnd); priv->server = gnet_unix_socket_server_new (priv->filename); synce_get_dbus_sender_uid (dbus_g_method_get_sender (priv->ctx), &uid); chmod (priv->filename, S_IRUSR | S_IWUSR); chown (priv->filename, uid, -1); chan = gnet_unix_socket_get_io_channel (priv->server); g_io_add_watch (chan, G_IO_IN, server_socket_readable_cb, self); dbus_g_method_return (priv->ctx, priv->filename); priv->ctx = NULL; } It's at the end of src/synce-connection-broker.c . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
code's been in there from the very first version of the file, so the upstream svn logs don't help explain what it's doing either. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I was hoping the package maintainer Andreas would comment. I added the chown and a couple of other fixes. I would rather the daemon communicate with the user viar a socket in /var/run. But I will add the code to allow it to use /tmp. Fixed in selinux-policy-3.6.26-2.fc12.noarch
Daniel: well, he probably would have done, but not all maintainers are as fast as you :) I know the synce guys quite well, I can take your suggestion to them - if I get this changed upstream, I'll notify you and you can take the permissions out of the policy again. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 356055 [details] put sockets in /var/run
Re-opening for Andreas. Andreas, I've attached a patch from Mark Ellis upstream which switches the socket location - if we confirm it works OK it'll go into upstream synce-hal. Can you add it to the Rawhide package, I'll test it, and if it works I will notify upstream and re-assign this bug back to Dan to take the rules back out of the policy? Thanks.
Was 0.14-3 intended to fix this? It appears to have gone through with no changelog update, so there's no record of what it's intended to do. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes, sorry about that hasty me.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This change went in upstream: Revision 3821 - (view) (download) (annotate) - [select for diffs] Modified Sat Aug 1 10:45:32 2009 UTC (15 months ago) by mark_ellis File length: 5847 byte(s) Diff to previous 3798 put client connection socket in /run instead of /tmp http://synce.svn.sourceforge.net/viewvc/synce/trunk/hal/ChangeLog?view=log prior to the 0.15 release. We have 0.15 in F14, so I guess this is fixed now. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers