Help with SELinux policy for Usability Study

Help with SELinux policy for Usability Study

[Cliffe]

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.

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.

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

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.

Again I am sure I am missing something simple and your advice will help 
a lot.

I need to resolve this asap and will really appreciate any advice.

Soon I will be running a comparative study comparing a number of 
security mechanisms and I need to sort this out.

Thank you,

Cliffe.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Help with SELinux policy for Usability Study

[Stephen Smalley]

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. 

> 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

> Again I am sure I am missing something simple and your advice will help 
> a lot.
> 
> I need to resolve this asap and will really appreciate any advice.
> 
> Soon I will be running a comparative study comparing a number of 
> security mechanisms and I need to sort this out.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Help with SELinux policy for Usability Study

[Cliffe]

[-- Attachment #1: Type: text/plain, Size: 3910 bytes --]



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.


[-- Attachment #2: Type: text/html, Size: 4738 bytes --]

Re: Help with SELinux policy for Usability Study

[Cliffe]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]



Cliffe wrote:
> Stephen Smalley wrote:
>> 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.
>   
(sorry, typo should read:)

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

did the trick.

[-- Attachment #2: Type: text/html, Size: 1104 bytes --]

Re: Help with SELinux policy for Usability Study

[Stephen Smalley]

On Thu, 2009-07-30 at 22:24 +0800, Cliffe wrote:
> 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.

Perhaps kwrite isn't actually running in kwrite_t at all.  Note that kde
has historically had a problem with launching all applications via a
single kde-init program, thereby preventing automatic domain transitions
on the specific application from working.  Not sure if that has been
fixed.  I don't use KDE.

> 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

That seems like a bug to me in dbus.

Again, I'd suggest that you also include SLIDE in your study - it will
add a further data point and is a more flexible solution, even if it may
be slightly harder to get started.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Help with SELinux policy for Usability Study

[Daniel J Walsh]

On 07/30/2009 10:44 AM, Stephen Smalley wrote:
> On Thu, 2009-07-30 at 22:24 +0800, Cliffe wrote:
>> 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.
> 
> Perhaps kwrite isn't actually running in kwrite_t at all.  Note that kde
> has historically had a problem with launching all applications via a
> single kde-init program, thereby preventing automatic domain transitions
> on the specific application from working.  Not sure if that has been
> fixed.  I don't use KDE.
> 
>> 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
> 
> That seems like a bug to me in dbus.
> 
> Again, I'd suggest that you also include SLIDE in your study - it will
> add a further data point and is a more flexible solution, even if it may
> be slightly harder to get started.
> 

BTW, if you use the sepolgen command line that is in F11 and Rawhide, it has new features to examine the executable and rpm information to generate more data automatigically.  It is using the same framework that polgengui is using. 

You can execute

sepolgen /usr/sbin/myapp

And it will generate the myapp,te, if, fc, sh file automatically, No gui to walk though.

For example it will look for paths in the rpm that match /var/run/myapp, /var/lib/myapp ... and create proper types.
It also runs nm -D /usr/sbin/myapp looking for function calls that it knows require certain interfaces,  If it find syslog it will add the 

logging_send_syslog_msg(myapp_t) 

call.

I have not merged this stuff back into the GUI yet.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Help with SELinux policy for Usability Study

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4520 bytes --]

On Thu, 2009-07-30 at 22:24 +0800, Cliffe wrote:
> 
> 
> 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.

I suspect this was due to dbus. kwrite_t may have been permissive but
other domains that needed interaction with kwrite to make it work were
enforced. So that why it seems that kwrite was enforced but really was
not.


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

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Help with SELinux policy for Usability Study

[Cliffe]

[-- Attachment #1: Type: text/plain, Size: 2595 bytes --]

Daniel J Walsh wrote:
> BTW, if you use the sepolgen command line that is in F11 and Rawhide, it has new features to examine the executable and rpm information to generate more data automatigically.  It is using the same framework that polgengui is using. 
>
> You can execute
>
> sepolgen /usr/sbin/myapp
>
> And it will generate the myapp,te, if, fc, sh file automatically, No gui to walk though.
>
> For example it will look for paths in the rpm that match /var/run/myapp, /var/lib/myapp ... and create proper types.
> It also runs nm -D /usr/sbin/myapp looking for function calls that it knows require certain interfaces,  If it find syslog it will add the 
>
> logging_send_syslog_msg(myapp_t) 
>
> call.
>
> I have not merged this stuff back into the GUI yet.
>   

Thanks. They sound like helpful features. They sound similar to some of 
the techniques my own tool uses.

I tested sepolgen with a few apps. Since the results still require a 
very similar amount of manual editing it is probably fairest to use the 
gui tool as much as possible as the other systems participants will use 
all use gui policy management tools.

Some information about the study:
    - Participants will be shown a prerecorded explanation and 
demonstration of SELinux
    - And have a limited amount of time to confine some programs
    - I don't want to go into too much detail here until the study is 
complete

Justification for using polgengui:
    - It ships standard with fedora
    - It has a gui (like the other tools they will be using)
    - It has a short learning curve (as opposed to perhaps SLIDE, which 
appears to be a more comprehensive tool for policy design but maybe not 
as suited to the average user)

Some questions:
Does SLIDE automate more of the process, such as adding to the created 
policy?
Is there a tool or command to put a domain into enforcing mode rather 
than manually editing the .te file? (system-config-selinux seems to 
think it is already in enforcing mode)

Some suggestions:
It might be a good idea to make the gui tools such as setroubleshoot 
aware of permissive domains, as it simply says that selinux enforcing 
mode is on.
It may be a good idea to create a gui tool which steps users through the 
process of adding to a .te file using audit2allow (if one doesn't exist 
already).

Christopher Pardy wrote:
> Please CC me any results you find as well as any issues with the gui tools as I'm revamping them for F12.
>   
Sure. Participants will give feedback such as suggestions for improvement.

Thanks again everyone for your advice and suggestions,

Cliffe.

[-- Attachment #2: Type: text/html, Size: 3171 bytes --]

Re: Help with SELinux policy for Usability Study

[Daniel J Walsh]

On 07/30/2009 09:57 PM, Cliffe wrote:
> Daniel J Walsh wrote:
>> BTW, if you use the sepolgen command line that is in F11 and Rawhide,
>> it has new features to examine the executable and rpm information to
>> generate more data automatigically.  It is using the same framework
>> that polgengui is using.
>> You can execute
>>
>> sepolgen /usr/sbin/myapp
>>
>> And it will generate the myapp,te, if, fc, sh file automatically, No
>> gui to walk though.
>>
>> For example it will look for paths in the rpm that match
>> /var/run/myapp, /var/lib/myapp ... and create proper types.
>> It also runs nm -D /usr/sbin/myapp looking for function calls that it
>> knows require certain interfaces,  If it find syslog it will add the
>> logging_send_syslog_msg(myapp_t)
>> call.
>>
>> I have not merged this stuff back into the GUI yet.
>>   
> 
> Thanks. They sound like helpful features. They sound similar to some of
> the techniques my own tool uses.
> 
> I tested sepolgen with a few apps. Since the results still require a
> very similar amount of manual editing it is probably fairest to use the
> gui tool as much as possible as the other systems participants will use
> all use gui policy management tools.
> 
> Some information about the study:
>    - Participants will be shown a prerecorded explanation and
> demonstration of SELinux
>    - And have a limited amount of time to confine some programs
>    - I don't want to go into too much detail here until the study is
> complete
> 
> Justification for using polgengui:
>    - It ships standard with fedora
>    - It has a gui (like the other tools they will be using)
>    - It has a short learning curve (as opposed to perhaps SLIDE, which
> appears to be a more comprehensive tool for policy design but maybe not
> as suited to the average user)
> 
> Some questions:
> Does SLIDE automate more of the process, such as adding to the created
> policy?
> Is there a tool or command to put a domain into enforcing mode rather
> than manually editing the .te file? (system-config-selinux seems to
> think it is already in enforcing mode)
> 
> Some suggestions:
> It might be a good idea to make the gui tools such as setroubleshoot
> aware of permissive domains, as it simply says that selinux enforcing
> mode is on.
Currently the information is there in the avc, success=True, indicates that the AVC while reported, did not cause the SYSCALL to fail, usually this means either the domain or system is in permissive mode.  Currently setools does not reveal
whether a domain is permissive or not,  this is something we want to add.  The setroubleshoot could reveal this.
> It may be a good idea to create a gui tool which steps users through the
> process of adding to a .te file using audit2allow (if one doesn't exist
> already).
> 
Patches welcome.  :^)

We have thought about this, but currently do not have the cycles.

> Christopher Pardy wrote:
>> Please CC me any results you find as well as any issues with the gui
>> tools as I'm revamping them for F12.
>>   
> Sure. Participants will give feedback such as suggestions for improvement.
> 
> Thanks again everyone for your advice and suggestions,
> 
> Cliffe.
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Help with SELinux policy for Usability Study

[Cliffe]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Daniel J Walsh wrote:
> On 07/30/2009 09:57 PM, Cliffe wrote:
>   
>> It may be a good idea to create a gui tool which steps users through the
>> process of adding to a .te file using audit2allow (if one doesn't exist
>> already).
>>     
> Patches welcome.  :^)
>
> We have thought about this, but currently do not have the cycles.
>   
:) I have some ideas to simplify and clarify the process. I'll see if I 
have some time (later in the year|early next year) after I have 
submitted my thesis.

[-- Attachment #2: Type: text/html, Size: 899 bytes --]