SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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

SELinux base policy r2 in hardened-dev overlay
 

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