Bug 243942 - SELinux is preventing sh (vpnc_t) "dac_read_search" to (vpnc_t)
SELinux is preventing sh (vpnc_t) "dac_read_search" to (vpnc_t)
Product: Fedora
Classification: Fedora
Component: vpnc (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-06-12 17:09 EDT by Rogue
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-14 08:22:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from strace -f on vpnc (232.76 KB, application/octet-stream)
2007-06-13 10:24 EDT, Rogue
no flags Details

  None (edit)
Description Rogue 2007-06-12 17:09:49 EDT
Description of problem:
SELinux denied access requested by sh. It is not expected that this access is
required by sh and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open a terminal and start vpnc
2. Answer all the required questions
3. When done, you should see a AVC denial message in the notification panel.
Actual results:
AVC denial from the system.
Terminal states the following: /usr/sbin/vpnc: no response from target

Expected results:
Connect to the VPN

Additional info:
Strangely the NetworkManager-vpnc extension is not throwing this error. Now I am
not sure if this is because of the appropriate settings or due to a gobbling of
the exception.
Comment 1 Tomas Mraz 2007-06-12 17:14:58 EDT
Can you please post the full AVC here?

Also is your system updated?
Comment 2 Rogue 2007-06-12 17:17:15 EDT
Wow... that was quick, I was just about to update this bug with the additional
info that I missed out :-)

I really wish I knew more about this stuff so I could help out with the patches
too :-)

Here is the additional info:

Source Context:  system_u:system_r:vpnc_tTarget
Context:  system_u:system_r:vpnc_tTarget Objects:  None [ capability ]Affected
RPM Packages:  Policy RPM:  selinux-policy-2.6.4-13.fc7Selinux
Enabled:  TruePolicy Type:  targetedMLS Enabled:  TrueEnforcing
Mode:  EnforcingPlugin Name:  plugins.catchallHost
Name:  XymnotunePlatform:  Linux Xymnotune 2.6.21-1.3194.fc7 #1 SMP Wed May 23
22:35:01 EDT 2007 i686 i686Alert Count:  7First Seen:  Wed 13 Jun 2007 02:27:56
AM ISTLast Seen:  Wed 13 Jun 2007 02:29:28 AM ISTLocal
ID:  54312e70-4fdd-4d17-ab43-1642e253f5de

Line Numbers:

Raw Audit Messages :

avc: denied { dac_read_search } for comm="sh" egid=0 euid=0 exe="/bin/bash"
exit=-13 fsgid=0 fsuid=0 gid=0 items=0 pid=3505
scontext=system_u:system_r:vpnc_t:s0 sgid=0 subj=system_u:system_r:vpnc_t:s0
suid=0 tclass=capability tcontext=system_u:system_r:vpnc_t:s0 tty=pts1 uid=0 
Comment 3 Tomas Mraz 2007-06-12 17:55:03 EDT
can you please provide output of:

ls -l /etc/vpnc

ls -ld /etc/vpnc
Comment 4 Rogue 2007-06-12 18:25:59 EDT
Output of ls -l /etc/vpnc
total 24
-rw------- 1 root root   119 2007-03-20 18:52 default.conf
-rwxr-xr-x 1 root root 10519 2007-03-20 18:52 vpnc-script

Output of ls -ld /etc/vpnc
drwxr-xr-x 2 root root 4096 2007-06-13 03:51 /etc/vpnc
Comment 5 Tomas Mraz 2007-06-13 04:34:06 EDT
That's apparently OK. The problem is I cannot reproduce this problem here so I'm
really curious what's the difference.

You could try to strace -f it but the strace log would record your passwords so
it is not a good idea to attach it here. Perhaps you could grep the log for
'EACCES' and post only the relevant lines.
Comment 6 Rogue 2007-06-13 10:04:12 EDT

My SELinux Policy is enforcing .. not sure if this could be an issue

Installed strace and ran it as root. The trace file was located in my home
directory, the reason I am mentioning this is one of the EACCES shows that as an

The following are the lines generated with EACCES in them.

3187  stat64("/home/rogue/trace", 0xbfece260) = -1 EACCES (Permission denied)
3187  stat64(".", 0xbfece278)           = -1 EACCES (Permission denied)
3187  stat64("/home/rogue/trace", 0xbfd7e850) = -1 EACCES (Permission denied)
3188  stat64(".", 0xbfd7e1f8)           = -1 EACCES (Permission denied)
3191  stat64(".", 0xbfd7e008)           = -1 EACCES (Permission denied)
3190  stat64(".", 0xbfd7e008)           = -1 EACCES (Permission denied)

Strangely, when I run the program through strace, I do not see the AVC popup
message. Is this expected?
Comment 7 Tomas Mraz 2007-06-13 10:11:56 EDT
Is it possible that the directory you're running vpnc in is not readable by root
without dac override? 'ls -ld .' output?

But I don't think that the vpnc not connecting to the gateway comes from these
SELinux denials.
Comment 8 Rogue 2007-06-13 10:22:32 EDT
A little more testing, showed me that it doesn't matter what the username and
passwords are. I will always get a denial message. So, I am attaching the strace
generated which contains fake username / password details.

And since strace -f will run only as root, I had to do a sudo su, if I try
running it as root (sudo su -), then I get another kind of a denial message,
something to do with vpnc and usr_t. I shall file a separate bug for that one.

As of now, I am attaching the strace log file generated.
Comment 9 Rogue 2007-06-13 10:24:27 EDT
Created attachment 156879 [details]
Output from strace -f on vpnc
Comment 10 Tomas Mraz 2007-06-13 11:19:49 EDT
I think the problem when you run it as root (su -) is similar. The AVCs are
really harmless and are caused by vpnc (when executing the shell script
vpnc-script) doesn't have access to the current directory. You can verify that
running 'cd /etc/vpnc; vpnc' shouldn't generate any AVCs.

Dan, perhaps they can/should be 'dontaudited'? Or I could patch vpnc so it does
chdir('/etc/vpnc') before calling the vpnc-script.
Comment 11 Daniel Walsh 2007-06-14 08:22:56 EDT
Ok in that case they can just be ignored.  It seems that any application that
starts up always does a getattr in the current working directory.  This triggers
the avc.  So if you did this in any directory that did not allow access you
would get this avc.  I don't want to dontaudit all possible directories, so I
guess the best thing is to ignore it.  Or maybe start the app from /.  :^)

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