On Fri, Oct 27, 2017 at 07:02:54AM -0700, Peter wrote:

Thanks, I think this is good start.

I think what we'd want to do is write up a feature page. Using https://github.com/cockpit-project/cockpit/wiki/Feature-template

That will help us finish the user stories and design.

I'll rewrite it into the template. Should I create a new page or do you want read and review it somewhere first and then move it to https://github.com/cockpit-project/cockpit/wiki/ ?

I do have some concerns about the dbus api. If it's just a wrapper around semanage and we still need to parse the output. What are the advantages of calling it instead of just running the semanage commands directly from cockpit.

As dbus interface was split from policycoreutils in recent SELinux Userspace release 2.7, it could be rewritten so that it would use libsemanage bindings instead of semanage command. But it's not even on the plan yet so pure speculation.

Currently there's no advantage. It's listed as a possibility as DBUS interface seems to be preferred and for the purpose of the feature it should be sufficient.

Thanks,

Petr

On 10/27/2017 05:35 AM, Petr Lautrbach wrote:

...

Hi,

there's already an epic in trello related to Improved SELinux troubleshooting and Management [1]. There seems to be missing a user story for SELinux management so I put together a document which should cover basic SELinux local policy management using either semanage command or org.selinux DBUS interface:

https://plautrba.fedorapeople.org/manage-local-selinux-policy-in-cockpit.htm...

I'd like to ask you for a review and comments if it makes sense and for help with design for this effort when there's an agreement

[1] https://trello.com/c/WiFrlt4C/381-epic-improved-selinux-troubleshooting-and-...

Thanks,

Petr _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

On Fri, Oct 27, 2017 at 07:38:39AM -0700, Peter wrote:

On 10/27/2017 07:36 AM, Petr Lautrbach wrote:

...

On Fri, Oct 27, 2017 at 07:02:54AM -0700, Peter wrote:

...

Thanks, I think this is good start.

I think what we'd want to do is write up a feature page. Using https://github.com/cockpit-project/cockpit/wiki/Feature-template

That will help us finish the user stories and design.

I'll rewrite it into the template. Should I create a new page or do you want read and review it somewhere first and then move it to https://github.com/cockpit-project/cockpit/wiki/ ?

Starting a new page on the wiki is fine. We can all edit it there.

So the page is here

https://github.com/cockpit-project/cockpit/wiki/Feature:-Manage-SELinux-poli...

There are 2 stories of 2 personas which I think describe expected usage. I'm not sure how to describe Workflows but in Prior Art it's documented as it is now.

...

...

I do have some concerns about the dbus api. If it's just a wrapper around semanage and we still need to parse the output. What are the advantages of calling it instead of just running the semanage commands directly from cockpit.

As dbus interface was split from policycoreutils in recent SELinux Userspace release 2.7, it could be rewritten so that it would use libsemanage bindings instead of semanage command. But it's not even on the plan yet so pure speculation.

Currently there's no advantage. It's listed as a possibility as DBUS interface seems to be preferred and for the purpose of the feature it should be sufficient.

Thanks,

Petr

...

On 10/27/2017 05:35 AM, Petr Lautrbach wrote:

...

Hi,

there's already an epic in trello related to Improved SELinux troubleshooting and Management [1]. There seems to be missing a user story for SELinux management so I put together a document which should cover basic SELinux local policy management using either semanage command or org.selinux DBUS interface:

https://plautrba.fedorapeople.org/manage-local-selinux-policy-in-cockpit.htm...

I'd like to ask you for a review and comments if it makes sense and for help with design for this effort when there's an agreement

[1] https://trello.com/c/WiFrlt4C/381-epic-improved-selinux-troubleshooting-and-...

Thanks,

Petr _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

---

cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org

On Wed, Nov 15, 2017 at 04:23:44PM +0100, Andreas Nilsson wrote:

On 2017-11-13 13:29, Petr Lautrbach wrote:

...

So the page is here

https://github.com/cockpit-project/cockpit/wiki/Feature:-Manage-SELinux-poli...

There are 2 stories of 2 personas which I think describe expected usage. I'm not sure how to describe Workflows but in Prior Art it's documented as it is now.

Looks good to me. Thanks for writing these up! For the stories, what about something like this:

Did you mean workflows?

"Phillip logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. He sets /companywebsite to be accessible by httpd. He then edits /etc/httpd/conf/httpd.conf and sets the configuration parameters necessary. He then creates the public_html folder for each users and set the right permissions. Once that is done he changes the selinux rule to allow users to server web content out of their home directories.

In this scenario I would not expect users to change rules but change boolean values. I'd rephrase the last sentence:

Once that is done he changes the SELinux boolean which allows web server to serve content out of home directories.

He then creates a test user, drops a html-file in /home/testuser/public_html and tests if it's accessible from a web browser. Once it's done he logs out." [1]

"George Cucumber logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. There he changes all user accounts from unconfined to guest. Once it's done, he creates a test user and tries to ping google.com. It won't work, so he's successful. He logs out again."

s/unconfined/unconfined_u/;s/guest/guest_u/

But it looks good.

"Paul logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. He sets the bank_trans_ service to permissive. Once that is done, he logs out again"

I'm not surte about this workflow. I CCed Mirek who's the owner of this idea if he can provide some insight for this.

1. Note that I added the additional steps unrelated to selinux, but

necessary for the workflow to be successful. There is still a big gap before all this is successful only using Cockpit, but I think that's OK for now.

Thanks!

Petr

On 11/16/2017 12:31 PM, Petr Lautrbach wrote:

On Wed, Nov 15, 2017 at 04:23:44PM +0100, Andreas Nilsson wrote:

...

On 2017-11-13 13:29, Petr Lautrbach wrote:

...

So the page is here

https://github.com/cockpit-project/cockpit/wiki/Feature:-Manage-SELinux-poli...

There are 2 stories of 2 personas which I think describe expected usage. I'm not sure how to describe Workflows but in Prior Art it's documented as it is now.

Looks good to me. Thanks for writing these up! For the stories, what about something like this:

Did you mean workflows?

...

"Phillip logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. He sets /companywebsite to be accessible by httpd. He then edits /etc/httpd/conf/httpd.conf and sets the configuration parameters necessary. He then creates the public_html folder for each users and set the right permissions. Once that is done he changes the selinux rule to allow users to server web content out of their home directories.

In this scenario I would not expect users to change rules but change boolean values. I'd rephrase the last sentence:

Once that is done he changes the SELinux boolean which allows web server to serve content out of home directories.

...

He then creates a test user, drops a html-file in /home/testuser/public_html and tests if it's accessible from a web browser. Once it's done he logs out." [1]

"George Cucumber logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. There he changes all user accounts from unconfined to guest. Once it's done, he creates a test user and tries to ping google.com. It won't work, so he's successful. He logs out again."

s/unconfined/unconfined_u/;s/guest/guest_u/

But it looks good.

...

"Paul logs in to the system with Cockpit. He navigates to the section where he can set the SELinux permissions. He sets the bank_trans_ service to permissive. Once that is done, he logs out again">

I'm not surte about this workflow. I CCed Mirek who's the owner of this idea if he can provide some insight for this.

I would like to see a possibility to apply the permissive mode for a selected service which can be listed by "semanage permissive -l"

...

1. Note that I added the additional steps unrelated to selinux, but

necessary for the workflow to be successful. There is still a big gap before all this is successful only using Cockpit, but I think that's OK for now.

Thanks!

Petr