Hi guys,
Currently all administration I do is handled through the sysadm_r:sysadm_t
context. As a result, I never needed to explicitly grant an admin interface
(like nscd_admin) to a specific role.
I'm now trying to allow a role (be it user_r, staff_r or a newly created
role) to (re)start the NSCD init script (which is labeled
nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
nscd_admin(staff_t, staff_r)
However, a user (SELinux user staff_u) doesn't seem to be able to really use
it properly, unless I also give that user the root password (which I don't)
for the run_init command...
I've tried:
~$ /etc/init.d/nscd status
-bash: /etc/init.d/nscd: /sbin/runscript: bad interpreter:
Permission denied
which is because of:
security_compute_sid: invalid context staff_u:system_r:initrc_t for
scontext=staff_u:staff_r:staff_t tcontext=system_u:object_r:nscd_initrc_exec_t
tclass=process
I've tried:
~$ /usr/sbin/run_init /etc/init.d/nscd status
Authenticating oper.
Password:
Could not set exec context to system_u:system_r:initrc_t
which is because of:
avc: denied { setexec } for pid=18505 comm="run_init"
scontext=staff_u:staff_r:staff_t tcontext=staff_u:staff_r:staff_t
tclass=process
I've tried:
~$ sudo /usr/sbin/run_init /etc/init.d/nscd status
but then, after authenticating, run_init asks for the root password which I
don't want to grant.
I've tried:
~$ sudo /etc/init.d/nscd status
sudo: unable to execute /etc/init.d/nscd: Permission denied
For this I don't know what is causing this - only see the standard denials
(rlimitinh, noatsecure, ...) and a getattr on a tty device.
It it "normal" that I would need to allow setexec for the user domain?
What is the correct way to, once a role/user is defined, grant him the
_admin interface and have him start/stop the init scripts?
Wkr,
Sven Vermeulen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/09/2012 02:38 PM, Sven Vermeulen wrote:
> Hi guys,
>
> Currently all administration I do is handled through the sysadm_r:sysadm_t
> context. As a result, I never needed to explicitly grant an admin interface
> (like nscd_admin) to a specific role.
>
> I'm now trying to allow a role (be it user_r, staff_r or a newly created
> role) to (re)start the NSCD init script (which is labeled
> nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
> nscd_admin(staff_t, staff_r)
>
> However, a user (SELinux user staff_u) doesn't seem to be able to really
> use it properly, unless I also give that user the root password (which I
> don't) for the run_init command...
>
> I've tried: ~$ /etc/init.d/nscd status -bash: /etc/init.d/nscd:
> /sbin/runscript: bad interpreter: Permission denied which is because of:
> security_compute_sid: invalid context staff_u:system_r:initrc_t for
> scontext=staff_u:staff_r:staff_t
> tcontext=system_u:object_r:nscd_initrc_exec_t tclass=process
>
> I've tried: ~$ /usr/sbin/run_init /etc/init.d/nscd status Authenticating
> oper. Password: Could not set exec context to system_u:system_r:initrc_t
> which is because of: avc: denied { setexec } for pid=18505 comm="run_init"
> scontext=staff_u:staff_r:staff_t tcontext=staff_u:staff_r:staff_t
> tclass=process
>
> I've tried: ~$ sudo /usr/sbin/run_init /etc/init.d/nscd status but then,
> after authenticating, run_init asks for the root password which I don't
> want to grant.
>
> I've tried: ~$ sudo /etc/init.d/nscd status sudo: unable to execute
> /etc/init.d/nscd: Permission denied For this I don't know what is causing
> this - only see the standard denials (rlimitinh, noatsecure, ...) and a
> getattr on a tty device.
>
> It it "normal" that I would need to allow setexec for the user domain?
>
> What is the correct way to, once a role/user is defined, grant him the
> _admin interface and have him start/stop the init scripts?
>
> Wkr, Sven Vermeulen _______________________________________________
> refpolicy mailing list refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
What OS are you seeing this on?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAkBmsACgkQrlYvE4MpobP53gCggEL0SK5vtlCeRHgnAUKpAmKD
mpIAoMkmepAq3LYXh7/5lEcEoxSuHiJi
=0YHe
-----END PGP SIGNATURE-----
On Aug 9, 2012 8:50 PM, "Daniel J Walsh" <[email protected]> wrote:
> > Currently all administration I do is handled through the
sysadm_r:sysadm_t
> > context. As a result, I never needed to explicitly grant an admin
interface
> > (like nscd_admin) to a specific role.
> >
> > I'm now trying to allow a role (be it user_r, staff_r or a newly created
> > role) to (re)start the NSCD init script (which is labeled
> > nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
> > nscd_admin(staff_t, staff_r)
[... various trials and errors ...]
> >
> What OS are you seeing this on?
This is on Gentoo Hardened. What is the normal approach to take (say on
RedHat Enterprise Linux)? If the role/domain has the _admin interface, just
"sudo <initscript>"? Or is there still a need for run_init?
>From what I gather from the _admin interfaces, we grant the domain the
can_system_change attribute so that the user /can/ transition from (say)
staff_u to system_u, but as far as I can see, you need to run the run_init
command in order to actually change a SELinux user (or runcon) - there is
no way to automatically do that. So I guess I need to call run_init, so
that would leave me two options:
~$ run_init /etc/init.d/nscd
But in this case, my Linux credentials never become root so it'll fail
anyway.
~$ sudo run_init /etc/init.d/nscd
But in this case, run_init wants to get the root password
(re-authenticate), or do I need to enable pam_rootok.so for this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20120809/6b307336/attachment.html
On 08/09/12 14:38, Sven Vermeulen wrote:
> Hi guys,
>
> Currently all administration I do is handled through the sysadm_r:sysadm_t
> context. As a result, I never needed to explicitly grant an admin interface
> (like nscd_admin) to a specific role.
>
> I'm now trying to allow a role (be it user_r, staff_r or a newly created
> role) to (re)start the NSCD init script (which is labeled
> nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
> nscd_admin(staff_t, staff_r)
>
> However, a user (SELinux user staff_u) doesn't seem to be able to really use
> it properly, unless I also give that user the root password (which I don't)
> for the run_init command...
There's a couple things going on here, which center around a clash between run_init and labeled init scripts:
> I've tried:
> ~$ /etc/init.d/nscd status
> -bash: /etc/init.d/nscd: /sbin/runscript: bad interpreter:
> Permission denied
> which is because of:
> security_compute_sid: invalid context staff_u:system_r:initrc_t for
> scontext=staff_u:staff_r:staff_t tcontext=system_u:object_r:nscd_initrc_exec_t
> tclass=process
Fails because there was no transition to run_init_t. It needs something like seutil_init_script_run_runinit(), but only for using nscd_initrc_exec_t for the run_init_t entrypoint.
> I've tried:
> ~$ /usr/sbin/run_init /etc/init.d/nscd status
> Authenticating oper.
> Password:
> Could not set exec context to system_u:system_r:initrc_t
> which is because of:
> avc: denied { setexec } for pid=18505 comm="run_init"
> scontext=staff_u:staff_r:staff_t tcontext=staff_u:staff_r:staff_t
> tclass=process
Same thing, but instead needs seutil_run_runinit(). But this exposes that with run_init right now, the usage of init labeled init scripts falls on its face, because when you're in run_init_t, it can transition to initrc_t using any entrypoint. Run_init would need to be enhanced to do some extra checks to see if you're permitted to run the script.
[cut]
> It it "normal" that I would need to allow setexec for the user domain?
No.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/09/2012 02:58 PM, Christopher J. PeBenito wrote:
> On 08/09/12 14:38, Sven Vermeulen wrote:
>> Hi guys,
>>
>> Currently all administration I do is handled through the
>> sysadm_r:sysadm_t context. As a result, I never needed to explicitly
>> grant an admin interface (like nscd_admin) to a specific role.
>>
>> I'm now trying to allow a role (be it user_r, staff_r or a newly created
>> role) to (re)start the NSCD init script (which is labeled
>> nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
>> nscd_admin(staff_t, staff_r)
>>
>> However, a user (SELinux user staff_u) doesn't seem to be able to really
>> use it properly, unless I also give that user the root password (which I
>> don't) for the run_init command...
>
> There's a couple things going on here, which center around a clash between
> run_init and labeled init scripts:
>
>> I've tried: ~$ /etc/init.d/nscd status -bash: /etc/init.d/nscd:
>> /sbin/runscript: bad interpreter: Permission denied which is because of:
>> security_compute_sid: invalid context staff_u:system_r:initrc_t for
>> scontext=staff_u:staff_r:staff_t
>> tcontext=system_u:object_r:nscd_initrc_exec_t tclass=process
>
> Fails because there was no transition to run_init_t. It needs something
> like seutil_init_script_run_runinit(), but only for using
> nscd_initrc_exec_t for the run_init_t entrypoint.
>
>> I've tried: ~$ /usr/sbin/run_init /etc/init.d/nscd status Authenticating
>> oper. Password: Could not set exec context to system_u:system_r:initrc_t
>> which is because of: avc: denied { setexec } for pid=18505
>> comm="run_init" scontext=staff_u:staff_r:staff_t
>> tcontext=staff_u:staff_r:staff_t tclass=process
>
> Same thing, but instead needs seutil_run_runinit(). But this exposes that
> with run_init right now, the usage of init labeled init scripts falls on
> its face, because when you're in run_init_t, it can transition to initrc_t
> using any entrypoint. Run_init would need to be enhanced to do some extra
> checks to see if you're permitted to run the script.
>
> [cut]
>> It it "normal" that I would need to allow setexec for the user domain
>
> No.
>
>
One of the best things about systemd is we can finally get away from the
run_init bologni..
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAlA6AACgkQrlYvE4MpobNCOgCcDzJEbf8kcwqdN+TQ/6UhE6LI
nCcAnijIKhbE2jpA3eNcKoqSMSMALhCv
=7Rne
-----END PGP SIGNATURE-----
On Thu, Aug 09, 2012 at 08:38:51PM +0200, Sven Vermeulen wrote:
> Currently all administration I do is handled through the sysadm_r:sysadm_t
> context. As a result, I never needed to explicitly grant an admin interface
> (like nscd_admin) to a specific role.
>
> I'm now trying to allow a role (be it user_r, staff_r or a newly created
> role) to (re)start the NSCD init script (which is labeled
> nscd_initrc_exec_t) so I thought it would be sufficient to just add in:
> nscd_admin(staff_t, staff_r)
>
> However, a user (SELinux user staff_u) doesn't seem to be able to really use
> it properly, unless I also give that user the root password (which I don't)
> for the run_init command...
[...]
Thank you all for the feedback, especially Dominick who put me on the right
track.
What I failed to do was to grant the system_r role to the (SELinux) user
that I was giving _admin rights to. Because of that, no transition to
<user>:system_r:initrc_t was possible.
By giving the user the system_r access, it was sufficient to just grant the
_admin to the user/role and use
~$ sudo /etc/init.d/nscd start
Wkr,
Sven Vermeulen