Bug 849745 - SELinux prevents pppd from working in targeted mode when using L2TP IPSec mode
SELinux prevents pppd from working in targeted mode when using L2TP IPSec mode
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Miroslav Grepl
Michal Trunecka
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-20 14:18 EDT by Michal Bruncko
Modified: 2014-09-30 19:33 EDT (History)
4 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-168.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 03:27:58 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Bruncko 2012-08-20 14:18:12 EDT
Description of problem:
I am using RHEL6 as VPN IPSec/L2TP concentrator with following components:
- xl2tpd-1.3.1-4.el6.x86_64 (which incorporates changes about PPPOL2TP part)
- ppp-2.4.5-5.el6 with patch from https://bugzilla.redhat.com/show_bug.cgi?id=815128 - which enables pppol2tp module for pppd
- ipsec-tools-0.8.0-3.el6.x86_64

Currently, when you try to connect to IPSec/L2TP server via VPN client (i.e. with incorporated win7 ipsec client) connection will not be established. 

From logs:

ipsec/l2tp/ppp log:
(...)
Aug 17 21:57:55 vpn01 pppd[10574]: Warning: can't open options file /root/.ppprc: Permission denied
Aug 17 21:57:55 vpn01 pppd[10574]: Plugin radius.so loaded.
Aug 17 21:57:55 vpn01 pppd[10574]: RADIUS plugin initialized.
Aug 17 21:57:55 vpn01 pppd[10574]: Plugin radattr.so loaded.
Aug 17 21:57:55 vpn01 pppd[10574]: RADATTR plugin initialized.
Aug 17 21:57:55 vpn01 pppd[10574]: Plugin pppol2tp.so loaded.
Aug 17 21:57:55 vpn01 pppd[10574]: Given FD for PPPoL2TP socket invalid (Bad file descriptor) <<<<<<<<<<<<<<<<<<<<<<<<<<
Aug 17 21:57:55 vpn01 pppd[10574]: Exit.
Aug 17 21:57:55 vpn01 xl2tpd[10515]: child_handler : pppd exited for call 1 with code 1
(...)

audit.log:
type=AVC msg=audit(1345484519.303:1460): avc:  denied  { getattr } for  pid=7779 comm="pppd" scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=socket
type=SYSCALL msg=audit(1345484519.303:1460): arch=c000003e syscall=51 success=yes exit=0 a0=8 a1=7fff0f411100 a2=7fff0f41118c a3=1999999999999999 items=0 ppid=7085 pid=7779 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=84 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:system_r:pppd_t:s0 key=(null)
type=AVC msg=audit(1345484519.303:1461): avc:  denied  { getopt } for  pid=7779 comm="pppd" scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=socket
type=AVC msg=audit(1345485667.313:1510): avc:  denied  { read } for  pid=9007 comm="pppd" name="dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1345485667.313:1510): avc:  denied  { open } for  pid=9007 comm="pppd" name="dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1345485667.313:1511): avc:  denied  { getattr } for  pid=9007 comm="pppd" path="/usr/share/radiusclient-ng/dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file

How reproducible:
- always with current version components
- when I disable selinux with "setenforce 0", I can immediately use IPSec/L2TP VPN service

  
Actual results:
client are unable connect to IPSec/L2TP VPN server due error of pppd daemon due of "Given FD for PPPoL2TP socket invalid (Bad file descriptor)" error.

Expected results:
connection via pppd should continue without this error

Additional info:
- before updating of xl2tpd (xl2tpd-1.3.1-1.el6.x86_64) and ppp (original ppp-2.4.5-5.el6) components, everything was working as expected with targeted SELinux mode.
- within pppd authentication, I am using ppp radius.so module in conjuction with radiusclient-ng.
- I dont know if this is related: https://bugzilla.redhat.com/show_bug.cgi?id=833557
- those mentioned AVC denied messages are probably not all, because even when I did custom exceptions (within local module using, audit2allow and recompiling), I can't still connect to VPN server when SELinux is enabled (same pppd error about file descriptor).

Log of pppd with working VPN connection:
(...)
Aug 20 20:15:04 vpn01 pppd[10104]: Plugin radius.so loaded.
Aug 20 20:15:04 vpn01 pppd[10104]: RADIUS plugin initialized.
Aug 20 20:15:04 vpn01 pppd[10104]: Plugin radattr.so loaded.
Aug 20 20:15:04 vpn01 pppd[10104]: RADATTR plugin initialized.
Aug 20 20:15:04 vpn01 pppd[10104]: Plugin pppol2tp.so loaded.
Aug 20 20:15:04 vpn01 pppd[10104]: pppd 2.4.5 started by username, uid 0
Aug 20 20:15:04 vpn01 pppd[10104]: using channel 21
Aug 20 20:15:04 vpn01 pppd[10104]: Starting negotiation on
Aug 20 20:15:04 vpn01 pppd[10104]: Overriding mtu 1500 to 1410
Aug 20 20:15:04 vpn01 pppd[10104]: PPPoL2TP options: debugmask 0
Aug 20 20:15:04 vpn01 pppd[10104]: Overriding mru 1500 to mtu value 1410
Aug 20 20:15:04 vpn01 pppd[10104]: sent [LCP ConfReq id=0x1 <mru 1410> <asyncmap 0x0> <auth eap> <magic 0xf946c3c5> <mrru 1410> <endpoint [MAC:02:14:aa:aa:aa:aa]>]
(...)
Comment 2 Milos Malik 2012-08-21 03:46:33 EDT
Hi Michal,

