This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 514768 - SELinux denial for synce-hal
SELinux denial for synce-hal
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: synce-hal (Show other bugs)
14
All Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
: Patch, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-30 13:07 EDT by Adam Williamson
Modified: 2010-11-05 18:30 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-05 18:30:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
put sockets in /var/run (1.43 KB, patch)
2009-08-03 11:44 EDT, Adam Williamson
no flags Details | Diff

  None (edit)
Description Adam Williamson 2009-07-30 13:07:32 EDT
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)
Comment 1 Adam Williamson 2009-07-30 13:08:58 EDT
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)
Comment 2 Adam Williamson 2009-07-30 13:13:32 EDT
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
Comment 3 Daniel Walsh 2009-07-30 17:30:24 EDT
Why is synce-hal creating a socket in /tmp?

Why is it changing ownership on something?
Comment 4 Adam Williamson 2009-07-30 19:10:00 EDT
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
Comment 5 Adam Williamson 2009-07-30 19:12:02 EDT
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
Comment 6 Daniel Walsh 2009-07-31 06:46:17 EDT
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
Comment 7 Adam Williamson 2009-07-31 10:52:02 EDT
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
Comment 8 Adam Williamson 2009-08-03 11:44:01 EDT
Created attachment 356055 [details]
put sockets in /var/run
Comment 9 Adam Williamson 2009-08-03 11:45:09 EDT
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.
Comment 10 Adam Williamson 2009-08-04 19:19:21 EDT
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
Comment 11 Andreas Bierfert 2009-08-05 00:39:26 EDT
Yes, sorry about that hasty me.
Comment 12 Bug Zapper 2009-11-16 06:11:48 EST
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
Comment 13 Bug Zapper 2010-11-04 06:38:31 EDT
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
Comment 14 Adam Williamson 2010-11-05 18:30:01 EDT
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

Note You need to log in before you can comment on or make changes to this bug.