SELinux base policy r2 in hardened-dev overlay
 

Hi guys,

I have just pushed selinux-base-policy--2.20110726-r2 to the hardened-dev
overlay. There are not that many changes in it (although "not many" is
relative of course) but some were quite necessary to be pushed out already.
The main reason why I do it now and not wait until I've fixed the other bugs
that are still lingering, is because for -r3 I might need to make more
in-depth changes on how we support init scripts within SELinux. More on that
later...

First of all, the small list in changes:
- for all domains that we add ourselves (like gorg, pan, skype, mutt, ...) I
didn't include the regular user support yet (stupid me), so that's fixed
now
- nagios diskcheck plugin issue is fixed
- xfce4 file contexts are fixed
- userdomains can now use syslog
- portage has improved layman/emerge-webrsync support (you will need to
"rlpkg layman portage" though)
- improved mutt domain definition (help from upstream)
- puppet fixes (a few of them)
- zabbix correction on context and support remote mysql support
- LDAPS support for nsswitch stuff
- update on courier-imap file contexts

There is also one change under the hood, which is the support for the
patchbundles. Up until now, the patchbundle was applied as one big bundle
(epatch ...tbz2) which made it difficult to debug patching issues. With r2,
the patches are applied one by one, so a failure in a patch immediately
gives a clear error in which patch (and where). It also shows the user the
list of patches being applied now - for those that like to watch epatch
work, that is ;-)

A second change is that the patches are now not only per-file fixes, but
structured in logical patchsets. These logical sets are a lot easier to send
upstream (and also mark as "approved upstream") and should make the
introduction of new upstream versions a lot easier to integrate (I had too
much time wasted due to manual patch transformations between 20101213 and
20110726).

BTW, we currently have 50 patchsets applied, 2 of them have been accepted
upstream (so we do not need to maintain those the moment a new refpolicy is
released), 7 of them are pending, the rest I still need to submit (but first
need to confirm that the issues have been resolved correctly).

Okay, but what is this "in-depth" change that I was talking about. Well,
SELinux policies support labeled init scripts. For instance,
"slapd_initrc_exec_t" which allows the init script to run in an init script
domain specific for slapd (splad_initrc_t). This allows for slapd-specific
allow statements (for instance PID file management) from within the init
script.

All fine, but Gentoo doesn't use that. We run all our scripts in initrc_t
instead. Why? Because we support "integrated run_init support", which allows
our users to just call "/etc/init.d/slapd start" instead of "run_init
/etc/init.d/slapd start". But this integrated run_init support automatically
transitions all scripts to initrc_t (and not slapd_initrc_t). And changing
this to support the named init scripts isn't straight forward (well, I hope
I eventually find a straight-forward method, but until now I didn't
succeed).

