[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

indeed, consider SELinux a tool in the Linux security specialist toolbox
similar to for example a drill in a dentist toolbox for example or a
doctors scalpel.

handling the drill/scalpel itself is probably easy too learn, but if you
do not have knowledge about tooth, root canals, human body, where to
drill or make an incision and i do not know what other aspects, then
chances are you will still be confused, insecure and prone to make errors.

i feel pretty confident with SELinux, but that is only part of the job.
My weak spots are my lack of security background and lack of programming
background.

It is a pretty serious problem that i try to work on.

> - 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.  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.
> 
> --
>    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/

iEYEARECAAYFAk2DfD8ACgkQMlxVo39jgT8UuQCfYTGmKJeEViNR6gty+X+VAAgG
i38An0PdwPTtnvpXIfR3itmrBb11x1Ro
=yQtB
-----END PGP SIGNATURE-----