On Tue, Sep 15, 2009 at 08:17:59PM -0400, debora@xxxxxxxxxxxxxxxxxx wrote: > Hello, > > Bryan Jacobson and myself (both from IBM) have been approved to lead two > SELinux BOFs at the upcoming LinuxCon and Linux Plumbers Conference in > Portland, Oregon. The LinuxCon BOF entitled "How to Keep SELinux Turned > On" is scheduled for Tuesday, September 22nd at 11:15 AM. The Linux > Plumbers Conference BOF entitled "Making SELinux Easier to Use" is set > for Thursday, September 24th at 3:00 PM. > > Below are the abstracts for both of the BOFs. If you are unable to > attend, but have input you would like to share, we would be very > interested in hearing it. > > Thanks! > Debora Velarde > IBM, Linux Technology Center > > > LinuxCon BOF: How to Keep SELinux Turned On > > According to our Linux support team, the number one question they get > about SELinux is. How do I turn off SELinux? This BoF will discuss > usability problems with SELinux that cause users to turn it off, and > focus on a small set of near term improvements. > > Although many tools for SELinux have been created, there is still a > perception that SELinux is too complicated to use. How can we change > that? We would also like to hear from experienced SELinux users that > have in depth knowledge of the tools available. Please come share your > knowledge, concerns, and ideas of what changes you would like to see. > In my view SELinux is not nearly as complicated to use as a Linux system that it tries to protect itself. I'd like to consider my myself "experienced user", and SELinux helped me better understand how a computer system as complex as Linux is works. I often compare SELinux to netfilter, although both a very much different. The point i am trying to make is that in both there are (atleast) two parts that you have to be aware about to operate it successfully. As a comparison: With a network firewall like for example Netfilter (framework) and iptables (user space tools) you have to learn how to operate the tools (iptables). This may seem difficult but what makes it difficult is that you must also know about networking itself. iptables -A is the easy part, what comes after that is harder because it is specific not networking. Same for SELinux (framework) and semanage etcetera (user space tools). In order to successfully manage a SELinux system you must not only be confident with the tools (which in my view is the easy part) but you must also be familiar with some of the basics about how a Linux environment works. classes, permissions (syscalls), processes and objects etc, you must know the subjects that you are trying to protect. The latter is in my view the harder part to understand, with or without SELinux. Granted, with SELinux there is also the difficulty that you must connect the link between how a system works and how SELinux tries to anticipate to that (for example mapping linux logins to SELinux users) I will admit that there is still (much) room for improvement to make SELinux more user friendly but i think the core issue is education/investment in security/responsible computer management. To successfully maintain a computer system you must know how it works and you must take the time to do it right. These are in my view the fundamental issues. There is a lot to learn about a system (which scares people in my view) and there are a lot of objects and subjects to manage which can take a lot of time) > > > Linux Plumbers BOF: Making SELinux Easier to Use (focus on documentation) > > SELinux is often disabled immediately or at the first sign of trouble. > How can we make SELinux something users actually want to leave on? > > Inadequate documentation was recently listed as one of problems > related to using SELinux on the SELinux mailing list. Although many > tools for SELinux have been created, there is still a perception that > SELinux is too complicated to use. This talk will present a list of > possible documentation improvements that can help change this > perception. When i first joined the #selinux irc channel one of my first complaint was the lack of documentation. It is easy to blame that. Nowadays i think theres plenty docs available (even for free) to learn all about SELinux/Linux. What in my view is a issue is that parts of it are scathered all over the internet (maillists, blogs, media articles, manuals, etc) It takes a lot of Googling to put the pieces of the puzzle together, but the pieces are there. I think a central place with urls to all those scathered resources may make things easier so that people do not have to spend much time to actually find stuff. selinuxproject.org/user_resources is an attempt to bring that together. When it comes to policy authoring things get a bit harder to find but books like SELinux by example should get people started and reference policy is the ultimate reference. We can spend a lot of time trying to write duplicate manuals but in my view that time can be spend on better things. Also alot of documentation is fixed on reference policy specifics. Reference policy is in my view just one configuration. Just like the old "NSA example policy" it may evolve (and it is constantly evolving) to some much different. In my view spending much words on a single policy(model) is not a good approach. It is better to understand the basics of SELinux properly, so that one can figure out *any* policy model on its own. To me it all boils down to subjects,objects,classes and permissions,constraints,types,roles,securitylevels,attributes etc. What a specific type allows that can be figured out once you know the basics and the problem is in my view is that users are confronted with issues like: a process cannot use permission execmod on lib_t. Thats just a policy decisions, a property of the policy model. A policy model has a lot of properties and instead of learning those policy specific properties, why not go straight to be core so that you can figure out those yourself. I am not saying that documentation cannot be improved. I am saying that i requires strong will to find all the bits and pieces scathered and put them together, and than study it. What kept me going and kept me interested is the power of control that SELinux provides. Results can be seen directly of a rule you add./not add. I do not see security only as a requirement but i also see it as a way to facilitate. I am not solely placing walls to deny access , i am placing them to guide subjects in the right direction (and a nice side effect is that there is (usually) no way around the fences) I am at a point where AVC denials do not scare me anymore. What does sometimes scare me is the amount of policy//time it takes to fix the issue properly. One AVC denial can potentially be a trigger to hours of work and hundreds of lines of policy, but i also realize that this is not just because of SELinux. It is because a system is complex and SELinux gives me the flexibility to manage as much as possible. I like that. Besides, When it comes to security you cannot just ignore parts in my view. You must be able to control as much as possible. So in short: 1. owners should mandate that operators keep selinux enabled. 2. owners should invest time and resources to educate operators and users. 3. operators should understand the complexity of computer systems and the need for (optimal) access control. 4. SELinux (documentation) should focus on the framework. Knowledge of the framework will help people find there own way to policy model specific properties. > > > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with > the words "unsubscribe selinux" without quotes as the message.
Attachment:
pgpQELQO0aJ8k.pgp
Description: PGP signature
