[refpolicy] Question: and the policy grows...

[domg472@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/17/2011 11:56 PM, Mark Montague wrote:
>   On March 17, 2011 15:40 , Guido Trentalancia <guido@trentalancia.com> 
> wrote:
>> Or even more likely SELinux is still perceived as "difficult to get into"
>> (a documentation issue).
> 
> My opinion is that SELinux *IS* "difficult to get into"; I do not think 
> that this is a matter of people holding false perceptions.
> 
> This is despite the documentation at 
> http://fedoraproject.org/wiki/SELinux being very good (in my opinion).  
> My team also took the RHS429 classroom training, which was also very 
> good and got us over a large number of hurdles.  (As you might guess 
> from this, I'm a Fedora / RHEL user)
> 
> Here is a list of some of the things I think make getting into SELinux 
> difficult:
> 
> - A lot of system administrators are not sufficiently familiar with how 
> Linux works (in my opinion) -- in particular, system calls, file 
> handling, session management, device management, networking, processes 
> -- before they try to get into SELinux.  It might be helpful to provide 
> a list of prerequisites to ensure that
> 
> - Effort versus reward:  it is VERY easy to disable SELinux to "fix" 
> something that is "broken" and rarely any negative consequences for 
> doing so.  On the other hand, it can take a lot of time and work to 
> learn enough to properly fix something while leaving SELinux enabled and 
> in enforcing mode, with little apparent reward for doing so.
> 
> - Terminology.  There's a LOT of it to learn.  This is not helped by 
> changes in terminology and confusion regarding domains vs types.

totally agree and there is a few more of those gotchas. for example how
s0:c1 is one field in the security context tuple although : is used to
signal "new field". So common sense says that s0:c1 are two field but in
reality its a single field.

  On a
> semi-related note, there might be too many choices, at least at first:  
> Modular versus monolithic, targeted versus strict versus MLS; 
> categories; sensitivities; RBAC; the reference policy.  It can be 
> somewhat overwhelming.
> 
> - Part-time versus full-time.  I think SELinux is a lot easier if it is 
> someone's primary focus.  However, for system administrators who spend 
> most of their time managing services and just need to work with SELinux 
> as a small component of overall service administration, it can be difficult.
> 
> 
> For me, personally, I have had the following difficulties:
> 
> - I've always struggled with policy file syntax.  What is allowed?  
> Where?  The M4 macros make things more mysterious for me, rather than 
> easier.  I'm find having to "pre-declare" everything in a require stanza 
> to be frustrating, especially as I'm constantly leaving things out.  
> I've still no understanding of the differences between .if and .te files 
> (e.g., apache.if versus apache.te in the targeted policy)
> 
> - Roles, in particular, could be better documented, in my opinion.  At 
> least, I have not found any great documentation that addresses everyday 
> situations with roles.  I'd like to make more use of roles in order to 
> run more secure servers, but am a bit lost.
> 
> - I've got little to no understanding of what the SELinux code in the 
> kernel does or how it does it.  It's a black box on which I twiddle 
> knobs and hope I get the result I want.  I see AVC denial messages but 
> have no idea what the Access Vector Cache is.
> 
> - Finding and installing the "right" Fedora / Red Hat RPMs for what 
> needs to be done (e.g., building policies).  (It's simple once you know, 
> but I had a great deal of trouble finding out): setools setools-devel 
> libsemanage-devel policycoreutils-python selinux-policy-devel 
> selinux-policy-doc.   policycoreutils-python was a big problem for me in 
> particular here, since the name of the RPM implies -- to me -- that it 
> is a set of policy core utilities for *use* with python, rather than 
> tools *written* in python (normally, when installing an RPM, I don't 
> care about what language was used to write the programs that it contains).
> 
> - Overall, I often feel like I'm flailing around in a dimly lit room 
> hoping to stumble on the solution to my problem-of-the-moment.
> 
> - Every so often I look at other MAC systems -- Smack, TOMOYO Linux, App 
> Armor -- in the hopes that one will provide the benefits of SELinux but 
> be easier (for me) to understand and work with.  No luck yet.
> 
> I'm not asking for help or solutions with any of the above bullet points 
> (I could probably clear up a number of them myself with a few more hours 
> research), I'm just trying to give people who already understand 
> everything some insights into people, like me, who are still struggling, 
> in the hopes that this will be useful to the community as a whole.
> 
> Finally, I'd like to thank both Dan Walsh and Dominic Grift for their 
> blogs -- both blogs have been extremely useful.

Thanks. I enjoy guiding people to selinux. It took me many years to get
where i am and i just want to share my knowledge forward. You can also
catch me on #selinux and #fedora-selinux, you will  find that i put much
effort into helping people out. If you ask me enough questions you will
know as much as i do.

SELinux is not so hard in my view considering its flexibility. But Linux
is complex and vast.

One issue i think could be better is the description of the object
classes and their descriptions.

In conclusion: managing selinux /security is a specialisation in my
view. Its like a job. Its not just selinux, you also need to know a bit
about security and you need to know about computer systems (linux). To
stay up to date you have to stay up to date with new things (in
linux,selinux and security). Read literature (maillist/irc/blogs) to
keep up to date with any new introduced classes/permissions and other
selinux technologies (and linux and security technologies).
Writing/maintaining selinux policy/systems is always ongoing when you
want optimal control.

The fedora policy/and refpolicy are general purpose policy and its
usually configured by default in a way that is as little invasive as
possible while in the meantime protect as much as possible.

So there are basically two modes:

1. i just accept that its there mode but i do not really care mode.
(novice) (default)
2. i employ selinux and i wield its power as much as possible mode.
(specialist/advanced) (hidden/tunable)

my take

> --
>    Mark Montague
>    mark at catseye.org
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2DMBsACgkQMlxVo39jgT+x7gCfae7sudsEbiXCipmbJAu2eWQZ
fc0AoJDdTo9cRmiV3YBWYF1tsPuvgM4V
=5NK9
-----END PGP SIGNATURE-----