I worked on some mockups for system-config-selinux today. Not complete yet, but take a look and let me know what you think so far:
https://fedoraproject.org/wiki/Design/SELinuxConfig
Dearadh Oscailte Abú! (Open Design Forever!)
I worked on some mockups for system-config-selinux today. Not complete yet, but take a look and let me know what you think so far:
https://fedoraproject.org/wiki/Design/SELinuxConfig
Hi,
My crits are:
1) Do you need the colons for the title 'General Config…' and subsection titles?
2) Enforcing mode = Enforcing. ??? This seems like bad wording. Are you illustrating how a policy is being enforced or more simply the fact that the policy is being enforced?
Other than that i think it looks nice and clean.
Hi Matt,
1) You're right, the colons should go. The only reason I put them there is because when I worked on it I had the GNOME HIG open to this http://library.gnome.org/devel/hig-book/stable/wi… but this isn't a property window nor are those property labels, it just somehow put the notion that bold labels need colons in my head. LOL. There are plenty of shots in the HIG showing subcategorization of screen areas having headers without colons so I'll certainly remove them in the next iteration of the mocks.
2) Well, the enforcing modes are : Enforcing | Permissive | Disabled I think. Enforcing mode is what status SELinux is currently set to with regards to how it does or doesn't enforce policy. I do agree that especially if you've got less knowledge of SELinux's unique jargon, that field seems rather nonsensical. I'm trying to think of a better way to pose it – 'Current Mode:' ? 'Current Status: ' ? :-/ I'll have to ponder on this for a while.
Thanks a bunch for the feedback!
I think this looks much cleaner than what it looks like now. But could you post a picture of how it currently looks so other people can more effectively compare the two (if they aren't currently on a computer with system-config-selinux or what not).
Hi Ahmed,
Sure thing. I'll be working on this again tomorrow, so I'll take some 'before' screenshots and upload them to the same wikipage the mocks are on. It's a good idea, so thanks!
Hi Ahmed, they're added now! See: https://fedoraproject.org/wiki/Design/SELinuxConf…
Thanks! Yeah, the mock ups look much more user friendly.
I think it is going to be hard to beat the current GUI. I would focus on cosmetic things but i would keep the way that information is presented and what is presented the same as much as possible. Knowing that the GUI is designed by someone maybe not so creative but with much knowledge of, and experience with SELinux and with the insight to know how stuff should be ordered to achieve good functionality.
Also keep in mind that SELinux is a framework. A lot of the info presented is not fixed, it is retrieved from the policy. Would the GUI be able display the properties of my personal policy as well as Fedora's "example" policies?
The GUI should make admin comfortable with working with great amounts of information. Search through , filter and sort the huge list of modules, contexts , seusers and seusers to linux user mappings, ports etcetera. What if you have 100 SELinux users or login mappings instead of just 5 or 6.
Maybe if the menu on the side is removed and somehow implemented in the top menu that would give more space to show the information. ( i like the idea of the tabs, the take less space and are easily accessible )
system-config-selinux is a front end to semanage. What added value can a front-end give over a text user interface interface? implement that.
People that manage selinux probably want it to be as functional as possible. easy navigation, flexibility, as little clicks as possible, good clear overview. Maybe give it labels, tool tips , or info buttons with information about what is expected for not so experienced users.
I remember a feature request that i once mentioned which is currently implemented. Sorting for columns. That made it easier to get some order in the huge lists of contexts, ports etcetera. ( with semanage you can always grep) The filter bar is also very useful.
I think i would try to find a balance between making the GUI friendlier for new users by making it easier to navigate and have more info about things that – are- fixed.
But the hardest customers are the semanage users. semanage can be used non-interactive and its fast (the drawback is much typing). the GUI is slow but can potentially do a better job displaying and navigating and achieving tasks with less interaction.
About policy provider:
It looks neat. but what if you have several policy models installed? In the current GUI there is a "system default policy type' drop down. Which, together with the relabel on reboot check box, let us switch policy models. would that still work with the package kit feature?
About users:
I think this page does not give a optimal overview of all settings. I would want to see all settings so i would probably keep the login mapping and seuser mapping separate like the current gui does to preserve space to present essential details. A nice option would be to hide columns with details. but by default i would want to see as much as possible.
About network ports:
I do not see the actual port numbers column? I would want to sort on port number, protocol. I like the way we can hide the security level column because that is really only applicable for MLS policy.
The GUI is really just a front-end to semanage and currently i think the GUI is really familiar to semanage users. The layout of the pages and settings can probably be improved and i think i would focus on that.
This is only my personal opinion. Thanks for your help to make managing SELinux more enjoyable.
Hi Dominick, you've given me a wealth of information and a lot of great points, thanks!
Just a couple of things I wanted to point out –
1) The very first column of the list in the network ports tab is actually 'Ports' and by default the screen is sorted by that (thus it's got a darker bg color, which is the GTK convention, which may be why you missed it) – with that in mind does that particular tab seem more suitable? – https://fedoraproject.org/wiki/Design/SELinuxConf…
2) As far as I know, the users screen shows the same user settings visible on the current users screens, with the exception of the MLS/MCS levels column (which is made visible via a checkbox along the bottom) and the actual selinux labels for users (e.g., 'admin_u') which I had in mind to display by a hover tooltip per user type. Perhaps it's important to display it outright, in another column perhaps? Does this make more sense? If you still feel there is information missing here, what information is it and why is it important?
3) "It looks neat. but what if you have several policy models installed?" The idea behind the policy provider field is it would show you where the currently-active policy comes from. If you have others installed, that is quite possible, but if I understand correctly only one-at-a-time may be active, and it's the active one we care about here. Part of the idea of displaying this is when someone complains to Dan about a 'bug' in SELinux, and he asks them which policy they are using, the way SELinux is set up now it provides a policy version number that is useless to Dan – it's much easier for him to know which policy they are talking about and whether or not there is an updated version available if they give him the name of the software package that provides it. The other idea here is if the policy is indeed out-of-date, we're hoping it'd encourage users to update it first, try again, *then* file a bug report with Dan because in many cases, he is able to assist users having trouble with their policy by simply advising them to update the policy to get a bug fix. Does that make more sense? Would it be useful for you to have other installed policies displayed here too? We had the idea to hide the policy selection behind the as-of-yet-not-mocked-up 'advanced' dialog (the button for it is in the lower left here: https://fedoraproject.org/wiki/Design/SELinuxConf… ) since we were under the impression that most users just stick with the default policy, do not install additional policies, and do not often switch between installed policies. If you have particular scenarios you'd like supported regarding additional policies and switching between them though, it'd be quite helpful for you to share more details about that if you can! 🙂
4) "Maybe if the menu on the side is removed and somehow implemented in the top menu that would give more space to show the information. ( i like the idea of the tabs, the take less space and are easily accessible )" Yeh I'm not sure the current navigational approach is the right one. I had the idea (I think I outlined it briefly on the wiki page with the mockups) that I could also mock it up with the tabs flat and straight across the top rather than having two major sections with subtabs under each. I'll certainly mock it up to get an idea of whether or not it's a reasonable way to organize the screens.
I have some questions for you too:
1) "Would the GUI be able display the properties of my personal policy as well as Fedora’s “example” policies?" When I spoke with Dan and his interns about this, I was under the impression that only one policy at a time can be loaded (thus the current UI's dropdown to switch between currently-installed policies.) Is that not the case? Right now many of the current screens have the ability to switch the view between seeing all policy items vs custom policy items only, and that functionality so far has been carried over in these mockups (check the 'view:' dropdown filters in the upper right corner of some of the lists, for example, the network ports one: https://fedoraproject.org/wiki/Design/SELinuxConf… )
2) "What if you have 100 SELinux users or login mappings instead of just 5 or 6." Is this a typical scenario? Is it a scenario that is possible at all? I was under the impression from speaking with Dan that the SELinux user types, while having really awesome possibilities, are not used often. One of the things I'd like to do is maybe make those possibilities more readily apparent with the UI (obviously haven't done that yet.) But if the feature is not used so often (what chances do you think there are someone has 100+ SELinux user types? I'm thinking 1 in 500 or worse?) then I question the utility of complicating the screen with filtering tools which is why I removed them explicitly for those lists. I'd rather design the GUI with an eye specifically towards the more common use cases, and for the rare 'ZOMG i got 1000 SELinux user types' case, those folks may well be better off using semanage anyway. Does that make sense? Have I got this completely wrong? How do you use SELinux user types? Do you have ~100 different types?
3) What are the most frequent / important tasks you find yourself using semanage to do? Is there anything you explicitly use semanage for because the current GUI doesn't support it, or is there anything you know semanage can do that the GUI cannot but should?
Thank you so much for taking the time to provide me with such well-reasoned thoughtful feedback. I hope you have a little bit more time to discuss this with me further 🙂
s/versoin/version/
bleh, terrible typo, thanks for noticing! I'll fix it in my next version of that screen, which I'm still working on! 🙂
It's probably just my ignorance on the subject, but one of the issues that I have is that there's no way to view locally defined policy (that I know of) in the GUI. It would be great if that were somehow integrated into this tool update.
If the information is available, perhaps an additional tab for local policy additions?
Hi Mace,
What do you mean by locally-defined policy? Do you mean custom bits added to what's defined by the installed policy by default? For that, the current UI in some lists has a button along the top with a little binoculars icon that says 'Customized' that will filter the list below so it only displays those rules that you have defined on your own outside of the policy.
Is that what you meant? Or did you have something else in mind?
The 'Customized' buttons don't display local policy in the current GUI. By local policy, I mean those things that are added via the sequence (for example):
audit2allow (or manually created) -> checkmodule -> semodule_package -> semodule -i
As far as I know, policy created this way is only managed via command line, and the GUI currently only manages distributed policy. If the locally created policy is in the GUI somewhere, there's no current way of distinguishing it, as far as I know.
That means that, once local policy is created, the GUI becomes superfluous (you have to use the command line anyway).
I can't imagine anything other than a straight desktop environment where some local policy would not be needed. If desktop users are the target audience for the GUI then not managing local policy is OK. If it's intended to have a more comprehensive role than that, I think it needs expansion.
1) Whoops, you're right. Yes that is more suitable indeed.
2) MCS and MLS are optional models in SELinux. Fedora has MCS enabled in its target policy though. This could be a good reason to make a option to hide it, but i would probably prefer it displayed by default.
SELinux user management has two parts:
a) In the first part you can create a SELinux user and map roles, and optionally (if enabled MCS and MLS category ranges) to this SELinux user.
semanage user -a -L s0 -r s0-s0:c0.c1023 -R "designer_r user_r" -P user mairin_u
-mairin_u is the custom SELinux user
-user is the prefix which is not used anymore (can be ignored)
-user_r and designer_r are the roles asigned to SELinux mairin_u
– s0 is the default MCS/MLS level (optional -policy must have MCS /MLS enabled)
-s0-s0:c0.1023 is the MCS/MLS range assigned to mairin_u SELinux user (also optional like the MCS/MLS label)
If MCS or MLS is enabled, than these field are important. If not enabled they can be removed.
b) In the second part you can map the SELinux users that i described in part one to Linux users (a note here is that in this part you can still edit the optional MCS and MLS ranges)
semanage login -a -s mairin_u -r s0-s0:c123,124 mairin
– mairin is the Linux login name
– mairin_u is the SELinux user name that we defined in a)
– the (-r) MCS range is a range that is assigned to mairin (the Linux user login name)
This range must be within the scope of the MCS/MLS range that is mapped to mairin_u in a). The MCS/MLS ranges here are also optional (MCS/MLS) must be enabled. But if MCS/MLS is enabled they are important.
3) Yes only one policy model can be active at a time. So if the packagekit plugin is meant to only display details for the active policy model then that great
However i would keep in mind that policy models can be installed from various sources. If the GUI is installed on debian, will it still work? probably not but that may not be a big deal if it behaves well.
The reasoning about dwalsh wanting to know policy versions makes sense but setroubleshoot already displays version numbers.
If there is a new version available then that will automatically be updates ASAP. Unless of course its only available on koji for the time being. In that case the package kit plugin cannot display it either (the exception is probably updates-testing)
4) I personally love system-config-users GUI, It is so clean and functional In many cases user management and selinux management are the same (with exceptions ofcourse)
The system-config-users GUI puts the focus on the content. It is made to handle many users (big white canvas with room for plenty users) buttons and tab on top easily accessible and in the same time they dont take up much space.
1) You are right. Only the active policy is important. What i meant by saying that was aimed at some of the fixed descriptions in you mocks. Also i said it wrong it should be:
Would the GUI be able display the properties of my personal policy as nice as Fedora’s “example” policies?
2) Good question. My honest opinion is that not many people use (the new) SELinux policy to its full potential. (its advanced features of restricting users) So for now chances are that not many people define many new SELinux user and login mapping.
However my believe is that once this restricting users feature gets better understood (and gets more audience this may change (maybe by the time of el6)
I am looking to how i use it and i certainly can imagine many different SELinux users and login mappings.
The default users are a good simple base selection of profiles but it is far from all of the possibilities
To explain how i use SELinux user lets look at my own SELinux environment:
I created a unique SELinux user to map to my Linux login name. This unique SELinux user is mapped to unique user domains. For example my default SELinux environment that i operate in is based of off the staff_t SELinux environment. Although the staff_t environment is a nice default profile, it is not customized to may particular requirement.
I could probably modify the staff_t environment and modify the staff_u SELinux user but than i change default predefined users (settings that will be reset once policy is updated)
Also i might assign different roles to different SELinux users:
joe_u gets (default) staff_r and access to webadm_r as he is the web administrator
pete_u is also web administrator but i do not want to give pete as much permissions as joe_u. Besides pete_u only logs in via openssh, also pete_u must also be able to manage the samba server. So i create a new SELinux user pete_u and instead of assigning the staff_t environment to pete_u is assign him to a modified guest_t environment and give pete_u access to both webadm_r and sambadm_r roles.
Most users have unique properties. SELinux allows fine grained access control. So why use like 5 predefined profiles if you can assign tailor made permissions to each user?
Sure sometimes its not worth all the trouble but in a professional environment it might just be worth it to manage users strict.
But you have a quite good point when you say that i and probably alot of advanced users) would probably use semanage. Basically because of its flexibility.
I think it is also true that not many people use SELinux to its full potential But in my vision i see that change and i see system-config-selinux as a work place, like OpenOffice.org writer for SELinux admins.
3) I probably mostly define SELinux users and login mappings. Also managing contexts. Although i recently started doing these things without both semanage and the GUI. I preferable use modules for defining SELinux users and contexts because they can be easily exported/deployed on more then one system and it can be automated.
SEmanage can do things that the GUI cannot like defining network interfaces and nodes, but these are advanced features that almost no one uses.
The current GUI is actually very functional as i said earlier. I think looks a bit rough though and it is slow but this is due to the SELinux infrastructure.
There are atleast two sides in SELinux world. The default configuration side (targeted/unconfined) which is used by most Fedora users. This configuration does not require much management compared to the other sides. Maybe add a custom context, a custom port definition, adding removing permissive domains.
The other side (strict) which is almost not used. This configuration allows for many different classes of users. Users are managed strict so besides the management mentioned above, SELinux admins for strict environments probably spend time creating SELinux users and login mapping.
I realize that i use SELinux in a pretty uncommon way so take my suggestions with a grain (or two) salt.
Thanks for your interest.
One of the big issues with the MLS/MCS labels and the reason that I, and others believe they should be hidden by default is that they are not terribly verbose. A mildly experienced user is able to understand many of the type, role, and user names but understanding the correspondence from MLS/MCS labels to their actual effect is significantly harder. Most users will simply stick with the default settings so hiding the scary labels by default is probably for the best.
It's interesting that you mentioned system-config-users as I just recently submitted a patch to allow you to change your user -> selinux user mapping within that gui. Hopefully that will be available soon.
In general if you have any features you'd like to see beyond visual changes I'll be the one actually implementing them so you should just ping me on freenode (cpardy) I'm floating around on #selinux and #fedora-selinux.
Just wondering: which system font are you using? Looks nice 🙂
It's Droid Sans! It's Apache license so it's happily free & open source.
How about an option to use AppArmor instead. 🙂
That's funny!