are you willing to retest your scenario once the updated selinux-policy packages become available?
Comment 3 Michal Bruncko 2012-08-21 03:59:20 EDT
Hi Milos.
Sure, I can do it. But be aware that those provided AVC messages are probably not all which are needed to be handled/allowed. Even when I created exceptions for all those AVCs, I can't still connect to VPN service when IPSec is in targeted mode.
But I cant see more AVCs in audit.log even I switch selinux mode to permissive mode.
Thanks
Comment 4 Miroslav Grepl 2012-08-21 06:47:53 EDT
Also could you add your output of

# ps -eZ |grep initrc
Comment 5 Michal Bruncko 2012-08-21 07:25:07 EDT
[root@vpn01 ~]# ps -eZ |grep initrc
system_u:system_r:initrc_t:s0     991 ?        00:00:00 sleep
system_u:system_r:initrc_t:s0    1093 ?        00:00:05 xe-daemon
system_u:system_r:initrc_t:s0    1451 ?        00:00:00 dhcp-helper
system_u:system_r:initrc_t:s0    1571 ?        00:00:00 pptpd
unconfined_u:system_r:initrc_t:s0 6829 ?       00:00:00 keepalived
unconfined_u:system_r:initrc_t:s0 6831 ?       00:00:00 keepalived
unconfined_u:system_r:initrc_t:s0 6832 ?       00:00:04 keepalived
unconfined_u:system_r:initrc_t:s0 7085 ?       00:00:00 xl2tpd
Comment 6 Miroslav Grepl 2012-08-21 09:33:30 EDT
If you execute 

# chcon -t pppd_exec_t PATHO/pptpd
# service pptpd restart

