From: domg472@gmail.com (Dominick Grift) Date: Fri, 18 Mar 2011 16:37:35 +0100 Subject: [refpolicy] Question: and the policy grows... In-Reply-To: <4D829196.2070804@catseye.org> References: <1300369855.30425.14.camel@tesla.lan> <4D8219D9.7080504@redhat.com> <1300377867.30425.40.camel@tesla.lan> <4D823A60.9020107@redhat.com> <1300390804.31755.6.camel@tesla.lan> <4D829196.2070804@catseye.org> Message-ID: <4D837C3F.2000707@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/17/2011 11:56 PM, Mark Montague wrote: > On March 17, 2011 15:40 , Guido Trentalancia > 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-----