Re: Help with SELinux policy for Usability Study

[Cliffe <cliffe@xxxxxx>]

Stephen Smalley wrote:

On Thu, 2009-07-30 at 11:50 +0800, Cliffe wrote:
  

Dear SELinux Gurus,

I am a PhD candidate conducting research into the usability of security 
mechanisms. I would really appreciate some help regarding the use of 
SELinux. Let me know if this is not the right place to be asking these 
types of questions.
    

General usability questions, yes.  polgengui however is Fedora-specific
and thus fedora-selinux-list may be a more suitable choice.

You should also take a look at SLIDE, an Eclipse plugin for creating
SELinux policies.  The upstream home page is at:
http://oss.tresys.com/projects/slide/
and the software should be available in Fedora via:
yum install eclipse-slide

  

I generated a policy for opera using polgengui. I then ran the generated 
./opera.sh.

Although SELinux was still set to enforcing mode opera seemed to run 
unconfined. The executable and process was labelled as expected 
(unconfined_u:unconfined_r:opera_t). AVCs were generated, but not enforced.

I added to opera.te using
grep opera /var/log/audit/audit.log | audit2allow >> opera.te
and reran ./opera.sh
until no AVCs were generated.

Looking at opera.te I noticed the line “permissive opera_t”, and not 
knowing exactly what this line does, I thought it may be placing this 
domain into permissive mode (although the gui tools suggest otherwise). 
Removing the line causes “/bin/sh: /usr/bin/opera: Permission denied”. 
No AVCs are generated.
    

Yes, permissive opera_t causes the domain to run in permissive mode
while leaving the rest of the system enforcing.  Per-domain permissive
mode was introduced in Fedora 10, I think.

  

So I am not sure why opera seams to be unconfined, or if removing the 
permissive line was on the right track. Any advice?
    

Yes, removing the permissive line is the right track to take when you
are ready to test in enforcing mode.  If you don't see any AVC denials,
then try running semodule -DB to strip all dontaudit rules from policy
and then re-test, followed by semodule -B again to restore the dontaudit
rules.  This will generate a _lot_ of denials, some of which are
irrelevant, but should then show you all denials.  dontaudit rules are
used to suppress denials that come from harmless application or library
probing (e.g. getcwd) that are not required for operation of the
application, but may sometimes mask real denials.

I'm not sure why polgengui is automatically adding a permissive line in
this case but not in the case of kwrite - Dan?  It should be consistent,
and it really only should do that with user consent as the user needs to
know that the domain is permissive. 
  

It adds the permissive line to both (I am not sure why kwrite seemed to be in enforcing mode). But the gui does not make this clear. I have mentioned this to the fedora-selinux mailing list.

Also I tried creating a policy for kwrite. This time the created policy 
seemed to be in effect as soon as I ran the kwrite.sh script. I set 
setenforce 0 and added to kwrite.te (as above for opera) until no error 
msgs were generated. Then I reran ./kwrite.sh. Now kwrite exists with 
“kwrite(2533): Couldn’t register name ‘”org.kate-editor.kwrite-2533’” 
with DBUS – another process owns it already!”. When setenforce 0 it runs 
without AVCs.
    

Sounds like you are getting a DBUS denial, so look for USER_AVC messages
e.g.
/sbin/ausearch -i -m USER_AVC.
  

None there. It turns out they were in /var/log/messages

so

grep kwrite /var/log/audit/audit.log | audit2allow >> kwrite.te

did the trick. It is strange that some AVCs go to /var/log/messages while others goto

/var/log/audit/audit.log

Thanks for all your advice, it has helped a lot.

Cliffe.