Just trying to open a key using networkmanager.

-Erinn

Why are your keys stored in the Document directory?

No real good reason, made sense at the time, so that is where they stayed. But if I understand this denial it would block any directory that is user_home_t, so if my openvpn keys are in a subdirectory of my home directory it won't allow them to be opened? Or is it just the Documents directory?

-Erinn

Move it to ~/.cert and run restorecon on it.

Well, then it may not be directly obvious, as NetworkManager do not tell us to place the certs in .certs. Personnaly, I faced the same issue today in f14. I generated them and copied them from the server.

Yeah... I almost think NM needs a setting to deal with this. Why/how would I know where these need to be.

+1

i can keep certs anywhere...

Reopening and reassigning to NetworkManager. nm-connection-editor should take care of the proper location of the certs.

Same thing here. I have my certs in /home/bartek/Euromaszt/tveurosat/backup/openvpn (don't ask :D) and I get the same SELinux error even with openvpn_enable_homedirs --> on.
I would understand if this variable was false, but I turned it on myself and it still doesn't work. When I move the certs to /etc/openvpn/ it works just fine.

Sorry for the double post (I can't see any "edit" option) but there really should be some kind of information that the certificates should be placed in ~/.cert...

*** Bug 639473 has been marked as a duplicate of this bug. ***

I got bitten by this as well, and it took a while to get this working. I don't think this is an SELinux bug though; NetworkManager is basically allowing configurations it knows cannot work.

Ideally, NetworkManager would offer to either move the relevant certificates for you (if you move them manually you have to update the config manually; NM is deeply unhelpful in managing to forget the previous settings too) or at least put (sym)links in place in .cert/ for you. And then running restorecon or whatever for you if necessary.

I don't especially like the idea of these certs being hidden in a dot directory per se, but NM could be a lot more helpful.

For those who have their home directory under something other than /home/ and/or certs/keys under something other than ~/.cert/ the following may be helpful:

chcon unconfined_u:object_r:home_cert_t:s0 ~/some_cert_dir/*.key
chcon unconfined_u:object_r:home_cert_t:s0 ~/some_cert_dir/*.crt


(discovered by a combination of prior comments here + lots of ls -Z and restorecon)

At the very least setroubleshooter should say that the certs must be labelled with type home_cert_t rather than unexpected access/intrusion attempt.

However, it seems a bit unreasonable to expect a desktop user to jump through all these hoops.

Miroslav, lets let openvpn search user_home_t:dir  I am adding a setroubleshoot plugin to rawhide, soon to F14 that will output something like.

sealert -a /tmp/t
100% donefound 1 alerts in /tmp/t
--------------------------------------------------------------------------------

SELinux is preventing /usr/sbin/openvpn from read access on the file Documents/mycert.

*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If you want to mv mycert to standard location so that openvpn can have read access
Then you must move the cert file to the ~/.cert directory
Do
# mv Documents/mycert ~/.cert
# restorecon -R -v ~/.cert


*****  Plugin openvpn (47.5 confidence) suggests  ****************************

If you want to modify the label on mycert so that openvpn can have read access on it
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t Documents/mycert
# restorecon -R -v Documents/mycert


*****  Plugin catchall (6.38 confidence) suggests  ***************************

If you believe that openvpn should be allowed read access on the mycert file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep /usr/sbin/openvpn /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

I'd like OpenVPN to be able to follow symlinks so I can create back-compat links when I move things to .cert/...

Miroslav, lets let openvpn read user_home_t:lnk_file

userdom_search_user_home_content(openvpn_t)

Should do it.

Fixed in selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-14.fc14

selinux-policy-3.9.7-14.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #21)
> selinux-policy-3.9.7-14.fc14 has been pushed to the Fedora 14 stable
> repository.  If problems still persist, please make note of it in this bug
> report.

no improvement noticed, selinux policy updated to 3.9.7-14.fc14.

error log:


Résumé:

SELinux empêche l'accès en « read » à /usr/sbin/openvpn on
/home/bleubs/Téléchargement/var/www/tuvpn/downloads/tuvpn/usuar

Description détaillée:

[openvpn a un type permissif (openvpn_t). Cet accès n'a pas été refusé.]

SELinux a refusé l'accès demandé par openvpn. Il n'est pas prévu que cet accès
soit requis par openvpn et cet accès peut signaler une tentative d'intrusion. Il
est également possible que cette version ou cette configuration spécifique de
l'application provoque cette demande d'accès supplémenta

Autoriser l'accès:

Vous pouvez créer un module de stratégie locale pour autoriser cet accès - lisez
la FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Merci de
remplir un rapport de bogue.

Informations complémentaires:

Contexte source               system_u:system_r:openvpn_t:s0
Contexte cible                unconfined_u:object_r:user_home_t:s0
Objets du contexte            /home/bleubs/Téléchargement/var/www/tuvpn/downlo
                              ads/tuvpn/usuario.crt [ file ]
source                        openvpn
Chemin de la source           /usr/sbin/openvpn
Port                          <Inconnu>
Hôte                          bleubs
Paquetages RPM source         openvpn-2.1.1-2.fc13
Paquetages RPM cible          
Politique RPM                 selinux-policy-3.9.7-14.fc14
Selinux activé                True
Type de politique             targeted
Mode strict                   Enforcing
Nom du plugin                 catchall
Nom de l'hôte                 bleubs
Plateforme                    Linux bleubs 2.6.35.9-64.fc14.x86_64 #1 SMP Fri
                              Dec 3 12:19:41 UTC 2010 x86_64 x86_64
Compteur d'alertes            2
Première alerte               dim. 05 déc. 2010 11:26:28 CET
Dernière alerte               dim. 05 déc. 2010 11:26:28 CET
ID local                      d4108df2-54c3-46e0-9eb8-a48692eddf3e
Numéros des lignes            

Messages d'audit bruts        

node=bleubs type=AVC msg=audit(1291544788.80:30649): avc:  denied  { read } for  pid=3410 comm="openvpn" name="usuario.crt" dev=sdc5 ino=11671 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

node=bleubs type=AVC msg=audit(1291544788.80:30649): avc:  denied  { open } for  pid=3410 comm="openvpn" name="usuario.crt" dev=sdc5 ino=11671 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

node=bleubs type=SYSCALL msg=audit(1291544788.80:30649): arch=c000003e syscall=2 success=yes exit=6 a0=7fffa6319e3f a1=0 a2=1b6 a3=0 items=0 ppid=3394 pid=3410 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="openvpn" exe="/usr/sbin/openvpn" subj=system_u:system_r:openvpn_t:s0 key=(null)

The policy fix is related to the comment #15. 

The solution for your issue is described in the comment #14.

I can't say that this is a very user friendly approach. NM should be modified to at least warn about this issue, and to handle any restorecon needed when creating .cert. This bug is assigned to NM, but it seems to be closed because of a minor fix to the SELinux policy. Reopen?

Who decided to put the cert file in ~/Documents?

The user. But since the current UI doesn't give you any clues to get things right, we can't really place the blame there. The current NM interface is:

1. User gets certificate by his/her own means to the machine
2. You tell NM where the file is.
3. NM gives the path, as-is, to OpenVPN.

There are no warning, or even suggestions as to where you should store this certificate. You only notice that the VPN refuses to work and you get a complaint from the SELinux tool (which isn't terribly helpful for the average user).

One possible change would be to "import" the certificate into NM instead of just pointing at it. Then NM could copy it to wherever it needs to be to satisfy security considerations.

Yeah, I honestly was a bit confused when I went to configure the vpn that it was asking where the files were. I assumed it would import them. I think I created a .openvpn or something like that to store mine. It really was an issue of - no information, no guidance from the ui. Had there been information someplace it would not have happened. Improving NM to either inform us, or automatically import them would be a great improvement.

Dan Williams what do you think of copying the cert to ~/.pki or ~/.cert?

I'm actually wondering why ~/.pki or ~/.cert. Why not ~/.local/share/NM ? I only say this because there are sooo many .X directories in a homedir.

That is fine also, as long as it is not some random directory picked by the user.

(In reply to comment #28)
> Dan Williams what do you think of copying the cert to ~/.pki or ~/.cert?

You need to make sure the user is aware of the copying if so.  He might want to purge the system of private keys and other sensitive data at a later time and could think it is enough to delete them from ~/stuff/ or whereever.  Perhaps just [sym]link instead of copying?

Tore

symlink would not help since the file would still have the default label user_home_t rather then the correct type home_cert_t.

I see.  But...

(In reply to comment #30)
> ...as long as it is not some random directory picked by the user.

Why not, exactly?  The user has traditionally enjoyed full flexibility in how he chooses to organise his files within his home directory.  For instance, I've traditionally kept my certificates and secret keys within ~/private, and even though GNOME by default set up ~/Documents for me, I keep all of my documents elsewhere.  OpenVPN has never complained about my certificates before, and similarly, OpenOffice.org happily opens documents saved outside of ~/Documents.

What is the actual benefit gained in taking away my freedom to organise $HOME they way I prefer, instead forcing me to place my files of a certain type in a certain location?

~/.cert or ~/.pki don't appear to be mentioned in the FHS or XDG specs either, are these completely arbitrary and Fedora-specific?

Tore

I think he issue is more to do with SELinux, to create a policy you have to label file paths. You can't arbitrarily anywhere I place these are the place to protect.

Another option would be to try to side-step the issue of OpenVPN needing read access in home directories completely. 

Can it be fed the certificate(s) some other way?

Temporary copy of the certificate in say /tmp?

You can store the certificates anywhere you want, but they have to be labeled correctly.  And we do have precedence for this.  sshd requires content in ~/.ssh directory.  Apache to some degree requires content in public_html/

If you want to store your data in ~/secrets, you can but you need to tell SELinux about it.

# semanage fcontext -a -t home_cert_t "PATHTO/secrets(/.*)?'
# restorecon -R -v PATHTO/secrets

Will change the labeling and allow openconnect access.

The default labeling has

/home/[^/]*/\.pki(/.*)?	unconfined_u:object_r:home_cert_t:s0
/home/[^/]*/\.cert(/.*)?	unconfined_u:object_r:home_cert_t:s0

I've noticed that the chcon approach breaks now and then. Not sure why, but for some reason my certificate gets reset to the default context now and then...

Has Dan had the time to look at any interface improvements here yet?

chcon is not permanant, you need to use semanage fcontext ... to modify the SELinux data store.  Pierre what is the path to the  files?

Is the directory or the certs being recreated?

And I take it you are referring to Dan Williams?

(In reply to comment #38)
> chcon is not permanant, you need to use semanage fcontext ... to modify the
> SELinux data store.  Pierre what is the path to the  files?
> 

Ah. The cert is straight up in the home dir as ~/.drzeus.ca

> Is the directory or the certs being recreated?

Nope, at least not to my knowledge. :)

> 
> And I take it you are referring to Dan Williams?

Yes.

Can you put it in ~/.cert/ or ~/.pki/ and run restorecon -R -v ~/.pki ~/.cert

Then everything should work.

I'm sorry but this may not be a SELinux bug however it *IS* a bug (so I'm reopenening for NM devs). There is absolutely *NO* indication as to where these files should be. If they should be in ~/.pki or ~/.cert then why is it asking for you to browse to individual key, cert etc files. That implies that I can store it anywhere. The NM ui needs some changes to fix this.

To fix this one of three possible solutions should happen.

NM vpn configuration should either just ask for the 'name' of the connection that it will find in ~/.pki or ~/.cert and the user is expected to name them after the connection or something like that.

OR

NM should move the files into that location as you browse for each file required.

OR

NM should tell the user that the access was denied and that by convention they should be stored in ~/.pki or ~/.cert

I have just installed F15 on a new laptop and been bitten by this exact same issue.

Same same on f15.

[root@re ~]# semanage fcontext -l |grep cert_t
/etc/httpd/alias(/.*)?                             all files          system_u:object_r:cert_t:s0 
/etc/pki(/.*)?                                     all files          system_u:object_r:cert_t:s0 
/etc/pki/dovecot(/.*)?                             all files          system_u:object_r:dovecot_cert_t:s0 
/home/[^/]*/\.certs(/.*)?                          all files          system_u:object_r:home_cert_t:s0 
/root/\.cert(/.*)?                                 all files          system_u:object_r:home_cert_t:s0 
/usr/share/ssl/certs(/.*)?                         all files          system_u:object_r:cert_t:s0 
/usr/share/ssl/certs/dovecot\.pem                  regular file       system_u:object_r:dovecot_cert_t:s0 
/usr/share/ssl/private(/.*)?                       all files          system_u:object_r:cert_t:s0 
/usr/share/ssl/private/dovecot\.pem                regular file       system_u:object_r:dovecot_cert_t:s0 
/var/named/chroot/etc/pki(/.*)?                    all files          system_u:object_r:cert_t:s0 


Workaround as explained above, by placing certificate files in ~/.cert/ , and then run as root

# semanage fcontext -a -t home_cert_t "/home/[^/]*/\.cert(/.*)?"
# restorecon -R -v /home/*/.cert/*

I'd rather also agree that this is an application bug. There is no way the user can guess this. Symlinks or GUI hints, please.

You do not need to add a file context specification for ~/.cert or ~/.pki. It is already specified in policy.

Als you have to do is create the directory and if you are running in a gui and have policycoreutils-restorecond installed then it will make sure that it is labelled correctly.

There was a bug in f15 where policycoreutils-restorecond was not installed in a default installation

In Fedora16 we added functionality so that polictcoreutils-restorecond is no longer needed  and so that those directories will be create with the proper context automatically.

The reason that you cannot list home directory context specification with semanage fcontext -l is that the home directory contexts are treated differently. The are generated with a tool called genhomedircon and are stored in /etc/selinux/$TYPE/contexts/files/context.homedirs (i might have the path wrong a bit here)

As pointed out earlier, semanage does not list homedir items. They are handled by genhomedircon instead.

# grep cert /etc/selinux/targeted/contexts/files/file_contexts.homedirs 
/home/[^/]*/\.pki(/.*)? unconfined_u:object_r:home_cert_t:s0
/home/[^/]*/\.cert(/.*)?        unconfined_u:object_r:home_cert_t:s0

Sorry for the confusion.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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 problem still affects Fedora 20 Alpha.

No user interaction should be required when importing an openvpn configuration into network-manager. It should the certs automatically in the correct directories.

Duplicate? https://bugzilla.redhat.com/show_bug.cgi?id=890361

What issue are you exactly getting?

I put a vpn config file and respective cert files somewhere under /home/yyy/ (but not in /home/yyy/.cert). When connecting to the vpn I get the error message "SELinux is preventing /usr/sbin/openvpn "search" access on
/home/yyy/zzz.". The enduser should not have to learn aber SELinux, the .certs folder,... NetworkManager-openvpn should take care of this (e.g. by copying the certs under /home/yyy/.certs).

Forgot to mention that I import the vpn config file in NetworkMangager.

There is an open bug for this under NetworkManager.