[gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

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

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

On Fri, Aug 19, 2011 at 08:51:48PM +0000, Sven Vermeulen wrote:
> 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.

Ah, all wrong here, there's no slapd_initrc_t domain. *sigh*

Anyways, there's still work. You get the picture ;-)

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Chris Richards]

> 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

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

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

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Radosław Smogura]

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.

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

On Sun, Aug 21, 2011 at 01:39:15PM +0200, Rados??aw Smogura wrote:
> 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?

The solution to support <domain>_initrc_exec_t must be a policy-based one
afaik. I don't think it'll be too difficult to find (the places within
refpolicy that are offering interfaces just for Gentoo's integrated run_init
are documented), it'll just take some time to get it in proper shape.

Question is, will this then support the reason for this (i.e. role-based
support for calling only selected init scripts)?

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Mike Edenfield]

On 8/21/2011 10:18 AM, Sven Vermeulen wrote:
> On Sun, Aug 21, 2011 at 01:39:15PM +0200, Rados??aw Smogura wrote:
>> 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?
>
> The solution to support<domain>_initrc_exec_t must be a policy-based one
> afaik. I don't think it'll be too difficult to find (the places within
> refpolicy that are offering interfaces just for Gentoo's integrated run_init
> are documented), it'll just take some time to get it in proper shape.

Is there a specific reason that the domain-specific initrc 
support cannot be made part of run_init? Instead of reading 
a single default context from initrc_context, you could 
instead label, for ex. the init script itself, and have 
run_init use that instead?

ISTM that the reason the existing domain-specific init 
policy doesn't work is because run_init is doing something 
unexpected, so it makes sense that fixing run_init would be 
the correct solution...

--Mike

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

On Sun, Aug 21, 2011 at 07:19:17PM -0400, Mike Edenfield wrote:
>> The solution to support<domain>_initrc_exec_t must be a policy-based one
>> afaik. I don't think it'll be too difficult to find (the places within
>> refpolicy that are offering interfaces just for Gentoo's integrated 
>> run_init
>> are documented), it'll just take some time to get it in proper shape.
>
> Is there a specific reason that the domain-specific initrc support cannot 
> be made part of run_init? Instead of reading a single default context from 
> initrc_context, you could instead label, for ex. the init script itself, 
> and have run_init use that instead?

The run_init application is merely a tool to support transitions across
roles as well. Its behavior can well be defined by the SELinux policy
itself.

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.

Since the policy defines an attribute called init_script_file_type, I hope
to update the Gentoo-specific privileges towards this attribute rather than
to initrc_exec_t so that the current behavior (sysadm_r can call init
scripts directly) is retained.

Then the second approach is to update - I think - the init_script_file
interface to support the Gentoo integrated run_init as well. But that's
something to test and find out.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

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

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Matt Thode]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

On Mon, Aug 22, 2011 at 12:25:32PM -0500, Matt Thode wrote:
> I know this is not ideal, but can you simply allow sysadm_r to use rc-service and it's brothers?

Doesn't it already?

~# id -Z
root:sysadm_r:sysadm_t

~# rc-service postfix status
Authenticating root.
Password: 
 * status: started

Unless you mean to support it without asking for re-authentication. In that
case, check out bug #365761. It contains a "fix" for this if you prepend
your runscript activities with run_init. However, it seems not to support
the use of rc-service though.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Matt Thode]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]


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

> 365761

Yep, I was looking for the bug

-- Matthew Thode

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Radosław Smogura]

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

Re: [gentoo-hardened] SELinux base policy r2 in hardened-dev overlay

[Sven Vermeulen]

On Mon, Aug 22, 2011 at 11:00:16PM +0200, Rados??aw Smogura wrote:
> 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.

That's perfectly possible. The reference policy contains a few default
roles, but additional roles might always be submitted. However, for
inclusion in Gentoo, please know that we try to follow the reference policy.
So if you are writing roles, it is best to contribute them there:

  http://oss.tresys.com/projects/refpolicy

That being said, most of the time roles are "fed" with the proper templates
(you have _role or _run templates to execute applications, or _admin
templates to manage daemons). 

Perhaps it would be better if someone drafts up a nice document on how to
create your own roles (and maintain them)?

Wkr,
	Sven Vermeulen