Yet we will eventually need to support this, because otherwise we need to
"open" the privileges on initrc_t towards all potential services. Not only
does that require lots of work, it also brings in patches in our policy that
upstream will never accept (and they're right not to accept it).

Hence I'll be working on that the upcoming days.

Wkr,
Sven Vermeulen

SELinux base policy r2 in hardened-dev overlay
 

> Okay, but what is this "in-depth" change that I was talking about. Well,
> SELinux policies support labeled init scripts. For instance,
> "slapd_initrc_exec_t" which allows the init script to run in an init
> script
> domain specific for slapd (splad_initrc_t). This allows for slapd-specific
> allow statements (for instance PID file management) from within the init
> script.
>
> All fine, but Gentoo doesn't use that. We run all our scripts in initrc_t
> instead. Why? Because we support "integrated run_init support", which
> allows
> our users to just call "/etc/init.d/slapd start" instead of "run_init
> /etc/init.d/slapd start". But this integrated run_init support
> automatically
> transitions all scripts to initrc_t (and not slapd_initrc_t). And changing
> this to support the named init scripts isn't straight forward (well, I
> hope
> I eventually find a straight-forward method, but until now I didn't
> succeed).
>
> Yet we will eventually need to support this, because otherwise we need to
> "open" the privileges on initrc_t towards all potential services. Not only
> does that require lots of work, it also brings in patches in our policy
> that
> upstream will never accept (and they're right not to accept it).

Ok, I buy the argument. Is this a shortcoming in the old bash init, or is
this a shortcoming in OpenRC?

I'm starting to see a little more free time from my job and might be able
to tackle some things starting in a couple of weeks.

Gizmo

SELinux base policy r2 in hardened-dev overlay
 

Sven Vermeulen <swift@gentoo.org> Sunday 21 of August 2011 12:06:46
> On Sat, Aug 20, 2011 at 08:08:41PM -0500, Chris Richards wrote:
> > > Yet we will eventually need to support this, because otherwise we need
> > > to "open" the privileges on initrc_t towards all potential services.
> > > Not only does that require lots of work, it also brings in patches in
> > > our policy that
> > > upstream will never accept (and they're right not to accept it).
> >
> > Ok, I buy the argument. Is this a shortcoming in the old bash init, or
> > is this a shortcoming in OpenRC?
> >
> > I'm starting to see a little more free time from my job and might be able
> > to tackle some things starting in a couple of weeks.
>
> I'm not sure. A quick check reveals that there is no such thing as
> domain-specific initrc_t subdomains. It seems that the subdomains are there
> to allow roles within SELinux to handle init scripts of one daemon but not
> the other (for instance, create an ldapadm_r which has ldap_admin() and as
> such is allowed to execute it properly, but doesn't have the same rights
> for postfix).
>
> Within Gentoo, we mark everything as initrc_exec_t, so the user needs just
> "one" privilege to handle services for all domains. I'd like to "fix" that,
> but still keep the integrated run_init support in-place. That'll require
> some more investigation here (since I don't understand how the integrated
> run_init is done).
>
> However, my initial assessment that we "otherwise" need to "open" up
> initrc_t stays in place (we just don't have a choice here). That initrc_t
> is a highly privileged domain is obvious from a first look at its .te file.
> So it looks as if we just need to add the proper optional_policy statements
> here.
>
> BTW, glad to hear you're seeing some free time in the near future ;-)
>
> Wkr,
> Sven Vermeulen

I'm not SeLinux guroo, but at eye glance it looks like init (runint) script
1. reads contexts/run_init_type (but I think this is done to password
authentication)
2. then it reads and changes to contexts/initrc_context domain.

This is made in policycoreutils-extras/runscript_selinux.c. There are some
comments about initrc_devpts_t.

Maybe changin 2. will be solution, instead of read contexts/initrc_context
take context from target script?

Regards,
Radek.

SELinux base policy r2 in hardened-dev overlay
 

On Aug 22, 2011, at 12:11 PM, Sven Vermeulen wrote:

> On Mon, Aug 22, 2011 at 03:18:16PM +0000, Sven Vermeulen wrote:
>> What you are suggesting (label init script) is exactly what I was talking
>> about: instead of having the init scripts labeled initrc_exec_t, they should
>> be labeled like slapd_initrc_exec_t, postfix_initrc_exec_t, ... and Gentoo's
>> integrated run_init support, which by the policy is currently only working
>> on initrc_exec_t, should support those too.
>
> I guess that won't be happening soon.
>
> When an administrative interface is granted to a domain/role (like
> ldap_admin) then a role transition to system_r is automatically granted
> when a transition occurs on the domain-specific initrc script (like
> slapd_initrc_exec_t). In case of integrated run_init support, this would
> create a context root:system_r:run_init_t, which is invalid.
>
> Removing the role transition in all administrative interfaces is imo a no-go
> as that would mean lots of work and maintenance.
>
> Oh well, it was fun to try...
>
> Wkr,
> Sven Vermeulen
>

I know this is not ideal, but can you simply allow sysadm_r to use rc-service and it's brothers?

-- Matthew Thode

SELinux base policy r2 in hardened-dev overlay
 

On Aug 22, 2011, at 1:18 PM, Sven Vermeulen wrote:

> 365761

Yep, I was looking for the bug

-- Matthew Thode

SELinux base policy r2 in hardened-dev overlay
 

Sven Vermeulen <swift@gentoo.org> Monday 22 of August 2011 19:11:38
> On Mon, Aug 22, 2011 at 03:18:16PM +0000, Sven Vermeulen wrote:
> > What you are suggesting (label init script) is exactly what I was talking
> > about: instead of having the init scripts labeled initrc_exec_t, they
> > should be labeled like slapd_initrc_exec_t, postfix_initrc_exec_t, ...
> > and Gentoo's integrated run_init support, which by the policy is
> > currently only working on initrc_exec_t, should support those too.
>
> I guess that won't be happening soon.
>
> When an administrative interface is granted to a domain/role (like
> ldap_admin) then a role transition to system_r is automatically granted
> when a transition occurs on the domain-specific initrc script (like
> slapd_initrc_exec_t). In case of integrated run_init support, this would
> create a context root:system_r:run_init_t, which is invalid.
>
> Removing the role transition in all administrative interfaces is imo a
> no-go as that would mean lots of work and maintenance.
>
> Oh well, it was fun to try...
>
> Wkr,
> Sven Vermeulen
Maybe better idea will be to move one level upper and instead of working with
domain templates we should create role templates. I generally like idea of
roles, and I think it may be nice solution that administrator may give someone
dba_admin role.

So templates should not only create domains, but roles too.

I may try to write few such templates.

Regards,
Radek