On Tue, 2013-12-10 at 17:00 +0100, Dominick Grift wrote:
> On Tue, 2013-12-10 at 16:57 +0100, Dominick Grift wrote:
>
> > >
> > > typeattribute $1 direct_init;
> > - typeattribute $2 direct_init_entry;
>
> Here its actually associated with the init daemon entry file. That is
> wrong in my view. The role transition should happen on the init script
> not the daemon entry file
>
> > > - role_transition $2 direct_init_entry system_r;
> > > + role_transition $2 init_script_file_type system_r;
>
> Here is that actual role transition. This is causing problems with
> direct_initrc. role transition to system_r should happen on the init
> script and not the init daemon executable file
In Gentoo, we don't use the direct_* attributes so I can't tell you that
they do (or do not) cause problems.
hpl htdocs # seinfo -adirect_init -x
direct_init
hpl htdocs # seinfo -adirect_run_init -x
direct_run_init
hpl htdocs # seinfo -adirect_init_entry -x
direct_init_entry
What we do is we have the following set:
seutil_init_script_run_runinit(sysadm_t, sysadm_r)
. seutil_init_script_domtrans_runinit(sysadm_t)
. . init_script_file_domtrans(sysadm_t, run_init_t)
. . . domain_auto_trans(sysadm_t, initrc_exec_t, run_init_t)
This ensures that, if sysadm_t executes an initrc_exec_t script, the script
is launched in the run_init_t context. Then, our init system (OpenRC) calls
a shared library we provide (linked with libselinux) which sets the next
execution context to system_u:system_r:initrc_t (using setexeccon) and
re-executes the script.
Wkr,
Sven Vermeulen
On Wed, 2013-12-11 at 09:33 +0100, Sven Vermeulen wrote:
>
> What we do is we have the following set:
>
> seutil_init_script_run_runinit(sysadm_t, sysadm_r)
> . seutil_init_script_domtrans_runinit(sysadm_t)
> . . init_script_file_domtrans(sysadm_t, run_init_t)
> . . . domain_auto_trans(sysadm_t, initrc_exec_t, run_init_t)
>
> This ensures that, if sysadm_t executes an initrc_exec_t script, the script
> is launched in the run_init_t context. Then, our init system (OpenRC) calls
> a shared library we provide (linked with libselinux) which sets the next
> execution context to system_u:system_r:initrc_t (using setexeccon) and
> re-executes the script.
>
Thanks. Do the *_admin() interfaces work in Gentoo?
The role transition in the *_admin() interfaces happen on the init
scripts, So if they work in Gentoo then i think we can be pretty certain
that the change i am suggesting in my patch will not break the SELinux
policy openrc solution.
It's a bit harder to verify init related stuff now though because
gentoo, debian and fedora each use a different init systems now
I believe we need to make sure to role transition on the init scripts
only because if we role transition on the daemon executable files
themselves then we get conflicts with executable files that can be run
both as a system service as well as a sessions service.
On Wed, Dec 11, 2013 at 09:56:37AM +0100, Dominick Grift wrote:
> Thanks. Do the *_admin() interfaces work in Gentoo?
>
> The role transition in the *_admin() interfaces happen on the init
> scripts, So if they work in Gentoo then i think we can be pretty certain
> that the change i am suggesting in my patch will not break the SELinux
> policy openrc solution.
Yes they do.
In case of such transitions, upon executing the script, the context is
already initrc_t (in the system_r role). The SELinux code that OpenRC calls
checks the current context, sees that it is not run_init_t and gracefully
returns (no further actions taken) and the "normal" flow continues.
> It's a bit harder to verify init related stuff now though because
> gentoo, debian and fedora each use a different init systems now
Indeed. I wouldn't mind splitting the init code into their respective
domains, although that will be a "hell of a job", while there are still
important shared aspects to it.
> I believe we need to make sure to role transition on the init scripts
> only because if we role transition on the daemon executable files
> themselves then we get conflicts with executable files that can be run
> both as a system service as well as a sessions service.
Indeed.
Wkr,
Sven Vermeulen
On Wed, 2013-12-11 at 10:52 +0100, Sven Vermeulen wrote:
> > It's a bit harder to verify init related stuff now though because
> > gentoo, debian and fedora each use a different init systems now
>
> Indeed. I wouldn't mind splitting the init code into their respective
> domains, although that will be a "hell of a job", while there are still
> important shared aspects to it.
Looking at Fedoras' solution i now think that this probably will not be
optimal although i cannot think of any really convincing arguments to
back up my statement, other then that it is probably a bit too late for
that now, and that it is probably not as efficient.
We can make the systemd specific policy conditional, and if we do that
consistent then that should probably be okay
Thanks