Hi Michal,

are you willing to retest your scenario once the updated selinux-policy packages become available?

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

Also could you add your output of

# ps -eZ |grep initrc

[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

If you execute 

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

what AVC are you getting then?

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.

(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

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.

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.

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.

ok ,thanks. I will try it and give feedback.

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.

/var/run/xl2tpd/l2tp-control is mislabled.

restorecon -R -v /var/run/xl2tpd

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

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? :)

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

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.

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)

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:

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.

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)?

issue fixed in bug 860087. this could be also closed right now. many thanks!!

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