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.
On Thu, 2009-07-30 at 12:04 +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.
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 makes opera_t a permissive domain indeed. To expose any possible hidden denials run: semodule -DB To hide them again: semodule -B
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.
This is probably a DBUS issue. DBUS is a SELinux object manager. This means that DBUS itself provides classes and permission for some of its objects. Dbus also enforces policy for these objects.
DBUS logs some user avc denials in audit.log (ausearch -m user_avc -ts today | grep dbus)
DBUS also logs some denials in /var/log/messages.
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.
Good luck.
On a unrelated note: I recently created a extensive series of screencasts showing how to confine a GUI app with SELinux (google-gadgets)
http://www.youtube.com/results?search_query=SELinux+confine+a+GUI+app
Thank you,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote:
So I am not sure why opera seams to be unconfined, or if removing the permissive line was on the right track. Any advice?
permissive domains can be used to troubleshoot/develop policy, without exposing the whole system.
eventually, after you've completed the development of your policy , and before you deploy your policy you should remove the permissive domain.
But in development stages a permissive domain makes it easier to debug your policy since everything is allowed but would be denials are logged.
Thank you,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On 07/30/2009 05:15 AM, Dominick Grift wrote:
On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote:
So I am not sure why opera seams to be unconfined, or if removing the permissive line was on the right track. Any advice?
permissive domains can be used to troubleshoot/develop policy, without exposing the whole system.
eventually, after you've completed the development of your policy , and before you deploy your policy you should remove the permissive domain.
But in development stages a permissive domain makes it easier to debug your policy since everything is allowed but would be denials are logged.
Thank you,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash.
We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode.
I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do.
Daniel J Walsh wrote:
On 07/30/2009 05:15 AM, Dominick Grift wrote:
On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote:
So I am not sure why opera seams to be unconfined, or if removing the permissive line was on the right track. Any advice?
permissive domains can be used to troubleshoot/develop policy, without exposing the whole system.
eventually, after you've completed the development of your policy , and before you deploy your policy you should remove the permissive domain.
But in development stages a permissive domain makes it easier to debug your policy since everything is allowed but would be denials are logged.
Thank you,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash.
We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode.
I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do.
Thanks Dan.
I like your polgengui tool. It makes the process of creating SELinux policies less daunting.
When it creates the .te .if and .fc files it says that the next step would be to put the system into permissive mode with setenforce 0. However, it should probably tell the user that the new policy will be in a permissive domain.
I agree that creating a policy for opera is not easy, but it would be a good idea to restrict its actions where possible.
My usability study will involve users using SELinux and your tool (I think it looks simpler than slide), as well as a couple of other systems.
I'll let you know of the results when the study is complete later this year.
Thanks,
Cliffe.
On 07/30/2009 10:17 AM, Cliffe wrote:
Daniel J Walsh wrote:
On 07/30/2009 05:15 AM, Dominick Grift wrote:
On Thu, 2009-07-30 at 12:04 +0800, Cliffe wrote:
So I am not sure why opera seams to be unconfined, or if removing the permissive line was on the right track. Any advice?
permissive domains can be used to troubleshoot/develop policy, without exposing the whole system.
eventually, after you've completed the development of your policy , and before you deploy your policy you should remove the permissive domain.
But in development stages a permissive domain makes it easier to debug your policy since everything is allowed but would be denials are logged.
Thank you,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Cliffe if you remove the permissive line from your te file, SELinux will enforce the policy, however opera will probably crash.
We default to permissive domains when we are building new policy modules, to allow you to record what an application does, and use tools like audit2allow to generate allow rules. Sort of a learning mode.
I would not have picked a tool like opera to build policy for, since it is very difficult to confine web browsers. They are too integrated into the system. You end up basically creating a usr role since the web browser tends to need to do everything the user can do.
Thanks Dan.
I like your polgengui tool. It makes the process of creating SELinux policies less daunting.
When it creates the .te .if and .fc files it says that the next step would be to put the system into permissive mode with setenforce 0. However, it should probably tell the user that the new policy will be in a permissive domain.
I agree that creating a policy for opera is not easy, but it would be a good idea to restrict its actions where possible.
My usability study will involve users using SELinux and your tool (I think it looks simpler than slide), as well as a couple of other systems.
I'll let you know of the results when the study is complete later this year.
Thanks,
Cliffe.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Cliffe
Please CC me any results you find as well as any issues with the gui tools as I'm revamping them for F12.
Christopher Pardy
selinux@lists.fedoraproject.org