[gentoo-hardened] Towards stabilizing the latest SELinux policies/utilities.

[gentoo-hardened] Towards stabilizing the latest SELinux policies/utilities.

[Anthony G. Basile]

This email is mostly for Swift and gizmo, but anyone can have their input.

I've been running a SELinux system for the last month or so since I've
uploaded the massive work done by Swift and gizmo.  There was one major
bug we noticed right away, and Swift got it, namely bugs #355745 and
#356533 --- dups.  After that, it looks pretty clean.

I'm think we should go for stabilization --- I'm not sure how since the
arch teams are going to say they really can't test this for us, and as
they did with other packages, will probably defer the judgment back to
us.  If we do, we should take this responsibility very seriously because
the arch teams, if nothing else, are a double check on our work.

So far I see only a few bugs that need addressing still in bugzilla.
(The bug reports are a bit disorganized because of how they were
assigned.  We're going to be assigning selinux bugs to
selinux@gentoo.org for easy lookup.)

I think these are blockers to stabilization.  Any others you want to add
to the list?

#355675 - No brainer. I'll test the patch there this afternoon and put
it on the tree later if it works.

#346563 - sounds like a profile problem, but I'm not sure its valid

-- 
Anthony G. Basile, Ph.D.
Gentoo Developer

Re: [gentoo-hardened] Towards stabilizing the latest SELinux policies/utilities.

[Sven Vermeulen]

On Thu, Mar 17, 2011 at 01:14:02PM -0400, Anthony G. Basile wrote:
> I'm think we should go for stabilization --- I'm not sure how since the
> arch teams are going to say they really can't test this for us, and as
> they did with other packages, will probably defer the judgment back to
> us.  If we do, we should take this responsibility very seriously because
> the arch teams, if nothing else, are a double check on our work.

For the time being, I'm focusing my attention on server-side testing:
integrated virtual environments running bind, openldap for authentication
with replication, a load-balanced apache setup offering squirrelmail access
to a virtual mailhosting setup (postfix/courier) and a standalone postgres
(still looking for something nice to fully test postgres with).

I'm extending the environment with more and more services so that I have
some testing environments for most of the servers (for instance, I have a
build server that uses lighttpd) for which we have policies.

However,
- I'm focussing on strict policy (no unconfined domains) which is a major
  shortage as we definitely want to support unconfined as well.
- Although I run my desktops with SELinux strict as well, I'm hardly what
  can be called a multimedia-user: apart from firefox and skype, all
  utilities I use are mostly command-line ;-) So support for
  desktop-oriented SELinux might still be lacking stuff. 

The reasons are fairly simple:
- Strict allows us to focus on the policy itself and, in theory, if a strict
  policy works well, unconfined should work well too as far as the same
  activities are concerned.
- Desktop applications are far too difficult to automatically test
  (regressions), which leads me to
- I hardly have the time to run manual tests ;-)

Of course, when there are bugs (for instance with unconfined) it's a small
step to convert to the targeted policy and verify if it is reproduceable
(like it was with that pesky bug you mentioned in the beginning of your
mail).

> So far I see only a few bugs that need addressing still in bugzilla.
> (The bug reports are a bit disorganized because of how they were
> assigned.  We're going to be assigning selinux bugs to
> selinux@gentoo.org for easy lookup.)
> 
> I think these are blockers to stabilization.  Any others you want to add
> to the list?
> 
> #355675 - No brainer. I'll test the patch there this afternoon and put
> it on the tree later if it works.
> 
> #346563 - sounds like a profile problem, but I'm not sure its valid

If we go for stabilization (and I wouldn't mind, as most additional servers
that I'm setting up hardly require updates on the policy) we should push the
SELinux Hardened Handbook (currently in hardened-doc.git) as well as the
SELinux FAQ. Also, the moment we stabilize, can we please get the
"loadpolicy" stuff out of our profile (selinux/make.defaults) ;-)

Anyhow, #346563 is about that weird multilib/nomultilib situation. SELinux
profiles currently enable multilib and "-multilib" (aka "no-multilib") is
for the time being not supported. But we might need to focus on this in the
near future as I would assume in server environments no-multilib is
preferred.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] Towards stabilizing the latest SELinux policies/utilities.

[Matthew Thode]

I run no-multilib and can offer to test postgres standalone for you.
But given that I run no-multilib I do not know if I can help until
that bug is fixed.

-- Matthew Thode

On Thu, Mar 17, 2011 at 17:33, Sven Vermeulen <sven.vermeulen@siphos.be> wrote:
> On Thu, Mar 17, 2011 at 01:14:02PM -0400, Anthony G. Basile wrote:
>> I'm think we should go for stabilization --- I'm not sure how since the
>> arch teams are going to say they really can't test this for us, and as
>> they did with other packages, will probably defer the judgment back to
>> us.  If we do, we should take this responsibility very seriously because
>> the arch teams, if nothing else, are a double check on our work.
>
> For the time being, I'm focusing my attention on server-side testing:
> integrated virtual environments running bind, openldap for authentication
> with replication, a load-balanced apache setup offering squirrelmail access
> to a virtual mailhosting setup (postfix/courier) and a standalone postgres
> (still looking for something nice to fully test postgres with).
>
> I'm extending the environment with more and more services so that I have
> some testing environments for most of the servers (for instance, I have a
> build server that uses lighttpd) for which we have policies.
>
> However,
> - I'm focussing on strict policy (no unconfined domains) which is a major
>  shortage as we definitely want to support unconfined as well.
> - Although I run my desktops with SELinux strict as well, I'm hardly what
>  can be called a multimedia-user: apart from firefox and skype, all
>  utilities I use are mostly command-line ;-) So support for
>  desktop-oriented SELinux might still be lacking stuff.
>
> The reasons are fairly simple:
> - Strict allows us to focus on the policy itself and, in theory, if a strict
>  policy works well, unconfined should work well too as far as the same
>  activities are concerned.
> - Desktop applications are far too difficult to automatically test
>  (regressions), which leads me to
> - I hardly have the time to run manual tests ;-)
>
> Of course, when there are bugs (for instance with unconfined) it's a small
> step to convert to the targeted policy and verify if it is reproduceable
> (like it was with that pesky bug you mentioned in the beginning of your
> mail).
>
>> So far I see only a few bugs that need addressing still in bugzilla.
>> (The bug reports are a bit disorganized because of how they were
>> assigned.  We're going to be assigning selinux bugs to
>> selinux@gentoo.org for easy lookup.)
>>
>> I think these are blockers to stabilization.  Any others you want to add
>> to the list?
>>
>> #355675 - No brainer. I'll test the patch there this afternoon and put
>> it on the tree later if it works.
>>
>> #346563 - sounds like a profile problem, but I'm not sure its valid
>
> If we go for stabilization (and I wouldn't mind, as most additional servers
> that I'm setting up hardly require updates on the policy) we should push the
> SELinux Hardened Handbook (currently in hardened-doc.git) as well as the
> SELinux FAQ. Also, the moment we stabilize, can we please get the
> "loadpolicy" stuff out of our profile (selinux/make.defaults) ;-)
>
> Anyhow, #346563 is about that weird multilib/nomultilib situation. SELinux
> profiles currently enable multilib and "-multilib" (aka "no-multilib") is
> for the time being not supported. But we might need to focus on this in the
> near future as I would assume in server environments no-multilib is
> preferred.
>
> Wkr,
>        Sven Vermeulen
>
>