what AVC are you getting then?
Comment 7 Michal Bruncko 2012-08-21 10:22:32 EDT
you sure with pptpd? this is not used in my scenario right now? this report is about xl2tpd. But wait a moment I will provide outputs from this.
Comment 8 Michal Bruncko 2012-08-21 13:31:44 EDT
(In reply to comment #6)
> If you execute 
> 
> # chcon -t pppd_exec_t PATHO/pptpd
> # service pptpd restart
> 
> what AVC are you getting then?

I dont know if I understand what you're requested...

[root@vpn01 ~]#chcon -t pppd_exec_t PATHO/pptpd
chcon: cannot access `PATHO/pptpd': No such file or directory

what is "PATHO"? And you are sure that changing context for unrelated daemon "pptpd"?

thanks
Comment 9 Daniel Walsh 2012-08-22 07:47:10 EDT
Try 
which pptpd
to get the path.

Probably /usr/sbin/pptpd

This executable should be running with a different label, if you used the package shipped with RHEL.
Comment 10 Michal Bruncko 2012-08-22 08:09:17 EDT
Daniel, ok, understand now... I guessed that this is about changing socket context and not binary on filesystem.
But.. make it sence to changing context of pptpd binary if it is not used in my scenario? this is not about PPTP+PPP VPN, but it is about IPSEC+L2TP+PPP VPN.
But ok... I can do it at evening.
Comment 11 Miroslav Grepl 2012-08-22 09:24:54 EDT
Ok, then the problem could be with

unconfined_u:system_r:initrc_t:s0 7085 ?       00:00:00 xl2tpd

which is going to be fixed in RHEL6.4.
Comment 12 Michal Bruncko 2012-08-22 09:45:45 EDT
ok ,thanks. I will try it and give feedback.
Comment 13 Michal Bruncko 2012-08-24 03:29:06 EDT
hmm, tried to change context of xl2tpd, but there are currently more issues needed to be handled:
Aug 24 09:25:49 vpn01 xl2tpd[12831]: open_controlfd: Unable to open /var/run/xl2tpd/l2tp-control for reading.

and from audit.log:
type=AVC msg=audit(1345792214.917:360): avc:  denied  { name_bind } for  pid=11756 comm="xl2tpd" src=1701 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
type=AVC msg=audit(1345792582.218:362): avc:  denied  { create } for  pid=12111 comm="xl2tpd" name="l2tp-control" scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1345793148.523:379): avc:  denied  { read } for  pid=12817 comm="xl2tpd" name="l2tp-control" dev=dm-5 ino=384 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1345793149.722:380): avc:  denied  { unlink } for  pid=12831 comm="xl2tpd" name="l2tp-control" dev=dm-5 ino=384 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=fifo_file
type=AVC msg=audit(1345793149.723:381): avc:  denied  { read } for  pid=12831 comm="xl2tpd" name="l2tp-control" dev=dm-5 ino=384 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=fifo_file

Ok, I will wait for fixing https://bugzilla.redhat.com/show_bug.cgi?id=833557 in RHEL6.4.
Comment 15 Daniel Walsh 2012-09-11 07:58:51 EDT
/var/run/xl2tpd/l2tp-control is mislabled.

restorecon -R -v /var/run/xl2tpd
Comment 16 Michal Bruncko 2012-09-20 13:24:05 EDT
tried latest selinux-policy-3.7.19-160.el6.noarch.rpm (and all dependencies) from http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/ as I am using CentOS and there is a bit delay between pusing updates into Centos repo....

Now I can see that there is new policy module installed in filesystem: /usr/share/selinux/targeted/l2tpd.pp.bz2.

but when I type "semodule -l", I dont see this module loaded:

[root@vpn01 ~]# semodule -l | grep l2
fail2ban        1.3.2

So I tried to load l2tpd policy with following results:
[root@vpn01 ~]# semodule -i /usr/share/selinux/targeted/l2tpd.pp.bz2
libsepol.print_missing_requirements: l2tpd's global requirements were not met: type/attribute l2tp_server_packet_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Whats going on? What I am doing wrong?

thanks 

michal
Comment 17 Michal Bruncko 2012-09-20 14:07:02 EDT
Ok, update:
Checked the http://people.redhat.com/dwalsh/SELinux/RHEL6/noarch/ directory today and there is new selinux policy version - selinux-policy-targeted-3.7.19-162.el6.noarch so I tried it with following results:

- I performered classic rpm -ivhU <> update
- performed reboot of server
- in output from " semodule -l" I can see finally l2tpd:
[root@vpn01 ~]# semodule -l | grep l2
fail2ban        1.3.2
l2tpd   1.0.0

- I completely rebuild context on whole FS:
[root@vpn01 ~]# restorecon -R -v /

- but the VPN connection is still broken:
Sep 20 19:57:41 vpn01 pppd[2136]: Plugin radius.so loaded.
Sep 20 19:57:41 vpn01 pppd[2136]: RADIUS plugin initialized.
Sep 20 19:57:41 vpn01 pppd[2136]: Plugin radattr.so loaded.
Sep 20 19:57:41 vpn01 pppd[2136]: RADATTR plugin initialized.
Sep 20 19:57:41 vpn01 pppd[2136]: Plugin pppol2tp.so loaded.
Sep 20 19:57:41 vpn01 pppd[2136]: Given FD for PPPoL2TP socket invalid (Bad file descriptor)
Sep 20 19:57:41 vpn01 pppd[2136]: Exit.
Sep 20 19:57:41 vpn01 xl2tpd[2027]: child_handler : pppd exited for call 1 with code 1
Sep 20 19:57:41 vpn01 xl2tpd[2027]: call_close: Call 61569 to 109.230.36.216 disconnected

- then I tried same with "setenforce 0", because after failed VPN connection attempt I have not seen any "denied" messages in audit.log.
- with "setenforce 0" I have successfully connected to VPN server and here is output from audit.log:
type=SYSCALL msg=audit(1348163948.048:46): arch=c000003e syscall=44 success=yes exit=128 a0=6 a1=7fe6e7e63970 a2=80 a3=0 items=0 ppid=1 pid=1166 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="racoon" exe="/usr/sbin/racoon" subj=system_u:system_r:racoon_t:s0 key=(null)
type=AVC msg=audit(1348163950.118:47): avc:  denied  { getattr } for  pid=2243 comm="pppd" scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:system_r:l2tpd_t:s0 tclass=socket
type=SYSCALL msg=audit(1348163950.118:47): arch=c000003e syscall=51 success=yes exit=0 a0=8 a1=7ffffa9f5fb0 a2=7ffffa9f603c a3=1999999999999999 items=0 ppid=2027 pid=2243 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:system_r:pppd_t:s0 key=(null)
type=AVC msg=audit(1348163950.118:48): avc:  denied  { getopt } for  pid=2243 comm="pppd" scontext=unconfined_u:system_r:pppd_t:s0 tcontext=unconfined_u:system_r:l2tpd_t:s0 tclass=socket
type=SYSCALL msg=audit(1348163950.118:48): arch=c000003e syscall=55 success=yes exit=0 a0=8 a1=111 a2=1 a3=7ffffa9f6038 items=0 ppid=2027 pid=2243 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:system_r:pppd_t:s0 key=(null)
type=AVC msg=audit(1348163952.154:49): avc:  denied  { read } for  pid=2243 comm="pppd" name="dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=AVC msg=audit(1348163952.154:49): avc:  denied  { open } for  pid=2243 comm="pppd" name="dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1348163952.154:49): arch=c000003e syscall=2 success=yes exit=9 a0=7ff041279510 a1=0 a2=1b6 a3=0 items=0 ppid=2027 pid=2243 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:system_r:pppd_t:s0 key=(null)
type=AVC msg=audit(1348163952.154:50): avc:  denied  { getattr } for  pid=2243 comm="pppd" path="/usr/share/radiusclient-ng/dictionary" dev=dm-1 ino=27491 scontext=unconfined_u:system_r:pppd_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=file
type=SYSCALL msg=audit(1348163952.154:50): arch=c000003e syscall=5 success=yes exit=0 a0=9 a1=7ffffa9f5990 a2=7ffffa9f5990 a3=0 items=0 ppid=2027 pid=2243 auid=10000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="pppd" exe="/usr/sbin/pppd" subj=unconfined_u:system_r:pppd_t:s0 key=(null)


any help please? :)
Comment 18 Michal Bruncko 2012-09-20 15:48:36 EDT
Ok, I have created local policy to avoid avc denied messages from previous post via audit2allow: 
module local 1.0;

require {
        type l2tpd_t;
        type pppd_t;
        type usr_t;
        class socket { getopt getattr };
        class file { read getattr open };
}

#============= pppd_t ==============
allow pppd_t l2tpd_t:socket { getopt getattr };
allow pppd_t usr_t:file { read getattr open };

with compiling, creating and loading into kernel.

But results are same - currently witout any AVC Denied messages in audit.log in any selinux mode (targetted or permissive), but I can't still create VPN connection due same error:
Sep 20 19:57:41 vpn01 pppd[2136]: Given FD for PPPoL2TP socket invalid (Bad file descriptor)
Sep 20 19:57:41 vpn01 pppd[2136]: Exit.
Sep 20 19:57:41 vpn01 xl2tpd[2027]: child_handler : pppd exited for call 1 with code 1
Comment 19 Miroslav Grepl 2012-09-21 05:48:27 EDT
Ok, if it does now work in permissive mode then a problem will be also with pppd. Could you also open a new bug for pppd?

I will fix those AVC msgs.
Comment 20 Michal Bruncko 2012-09-21 05:58:14 EDT
But this was always working in permissive mode. Do you think that there should be special selinux module created also for pppd? 
Ok, no problem, I can open new bug. 
But there is one thing: currently I am not able to identify from audit.log, what is the reason for blocking of pppd. I just know that in permissive mode the pppd is continuing with connection establishing, but in tagreted mode it fails with 

Given FD for PPPoL2TP socket invalid (Bad file descriptor)
Comment 21 Miroslav Grepl 2012-09-21 08:43:26 EDT
Ah, I thought it does not work also in permissive mode

>But results are same - currently witout any AVC Denied messages in audit.log in >any selinux mode (targetted or permissive), but I can't still create VPN >connection due same error:
Comment 22 Michal Bruncko 2012-09-24 18:11:46 EDT
Sorry, my fault in my english explanation probably :) I meant that: No AVC messages was logged in targeted nor in permissive mode.

Connection always worked in permissive mode.
Comment 23 Michal Bruncko 2012-09-24 18:40:14 EDT
Ok, now I found the main issue of this. When I appended additional "read" and "write" allowed operations for pppd on l2tpd_t socked to existing local selinux policy I can finally connect to VPN server in selinux targeted mode :)

I just appended "read" and "write" operations into locally-generated policy (based on previous AVC messages):

require {
        type l2tpd_t;
        type pppd_t;
        type usr_t;
        class socket { getopt getattr };
        class file { read getattr open };
}

#============= pppd_t ==============
allow pppd_t l2tpd_t:socket { getopt getattr };
allow pppd_t usr_t:file { read getattr open };


and here is final policy which is working for me:

require {
        type l2tpd_t;
        type pppd_t;
        type usr_t;
        class socket { getopt getattr read write };
        class file { read getattr open };
}

#============= pppd_t ==============
allow pppd_t l2tpd_t:socket { getopt getattr read write };
allow pppd_t usr_t:file { read getattr open };



There is only one question: why auditd does not catch prohibited operation "read" or "write" of pppd daemon (even in case that oeprations "getopt getattr" was allready enabled via local selinux policy)?
Comment 25 Michal Bruncko 2012-10-11 17:31:24 EDT
issue fixed in bug 860087. this could be also closed right now. many thanks!!
Comment 27 errata-xmlrpc 2013-02-21 03:27:58 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0314.html

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