[refpolicy] How to give _admin rights?

[refpolicy] How to give _admin rights?

[Sven Vermeulen]

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] How to give _admin rights?

[Daniel J Walsh]

-----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-----

[refpolicy] How to give _admin rights?

[Sven Vermeulen]

On Aug 9, 2012 8:50 PM, "Daniel J Walsh" <dwalsh@redhat.com> 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 

[refpolicy] How to give _admin rights?

[Christopher J. PeBenito]

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
www.tresys.com | oss.tresys.com

[refpolicy] How to give _admin rights?

[Daniel J Walsh]

-----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-----

[refpolicy] How to give _admin rights?

[Sven Vermeulen]

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