danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Share Next Entry
Setroubleshoot does a nice job nowadays but do people read it?
danwalsh
<whine>
Frustrating:
Getting a bugzillas with an setroubleshoot alert mesage that tells the user user exactly 
what the problem and solution is, and yet the user goes through the GUI looking for the 
Report the Bug button.  

I call this the Bug Dan Walsh Button, although I guess I could call it the Bug Miroslav Grepl 
Button now. 

Then the user waits for a response from a human saying to say 

"Did you read the alert?  It told you what to do." Bugzilla Closed NotABug

All the time the user sits with a broken tool or in permissive mode, when the user could 
have fixed the problem in seconds.  Lots of bugzillas say, XYZ is mislabeled just run restorecon XYZ  :^(

</whine>

Setroubleshoot did a great job of diagnosing this problem.  

It gave the user two good solutions, and one fall back.

Bottom Line, Please read the alert information before reporting a bugzilla.

Of course the tooling in NetworkManager should have done this automatically, but we have a 
bugzilla open for that.

Description of problem:
Upon trying to activate the VPN interface, I received the pop-up advising me that it was blocked. 
SELinux is preventing /usr/sbin/openvpn from 'open' accesses on the file /home/dwalsh/personalVPN/CN00318823.crt.

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

If you want to mv CN00318823.crt to standard location so that openvpn can have open access
Then you must move the cert file to the ~/.cert directory
Do
# mv /home/dwalsh/personalVPN/CN00318823.crt ~/.cert
# restorecon -R -v ~/.cert


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

If you want to modify the label on CN00318823.crt so that openvpn can have open access on it
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t /home/dwalsh/personalVPN/CN00318823.crt
# restorecon -R -v /home/dwalsh/personalVPN/CN00318823.crt


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

If you believe that openvpn should be allowed open access on the CN00318823.crt 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 openvpn /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:openvpn_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                /home/dwalsh/personalVPN/CN00318823.crt [ file ]
Source                        openvpn
Source Path                   /usr/sbin/openvpn
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           openvpn-2.3.2-1.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-73.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.10.10-200.fc19.x86_64 #1 SMP Thu
                              Aug 29 19:05:45 UTC 2013 x86_64 x86_64
Alert Count                   2
First Seen                    2013-09-03 16:46:59 EDT
Last Seen                     2013-09-05 17:57:28 EDT
Local ID                      f008846c-ad32-4676-925c-4a86a1b87a2b

Raw Audit Messages
type=AVC msg=audit(1378418248.924:702): avc:  denied  { open } for  pid=1996 comm="openvpn" path="/home/dwalsh/personalVPN/CN00318823.crt" dev="dm-2" ino=11141302 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file


type=SYSCALL msg=audit(1378418248.924:702): arch=x86_64 syscall=open success=no exit=EACCES a0=7fffcf992f0e a1=0 a2=1b6 a3=7fffcf990410 items=0 ppid=1992 pid=1996 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=openvpn exe=/usr/sbin/openvpn subj=system_u:system_r:openvpn_t:s0 key=(null)

Hash: openvpn,openvpn_t,user_home_t,file,open



While I empathise with the "the tooling gave you enough information you could have figured it out yourself" nature of the post (and have been on the receiving end of a bunch of reports like that), it seems to me that 61 lines of output (of which "If you believe $TOOL should be allowed... access on the $FILE_FOR_TOOL by default... then you should report a bug" is most of the volume, which implies to the skim reader it's more important) isn't exactly helping the less-than-expert user understand that it's not working because they're "doing it wrong".

A couple of suggestions:
1. I'd suggest not displaying the catchall information if there are is at least one (significantly) higher confidence option, unless there's some sort of "I don't like the advice, give me something else" command line option (eg, a --verbose, or --generic advice or --show-workarounds). The default advice can always end with a single line that says something like "run $FOO --show-workarounds for more alternatives". (If there's nothing else to suggest then yes maybe show the catch all by default.)

2. The first two options are functionally identical problems ("the file has the wrong label") yet (a) fail to say explicitly "the file has the wrong label", and (b) fail to point out that there are two ways to have it get correct label (ie, "put it in the standard directory" and "manually set the label on the file") rather than, eg, just being to cargo-cult things to do (the third one, the generic work around, is very cargo-cult). Even just starting with "OpenVPN is not permitted to read files labeled $LABEL_ON_PROBLEM_CRT_FILE; it needs a different label" would seriously improve the usability of the advice for someone in a rush. (I know that's what the audit message means, you know that's what the audit message means, but the average user reporting it to bugzilla clearly doesn't: if they did understand, they'd have relabeled without even needing setroubleshoot.)

Just to be clear, I think setroubleshoot is a huge improvement on the pre-setroubleshoot days. But I also thing there's scope to divert more of the "it's broken, please fix" generic reports by having it provide advice it has figured out in a more readable manner (ie, concise, to the point, with specific fixes).

Ewen

PS: If there's an obvious way that users should be getting those certificates onto the system in such a way that they automatically get labelled correctly, it'd be a really good idea to document that prominently. If every approach requires "do something then run restorecon" then IMHO that's a usability bug, since it's a poor solution to the average use case for using OpenVPN (viz, someone gives you a certificate, you copy it onto your system and try to use it). Just saying.

These are all good ideas, and something we should consider for our next redesign, which should be happening in F21 with full integration into journald. Makeing automatic messages that do not say something stupid is sometimes difficult. But I agree in this case giving the user the option to submit a bug, should be buried.

I also agree that the real bug here is NetworkManager, which I believe the user used to load his Certificate should have fixed the label or copied the Certificate into the ~/.cert or !/.pki directory with the correct label, then the user would never have seen this issue.

You are viewing danwalsh