"security_compute_sid: invalid context" error when starting/stopping mysqld daemon

"security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Larry Ross]

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

I have two selinux users that need to be able to stop and start the mysql
daemon, which is started by the initialization scripts.  When the daemon is
stopped and started by the secadm_u user, it ends up in the context
secadm_u:secadm_r:mysqld_t.  When it is stopped and started by the dbadm_u
user, it ends up in the dbadm_u:dbadm_r:mysqld_t context.  When it is
started by the init scripts it ends up in the system_u:system_r:mysqld_t
domain.

I would like it to alway end up in the system_r:mysqld_t domain, but can't
seem to find any documentation that describes how to get that to work.

If I add a role_transition rule to transition the role to system_r when the
executable is run:
role_transition sysadm_r mysqld_safe_exec_t system_r;
role_transition dbadm_r  mysqld_safe_exec_t system_r;
I end up getting these errors:

Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
security_compute_sid:  invalid context dbadm_u:system_r:mysqld_safe_t:s0 for
scontext=dbadm_u:dbadm_r:initrc_t:s0
tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process

I believe I have the rules that should allow this, but obviously I am
missing something.
role dbadm_r types mysqld_safe_t;
role sysadm_r types mysqld_safe_t;
role system_r types mysqld_safe_t;
and this:
allow initrc_t mysqld_safe_t : process transition ;
which is what the "security_compute_sid" message looks like it is missing.

Does anyone know where I can find a good description of how to get a service
to transistion back into system_r when started by a user or have any idea
what I am missing?

  Thank you,
  Larry

[-- Attachment #2: Type: text/html, Size: 1898 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Dominick Grift]

On Wed, 2009-11-04 at 15:57 -0800, Larry Ross wrote:
> I have two selinux users that need to be able to stop and start the
> mysql daemon, which is started by the initialization scripts.  When
> the daemon is stopped and started by the secadm_u user, it ends up in
> the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
> started by the dbadm_u user, it ends up in the
> dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
> scripts it ends up in the system_u:system_r:mysqld_t domain.
>  
> I would like it to alway end up in the system_r:mysqld_t domain, but
> can't seem to find any documentation that describes how to get that to
> work.
>  
> If I add a role_transition rule to transition the role to system_r
> when the executable is run:
> role_transition sysadm_r mysqld_safe_exec_t system_r;
> role_transition dbadm_r  mysqld_safe_exec_t system_r;
> 
> I end up getting these errors:
>  
> Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
> security_compute_sid:  invalid context
> dbadm_u:system_r:mysqld_safe_t:s0 for
> scontext=dbadm_u:dbadm_r:initrc_t:s0
> tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
> 
>  
> I believe I have the rules that should allow this, but obviously I am
> missing something.
> role dbadm_r types mysqld_safe_t;
> role sysadm_r types mysqld_safe_t;
> role system_r types mysqld_safe_t;
> 
> and this:
> allow initrc_t mysqld_safe_t : process transition ;
> which is what the "security_compute_sid" message looks like it is
> missing.
>  
> Does anyone know where I can find a good description of how to get a
> service to transistion back into system_r when started by a user or
> have any idea what I am missing?

I am not sure but i believe that this piece of policy takes care of the
init scipt stuff for restricted administators (example from apache).

	init_labeled_script_domtrans($1, httpd_initrc_exec_t)
	domain_system_change_exemption($1)
	role_transition $2 httpd_initrc_exec_t system_r;
	allow $2 system_r;

You could basically replace the httpd specifics, and the $1 (domain),
and $2 (role).

Also make sure that you map the system_r role to your seuser.

hth, 
>   Thank you,
>   Larry
>  



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Eamon Walsh]

On 11/04/2009 06:57 PM, Larry Ross wrote:
> I have two selinux users that need to be able to stop and start the
> mysql daemon, which is started by the initialization scripts.  When
> the daemon is stopped and started by the secadm_u user, it ends up in
> the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
> started by the dbadm_u user, it ends up in the
> dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
> scripts it ends up in the system_u:system_r:mysqld_t domain.
>  
> I would like it to alway end up in the system_r:mysqld_t domain, but
> can't seem to find any documentation that describes how to get that to
> work.
>  
> If I add a role_transition rule to transition the role to system_r
> when the executable is run:
> role_transition sysadm_r mysqld_safe_exec_t system_r;
> role_transition dbadm_r  mysqld_safe_exec_t system_r;
> I end up getting these errors:
>  
> Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
> security_compute_sid:  invalid context
> dbadm_u:system_r:mysqld_safe_t:s0 for
> scontext=dbadm_u:dbadm_r:initrc_t:s0
> tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
>  
> I believe I have the rules that should allow this, but obviously I am
> missing something.
> role dbadm_r types mysqld_safe_t;
> role sysadm_r types mysqld_safe_t;
> role system_r types mysqld_safe_t;
> and this:
> allow initrc_t mysqld_safe_t : process transition ;
> which is what the "security_compute_sid" message looks like it is missing.
>  
> Does anyone know where I can find a good description of how to get a
> service to transistion back into system_r when started by a user or
> have any idea what I am missing?


The run_init program was designed to solve this problem, take a look at
the man page.

On Fedora at least, the "service" command calls run_init internally, so
doing "service mysqld start" should in theory start it up in the
system_r role.  If you're just running "/etc/init.d/mysld start" it
won't transition.



-- 

Eamon Walsh 
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Larry Ross]

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

On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:

>  On 11/04/2009 06:57 PM, Larry Ross wrote:
> > I have two selinux users that need to be able to stop and start the
> > mysql daemon, which is started by the initialization scripts.  When
> > the daemon is stopped and started by the secadm_u user, it ends up in
> > the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
> > started by the dbadm_u user, it ends up in the
> > dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
> > scripts it ends up in the system_u:system_r:mysqld_t domain.
> >
> > I would like it to alway end up in the system_r:mysqld_t domain, but
> > can't seem to find any documentation that describes how to get that to
> > work.
> >
> > If I add a role_transition rule to transition the role to system_r
> > when the executable is run:
> > role_transition sysadm_r mysqld_safe_exec_t system_r;
> > role_transition dbadm_r  mysqld_safe_exec_t system_r;
> > I end up getting these errors:
> >
> > Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
> > security_compute_sid:  invalid context
> > dbadm_u:system_r:mysqld_safe_t:s0 for
> > scontext=dbadm_u:dbadm_r:initrc_t:s0
> > tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
> >
> > I believe I have the rules that should allow this, but obviously I am
> > missing something.
> > role dbadm_r types mysqld_safe_t;
> > role sysadm_r types mysqld_safe_t;
> > role system_r types mysqld_safe_t;
> > and this:
> > allow initrc_t mysqld_safe_t : process transition ;
> > which is what the "security_compute_sid" message looks like it is
> missing.
> >
> > Does anyone know where I can find a good description of how to get a
> > service to transistion back into system_r when started by a user or
> > have any idea what I am missing?
>
>
> The run_init program was designed to solve this problem, take a look at
> the man page.
>
> On Fedora at least, the "service" command calls run_init internally, so
> doing "service mysqld start" should in theory start it up in the
> system_r role.  If you're just running "/etc/init.d/mysld start" it
> won't transition.
>
That would be great, but I am trying to use this as normal users on a system
to which the root account is locked.  As far as I know, run_init always asks
for the root password.  Is there a way to use it without having access to
the root password?

BTW, I am using RHEL 5.3, do you know if service there calls run_init
internally?

  Thank you,
  Larry



>
>
> --
>
> Eamon Walsh
> National Security Agency
>
>

[-- Attachment #2: Type: text/html, Size: 3358 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Dominick Grift]

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

On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry Ross wrote:
> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
> 
> >  On 11/04/2009 06:57 PM, Larry Ross wrote:
> > > I have two selinux users that need to be able to stop and start the
> > > mysql daemon, which is started by the initialization scripts.  When
> > > the daemon is stopped and started by the secadm_u user, it ends up in
> > > the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
> > > started by the dbadm_u user, it ends up in the
> > > dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
> > > scripts it ends up in the system_u:system_r:mysqld_t domain.
> > >
> > > I would like it to alway end up in the system_r:mysqld_t domain, but
> > > can't seem to find any documentation that describes how to get that to
> > > work.
> > >
> > > If I add a role_transition rule to transition the role to system_r
> > > when the executable is run:
> > > role_transition sysadm_r mysqld_safe_exec_t system_r;
> > > role_transition dbadm_r  mysqld_safe_exec_t system_r;
> > > I end up getting these errors:
> > >
> > > Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
> > > security_compute_sid:  invalid context
> > > dbadm_u:system_r:mysqld_safe_t:s0 for
> > > scontext=dbadm_u:dbadm_r:initrc_t:s0
> > > tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
> > >
> > > I believe I have the rules that should allow this, but obviously I am
> > > missing something.
> > > role dbadm_r types mysqld_safe_t;
> > > role sysadm_r types mysqld_safe_t;
> > > role system_r types mysqld_safe_t;
> > > and this:
> > > allow initrc_t mysqld_safe_t : process transition ;
> > > which is what the "security_compute_sid" message looks like it is
> > missing.
> > >
> > > Does anyone know where I can find a good description of how to get a
> > > service to transistion back into system_r when started by a user or
> > > have any idea what I am missing?
> >
> >
> > The run_init program was designed to solve this problem, take a look at
> > the man page.
> >
> > On Fedora at least, the "service" command calls run_init internally, so
> > doing "service mysqld start" should in theory start it up in the
> > system_r role.  If you're just running "/etc/init.d/mysld start" it
> > won't transition.
> >
> That would be great, but I am trying to use this as normal users on a system
> to which the root account is locked.  As far as I know, run_init always asks
> for the root password.  Is there a way to use it without having access to
> the root password?

I think you can use pam_rootok in /etc/pam.d/run_init. I dont know the details of the top of my head because i use Fedora and the policy that i posted earlier so that i automatically transition to initrc_t without run_init.

hth
> 
> BTW, I am using RHEL 5.3, do you know if service there calls run_init
> internally?
> 
>   Thank you,
>   Larry
> 
> 
> 
> >
> >
> > --
> >
> > Eamon Walsh
> > National Security Agency
> >
> >

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Eamon Walsh]

On 11/06/2009 05:11 PM, Dominick Grift wrote:
> On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry Ross wrote:
>   
>> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:
>>
>>     
>>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
>>>       
>>>> I have two selinux users that need to be able to stop and start the
>>>> mysql daemon, which is started by the initialization scripts.  When
>>>> the daemon is stopped and started by the secadm_u user, it ends up in
>>>> the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
>>>> started by the dbadm_u user, it ends up in the
>>>> dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
>>>> scripts it ends up in the system_u:system_r:mysqld_t domain.
>>>>
>>>> I would like it to alway end up in the system_r:mysqld_t domain, but
>>>> can't seem to find any documentation that describes how to get that to
>>>> work.
>>>>
>>>> If I add a role_transition rule to transition the role to system_r
>>>> when the executable is run:
>>>> role_transition sysadm_r mysqld_safe_exec_t system_r;
>>>> role_transition dbadm_r  mysqld_safe_exec_t system_r;
>>>> I end up getting these errors:
>>>>
>>>> Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
>>>> security_compute_sid:  invalid context
>>>> dbadm_u:system_r:mysqld_safe_t:s0 for
>>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
>>>> tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
>>>>
>>>> I believe I have the rules that should allow this, but obviously I am
>>>> missing something.
>>>> role dbadm_r types mysqld_safe_t;
>>>> role sysadm_r types mysqld_safe_t;
>>>> role system_r types mysqld_safe_t;
>>>> and this:
>>>> allow initrc_t mysqld_safe_t : process transition ;
>>>> which is what the "security_compute_sid" message looks like it is
>>>>         
>>> missing.
>>>       
>>>> Does anyone know where I can find a good description of how to get a
>>>> service to transistion back into system_r when started by a user or
>>>> have any idea what I am missing?
>>>>         
>>>
>>> The run_init program was designed to solve this problem, take a look at
>>> the man page.
>>>
>>> On Fedora at least, the "service" command calls run_init internally, so
>>> doing "service mysqld start" should in theory start it up in the
>>> system_r role.  If you're just running "/etc/init.d/mysld start" it
>>> won't transition.
>>>
>>>       
>> That would be great, but I am trying to use this as normal users on a system
>> to which the root account is locked.  As far as I know, run_init always asks
>> for the root password.  Is there a way to use it without having access to
>> the root password?
>>     
> I think you can use pam_rootok in /etc/pam.d/run_init. I dont know the details of the top of my head because i use Fedora and the policy that i posted earlier so that i automatically transition to initrc_t without run_init.
>   


Yes, /etc/pam.d/run_init controls the password check done by run_init. 
Also, it only asks for the password of whatever user is running it, not
always the root password.  The only reason it asks for a password is to
verify that a human is present.

"run_init id -Z" from sysadm_r should print out
"system_u:system_r:initrc_t".  Other roles might need the following line
of policy to be able to run run_init (using the example of staff):

seutil_run_runinit(staff_t, staff_r)

The policy snippet Dominick posted earlier also works.



>  
> BTW, I am using RHEL 5.3, do you know if service there calls run_init
> internally?

I was mistaken about this, as pointed out by Paul, service doesn't call
run_init.



-- 

Eamon Walsh 
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Larry Ross]

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

On Fri, Nov 6, 2009 at 3:23 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:

>  On 11/06/2009 05:11 PM, Dominick Grift wrote:
> > On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry Ross wrote:
> >
> >> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh <ewalsh@tycho.nsa.gov>
> wrote:
> >>
> >>
> >>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
> >>>
> >>>> I have two selinux users that need to be able to stop and start the
> >>>> mysql daemon, which is started by the initialization scripts.  When
> >>>> the daemon is stopped and started by the secadm_u user, it ends up in
> >>>> the context secadm_u:secadm_r:mysqld_t.  When it is stopped and
> >>>> started by the dbadm_u user, it ends up in the
> >>>> dbadm_u:dbadm_r:mysqld_t context.  When it is started by the init
> >>>> scripts it ends up in the system_u:system_r:mysqld_t domain.
> >>>>
> >>>> I would like it to alway end up in the system_r:mysqld_t domain, but
> >>>> can't seem to find any documentation that describes how to get that to
> >>>> work.
> >>>>
> >>>> If I add a role_transition rule to transition the role to system_r
> >>>> when the executable is run:
> >>>> role_transition sysadm_r mysqld_safe_exec_t system_r;
> >>>> role_transition dbadm_r  mysqld_safe_exec_t system_r;
> >>>> I end up getting these errors:
> >>>>
> >>>> Nov  4 15:41:36 localhost kernel: type=1401 audit(1257378096.775:46):
> >>>> security_compute_sid:  invalid context
> >>>> dbadm_u:system_r:mysqld_safe_t:s0 for
> >>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
> >>>> tcontext=system_u:object_r:mysqld_safe_exec_t:s0 tclass=process
> >>>>
> >>>> I believe I have the rules that should allow this, but obviously I am
> >>>> missing something.
> >>>> role dbadm_r types mysqld_safe_t;
> >>>> role sysadm_r types mysqld_safe_t;
> >>>> role system_r types mysqld_safe_t;
> >>>> and this:
> >>>> allow initrc_t mysqld_safe_t : process transition ;
> >>>> which is what the "security_compute_sid" message looks like it is
> >>>>
> >>> missing.
> >>>
> >>>> Does anyone know where I can find a good description of how to get a
> >>>> service to transistion back into system_r when started by a user or
> >>>> have any idea what I am missing?
> >>>>
> >>>
> >>> The run_init program was designed to solve this problem, take a look at
> >>> the man page.
> >>>
> >>> On Fedora at least, the "service" command calls run_init internally, so
> >>> doing "service mysqld start" should in theory start it up in the
> >>> system_r role.  If you're just running "/etc/init.d/mysld start" it
> >>> won't transition.
> >>>
> >>>
> >> That would be great, but I am trying to use this as normal users on a
> system
> >> to which the root account is locked.  As far as I know, run_init always
> asks
> >> for the root password.  Is there a way to use it without having access
> to
> >> the root password?
> >>
> > I think you can use pam_rootok in /etc/pam.d/run_init. I dont know the
> details of the top of my head because i use Fedora and the policy that i
> posted earlier so that i automatically transition to initrc_t without
> run_init.
> >
>
>
> Yes, /etc/pam.d/run_init controls the password check done by run_init.
> Also, it only asks for the password of whatever user is running it, not
> always the root password.  The only reason it asks for a password is to
> verify that a human is present.
>
> "run_init id -Z" from sysadm_r should print out
> "system_u:system_r:initrc_t".  Other roles might need the following line
> of policy to be able to run run_init (using the example of staff):
>
> seutil_run_runinit(staff_t, staff_r)
>
> The policy snippet Dominick posted earlier also works.
>

I get a syntax error when I try to use that snippet:

# make -f /usr/share/selinux/devel/Makefile
Compiling strict appmysql module
/usr/bin/checkmodule:  loading policy configuration from tmp/appmysql.tmp
appmysql.te:62:ERROR 'syntax error' at token 'init_labeled_script_domtrans'
on line 92695:
init_labeled_script_domtrans(mysqld_safe_t, mysqld_safe_exec_t)
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
make: *** [tmp/appmysql.mod] Error 1
is init_labeled_script_domtrans defined for RHEL 5.3?  I see it used in the
files below:

/usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/virt.if:
init_labeled_script_domtrans($1, virtd_initrc_exec_t)
/usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/avahi.if:
init_labeled_script_domtrans($1, avahi_initrc_exec_t)
/usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/spamassassin.if:
init_labeled_script_domtrans($1,spamd_script_exec_t)
but I don't see it defined anywhere.

  -- Larry


>
>
>
> >
> > BTW, I am using RHEL 5.3, do you know if service there calls run_init
> > internally?
>
> I was mistaken about this, as pointed out by Paul, service doesn't call
> run_init.
>
>
>
> --
>
> Eamon Walsh
> National Security Agency
>
>

[-- Attachment #2: Type: text/html, Size: 6504 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Dominick Grift]

On Mon, 2009-11-09 at 12:54 -0800, Larry Ross wrote:
> On Fri, Nov 6, 2009 at 3:23 PM, Eamon Walsh <ewalsh@tycho.nsa.gov>
> wrote:
>         
>         On 11/06/2009 05:11 PM, Dominick Grift wrote:
>         > On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry Ross wrote:
>         >
>         >> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh
>         <ewalsh@tycho.nsa.gov> wrote:
>         >>
>         >>
>         >>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
>         >>>
>         >>>> I have two selinux users that need to be able to stop and
>         start the
>         >>>> mysql daemon, which is started by the initialization
>         scripts.  When
>         >>>> the daemon is stopped and started by the secadm_u user,
>         it ends up in
>         >>>> the context secadm_u:secadm_r:mysqld_t.  When it is
>         stopped and
>         >>>> started by the dbadm_u user, it ends up in the
>         >>>> dbadm_u:dbadm_r:mysqld_t context.  When it is started by
>         the init
>         >>>> scripts it ends up in the system_u:system_r:mysqld_t
>         domain.
>         >>>>
>         >>>> I would like it to alway end up in the system_r:mysqld_t
>         domain, but
>         >>>> can't seem to find any documentation that describes how
>         to get that to
>         >>>> work.
>         >>>>
>         >>>> If I add a role_transition rule to transition the role to
>         system_r
>         >>>> when the executable is run:
>         >>>> role_transition sysadm_r mysqld_safe_exec_t system_r;
>         >>>> role_transition dbadm_r  mysqld_safe_exec_t system_r;
>         >>>> I end up getting these errors:
>         >>>>
>         >>>> Nov  4 15:41:36 localhost kernel: type=1401
>         audit(1257378096.775:46):
>         >>>> security_compute_sid:  invalid context
>         >>>> dbadm_u:system_r:mysqld_safe_t:s0 for
>         >>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
>         >>>> tcontext=system_u:object_r:mysqld_safe_exec_t:s0
>         tclass=process
>         >>>>
>         >>>> I believe I have the rules that should allow this, but
>         obviously I am
>         >>>> missing something.
>         >>>> role dbadm_r types mysqld_safe_t;
>         >>>> role sysadm_r types mysqld_safe_t;
>         >>>> role system_r types mysqld_safe_t;
>         >>>> and this:
>         >>>> allow initrc_t mysqld_safe_t : process transition ;
>         >>>> which is what the "security_compute_sid" message looks
>         like it is
>         >>>>
>         >>> missing.
>         >>>
>         >>>> Does anyone know where I can find a good description of
>         how to get a
>         >>>> service to transistion back into system_r when started by
>         a user or
>         >>>> have any idea what I am missing?
>         >>>>
>         >>>
>         >>> The run_init program was designed to solve this problem,
>         take a look at
>         >>> the man page.
>         >>>
>         >>> On Fedora at least, the "service" command calls run_init
>         internally, so
>         >>> doing "service mysqld start" should in theory start it up
>         in the
>         >>> system_r role.  If you're just running "/etc/init.d/mysld
>         start" it
>         >>> won't transition.
>         >>>
>         >>>
>         >> That would be great, but I am trying to use this as normal
>         users on a system
>         >> to which the root account is locked.  As far as I know,
>         run_init always asks
>         >> for the root password.  Is there a way to use it without
>         having access to
>         >> the root password?
>         >>
>         > I think you can use pam_rootok in /etc/pam.d/run_init. I
>         dont know the details of the top of my head because i use
>         Fedora and the policy that i posted earlier so that i
>         automatically transition to initrc_t without run_init.
>         >
>         
>         
>         
>         Yes, /etc/pam.d/run_init controls the password check done by
>         run_init.
>         Also, it only asks for the password of whatever user is
>         running it, not
>         always the root password.  The only reason it asks for a
>         password is to
>         verify that a human is present.
>         
>         "run_init id -Z" from sysadm_r should print out
>         "system_u:system_r:initrc_t".  Other roles might need the
>         following line
>         of policy to be able to run run_init (using the example of
>         staff):
>         
>         seutil_run_runinit(staff_t, staff_r)
>         
>         The policy snippet Dominick posted earlier also works.
>  
> I get a syntax error when I try to use that snippet:
>  
> # make -f /usr/share/selinux/devel/Makefile
> Compiling strict appmysql module
> /usr/bin/checkmodule:  loading policy configuration from
> tmp/appmysql.tmp
> appmysql.te:62:ERROR 'syntax error' at token
> 'init_labeled_script_domtrans' on line 92695:
> init_labeled_script_domtrans(mysqld_safe_t, mysqld_safe_exec_t)
> /usr/bin/checkmodule:  error(s) encountered while parsing
> configuration
> make: *** [tmp/appmysql.mod] Error 1
> 
> is init_labeled_script_domtrans defined for RHEL 5.3?  I see it used
> in the files below: 
>  
> /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/virt.if:        init_labeled_script_domtrans($1, virtd_initrc_exec_t)
> /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/avahi.if:       init_labeled_script_domtrans($1, avahi_initrc_exec_t)
> /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/spamassassin.if:        init_labeled_script_domtrans($1,spamd_script_exec_t)
> 
> but I don't see it defined anywhere.  

If it is there then it should be defined in init.if.

You could simply add this to your mysqladm interface file:

########################################
## <summary>
##	Transition to the init script domain
##	on a specified labeled init script.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
## <param name="init_script_file">
##	<summary>
##	Labeled init script file.
##	</summary>
## </param>
#
interface(`init_labeled_script_domtrans',`
	gen_require(`
		type initrc_t;
	')

	domtrans_pattern($1, $2, initrc_t)
	files_search_etc($1)
')

That should atleast make it work for that module. Hopefully the other
policy in the snippit is supported.

>   -- Larry
>  
>         
>         
>         
>         >
>         > BTW, I am using RHEL 5.3, do you know if service there calls
>         run_init
>         > internally?
>         
>         
>         I was mistaken about this, as pointed out by Paul, service
>         doesn't call
>         run_init.
>         
>         
>         
>         --
>         
>         
>         Eamon Walsh
>         National Security Agency
>         
>         
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Larry Ross]

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

On Mon, Nov 9, 2009 at 1:27 PM, Dominick Grift <domg472@gmail.com> wrote:

>  On Mon, 2009-11-09 at 12:54 -0800, Larry Ross wrote:
> > On Fri, Nov 6, 2009 at 3:23 PM, Eamon Walsh <ewalsh@tycho.nsa.gov>
> > wrote:
> >
> >         On 11/06/2009 05:11 PM, Dominick Grift wrote:
> >         > On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry Ross wrote:
> >         >
> >         >> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh
> >         <ewalsh@tycho.nsa.gov> wrote:
> >         >>
> >         >>
> >         >>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
> >         >>>
> >         >>>> I have two selinux users that need to be able to stop and
> >         start the
> >         >>>> mysql daemon, which is started by the initialization
> >         scripts.  When
> >         >>>> the daemon is stopped and started by the secadm_u user,
> >         it ends up in
> >         >>>> the context secadm_u:secadm_r:mysqld_t.  When it is
> >         stopped and
> >         >>>> started by the dbadm_u user, it ends up in the
> >         >>>> dbadm_u:dbadm_r:mysqld_t context.  When it is started by
> >         the init
> >         >>>> scripts it ends up in the system_u:system_r:mysqld_t
> >         domain.
> >         >>>>
> >         >>>> I would like it to alway end up in the system_r:mysqld_t
> >         domain, but
> >         >>>> can't seem to find any documentation that describes how
> >         to get that to
> >         >>>> work.
> >         >>>>
> >         >>>> If I add a role_transition rule to transition the role to
> >         system_r
> >         >>>> when the executable is run:
> >         >>>> role_transition sysadm_r mysqld_safe_exec_t system_r;
> >         >>>> role_transition dbadm_r  mysqld_safe_exec_t system_r;
> >         >>>> I end up getting these errors:
> >         >>>>
> >         >>>> Nov  4 15:41:36 localhost kernel: type=1401
> >         audit(1257378096.775:46):
> >         >>>> security_compute_sid:  invalid context
> >         >>>> dbadm_u:system_r:mysqld_safe_t:s0 for
> >         >>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
> >         >>>> tcontext=system_u:object_r:mysqld_safe_exec_t:s0
> >         tclass=process
> >         >>>>
> >         >>>> I believe I have the rules that should allow this, but
> >         obviously I am
> >         >>>> missing something.
> >         >>>> role dbadm_r types mysqld_safe_t;
> >         >>>> role sysadm_r types mysqld_safe_t;
> >         >>>> role system_r types mysqld_safe_t;
> >         >>>> and this:
> >         >>>> allow initrc_t mysqld_safe_t : process transition ;
> >         >>>> which is what the "security_compute_sid" message looks
> >         like it is
> >         >>>>
> >         >>> missing.
> >         >>>
> >         >>>> Does anyone know where I can find a good description of
> >         how to get a
> >         >>>> service to transistion back into system_r when started by
> >         a user or
> >         >>>> have any idea what I am missing?
> >         >>>>
> >         >>>
> >         >>> The run_init program was designed to solve this problem,
> >         take a look at
> >         >>> the man page.
> >         >>>
> >         >>> On Fedora at least, the "service" command calls run_init
> >         internally, so
> >         >>> doing "service mysqld start" should in theory start it up
> >         in the
> >         >>> system_r role.  If you're just running "/etc/init.d/mysld
> >         start" it
> >         >>> won't transition.
> >         >>>
> >         >>>
> >         >> That would be great, but I am trying to use this as normal
> >         users on a system
> >         >> to which the root account is locked.  As far as I know,
> >         run_init always asks
> >         >> for the root password.  Is there a way to use it without
> >         having access to
> >         >> the root password?
> >         >>
> >         > I think you can use pam_rootok in /etc/pam.d/run_init. I
> >         dont know the details of the top of my head because i use
> >         Fedora and the policy that i posted earlier so that i
> >         automatically transition to initrc_t without run_init.
> >         >
> >
> >
> >
> >         Yes, /etc/pam.d/run_init controls the password check done by
> >         run_init.
> >         Also, it only asks for the password of whatever user is
> >         running it, not
> >         always the root password.  The only reason it asks for a
> >         password is to
> >         verify that a human is present.
> >
> >         "run_init id -Z" from sysadm_r should print out
> >         "system_u:system_r:initrc_t".  Other roles might need the
> >         following line
> >         of policy to be able to run run_init (using the example of
> >         staff):
> >
> >         seutil_run_runinit(staff_t, staff_r)
> >
> >         The policy snippet Dominick posted earlier also works.
> >
> > I get a syntax error when I try to use that snippet:
> >
> > # make -f /usr/share/selinux/devel/Makefile
> > Compiling strict appmysql module
> > /usr/bin/checkmodule:  loading policy configuration from
> > tmp/appmysql.tmp
> > appmysql.te:62:ERROR 'syntax error' at token
> > 'init_labeled_script_domtrans' on line 92695:
> > init_labeled_script_domtrans(mysqld_safe_t, mysqld_safe_exec_t)
> > /usr/bin/checkmodule:  error(s) encountered while parsing
> > configuration
> > make: *** [tmp/appmysql.mod] Error 1
> >
> > is init_labeled_script_domtrans defined for RHEL 5.3?  I see it used
> > in the files below:
> >
> > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/virt.if:
>        init_labeled_script_domtrans($1, virtd_initrc_exec_t)
> > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/avahi.if:
>       init_labeled_script_domtrans($1, avahi_initrc_exec_t)
> >
> /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/spamassassin.if:
>        init_labeled_script_domtrans($1,spamd_script_exec_t)
> >
> > but I don't see it defined anywhere.
>
> If it is there then it should be defined in init.if.
>
> You could simply add this to your mysqladm interface file:
>
> ########################################
> ## <summary>
> ##      Transition to the init script domain
> ##      on a specified labeled init script.
> ## </summary>
> ## <param name="domain">
> ##      <summary>
> ##      Domain allowed access.
> ##      </summary>
> ## </param>
> ## <param name="init_script_file">
> ##      <summary>
> ##      Labeled init script file.
> ##      </summary>
> ## </param>
> #
> interface(`init_labeled_script_domtrans',`
>        gen_require(`
>                type initrc_t;
>        ')
>
>        domtrans_pattern($1, $2, initrc_t)
>        files_search_etc($1)
> ')
>
> That should atleast make it work for that module. Hopefully the other
> policy in the snippit is supported.
>

I have seen this before, and I find it confusing, I get denials:

Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43): avc:
denied  { transition } for  pid=3799 comm="mysql"
path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
I run that denial through audit2allow and I get this:
#============= initrc_t ==============
allow initrc_t mysqld_safe_t:process transition;
That rule is already present in the policy:
allow initrc_t mysqld_safe_t:process transition;
Can anyone tell me why this happens?  Am I missing something?  Is
audit2allow confused?  Is the rule not being honored for some reason?

  -- Larry




>  >   -- Larry
> >
> >
> >
> >
> >         >
> >         > BTW, I am using RHEL 5.3, do you know if service there calls
> >         run_init
> >         > internally?
> >
> >
> >         I was mistaken about this, as pointed out by Paul, service
> >         doesn't call
> >         run_init.
> >
> >
> >
> >         --
> >
> >
> >         Eamon Walsh
> >         National Security Agency
> >
> >
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 10273 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Eamon Walsh]

On 11/10/2009 06:54 PM, Larry Ross wrote:

[snip]
>
> I have seen this before, and I find it confusing, I get denials:
>  
> Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43):
> avc:  denied  { transition } for  pid=3799 comm="mysql"
> path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
> scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
> tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
> I run that denial through audit2allow and I get this:
> #============= initrc_t ==============
> allow initrc_t mysqld_safe_t:process transition;
> That rule is already present in the policy:
> allow initrc_t mysqld_safe_t:process transition;
> Can anyone tell me why this happens?  Am I missing something?  Is
> audit2allow confused?  Is the rule not being honored for some reason?


There are additional "constrain" statements in the policy that can
override allow rules.  They are in the "policy/constraints" file in the
policy source.  In this case, I think you are hitting the following
constraint:

constrain process { transition noatsecure siginh rlimitinh }
(
        r1 == r2 
        or ( t1 == can_change_process_role and t2 == process_user_target )
        or ( t1 == cron_source_domain and t2 == cron_job_domain )
        or ( t1 == can_system_change and r2 == system_r )
        or ( t1 == process_uncond_exempt )
);


Which says you can't transition unless the new role is the same as the
old role (first line) or your type meets one of four exceptions
(remaining lines).  audit2allow does get confused here because the AVC
message doesn't indicate that it's because of a constraint violation. 
This is a known problem.

In the denial above, the source context is initrc_t but running in the
app_dbadm_r role.  I think you want to already be in the system_r role
when you are running as initrc_t.  Which is what the last three lines of
Dominick's snippet do:

# When app_dbadm_t runs the mysql init script, change to initrc_t
init_labeled_script_domtrans(app_dbadm_t, mysqld_initrc_exec_t)

# Exempt app_dbadm_t from the role-change constraint (to system_r only)
domain_system_change_exemption(app_dbadm_t)

# When app_dbadm_r runs the mysqld init script, change to system_r:
role_transition app_dbadm_r mysqld_initrc_exec_t system_r;
allow app_dbadm_r system_r;


If you do have this policy in place, check the label on the
/etc/init.d/mysql script and make sure it corresponds to the one in the
policy.


-- 

Eamon Walsh 
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Larry Ross]

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

On Tue, Nov 10, 2009 at 4:46 PM, Eamon Walsh <ewalsh@tycho.nsa.gov> wrote:

> On 11/10/2009 06:54 PM, Larry Ross wrote:
>
> [snip]
> >
> > I have seen this before, and I find it confusing, I get denials:
> >
> > Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43):
> > avc:  denied  { transition } for  pid=3799 comm="mysql"
> > path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
> > scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
> > tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
> > I run that denial through audit2allow and I get this:
> > #============= initrc_t ==============
> > allow initrc_t mysqld_safe_t:process transition;
> > That rule is already present in the policy:
> > allow initrc_t mysqld_safe_t:process transition;
> > Can anyone tell me why this happens?  Am I missing something?  Is
> > audit2allow confused?  Is the rule not being honored for some reason?
>
>
> There are additional "constrain" statements in the policy that can
> override allow rules.  They are in the "policy/constraints" file in the
> policy source.  In this case, I think you are hitting the following
> constraint:
>
> constrain process { transition noatsecure siginh rlimitinh }
> (
>        r1 == r2
>        or ( t1 == can_change_process_role and t2 == process_user_target )
>        or ( t1 == cron_source_domain and t2 == cron_job_domain )
>        or ( t1 == can_system_change and r2 == system_r )
>        or ( t1 == process_uncond_exempt )
> );
>
>
> Which says you can't transition unless the new role is the same as the
> old role (first line) or your type meets one of four exceptions
> (remaining lines).  audit2allow does get confused here because the AVC
> message doesn't indicate that it's because of a constraint violation.
> This is a known problem.
>

 Eamon,
  Thank you for this, it helps a lot.


>
> In the denial above, the source context is initrc_t but running in the
> app_dbadm_r role.  I think you want to already be in the system_r role
> when you are running as initrc_t.  Which is what the last three lines of
> Dominick's snippet do:
>
> # When app_dbadm_t runs the mysql init script, change to initrc_t
> init_labeled_script_domtrans(app_dbadm_t, mysqld_initrc_exec_t)
>

I had this wrong I had this instead (obviously I misunderstood the arguments
to that interface):
init_labeled_script_domtrans(mysqld_safe_t, mysqld_safe_exec_t)



> # Exempt app_dbadm_t from the role-change constraint (to system_r only)
> domain_system_change_exemption(app_dbadm_t)
>
> # When app_dbadm_r runs the mysqld init script, change to system_r:
> role_transition app_dbadm_r mysqld_initrc_exec_t system_r;
> allow app_dbadm_r system_r;
>

Found it.  I had written rules to transition into the initrc_t domain type
when executing files with the type initrc_exec_t.  This was happening before
the execution of mysqld_safe.

So the timeline was:
service mysql start
- calls /etc/init.d/mysql
  (initrc_exec_t, causes transition into initrc_t)
- calls /usr/bin/mysqld_safe
  (mysqld_safe_exec_t, causes transition into mysqld_safe_t, attempts to
transition into system_r and fails)
so it had tranisitoned into the initrc domain before getting to where
I thought the problem was.

  Thank you everyone for your insight, I learned a lot.
  Larry



>
>
> If you do have this policy in place, check the label on the
> /etc/init.d/mysql script and make sure it corresponds to the one in the
> policy.


>
> --
>
> Eamon Walsh
> National Security Agency
>
>

[-- Attachment #2: Type: text/html, Size: 4888 bytes --]

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Dominick Grift]

On Tue, 2009-11-10 at 15:54 -0800, Larry Ross wrote:
> On Mon, Nov 9, 2009 at 1:27 PM, Dominick Grift <domg472@gmail.com>
> wrote:
>         
>         On Mon, 2009-11-09 at 12:54 -0800, Larry Ross wrote:
>         > On Fri, Nov 6, 2009 at 3:23 PM, Eamon Walsh
>         <ewalsh@tycho.nsa.gov>
>         > wrote:
>         >
>         >         On 11/06/2009 05:11 PM, Dominick Grift wrote:
>         >         > On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry
>         Ross wrote:
>         >         >
>         >         >> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh
>         >         <ewalsh@tycho.nsa.gov> wrote:
>         >         >>
>         >         >>
>         >         >>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
>         >         >>>
>         >         >>>> I have two selinux users that need to be able
>         to stop and
>         >         start the
>         >         >>>> mysql daemon, which is started by the
>         initialization
>         >         scripts.  When
>         >         >>>> the daemon is stopped and started by the
>         secadm_u user,
>         >         it ends up in
>         >         >>>> the context secadm_u:secadm_r:mysqld_t.  When
>         it is
>         >         stopped and
>         >         >>>> started by the dbadm_u user, it ends up in the
>         >         >>>> dbadm_u:dbadm_r:mysqld_t context.  When it is
>         started by
>         >         the init
>         >         >>>> scripts it ends up in the
>         system_u:system_r:mysqld_t
>         >         domain.
>         >         >>>>
>         >         >>>> I would like it to alway end up in the
>         system_r:mysqld_t
>         >         domain, but
>         >         >>>> can't seem to find any documentation that
>         describes how
>         >         to get that to
>         >         >>>> work.
>         >         >>>>
>         >         >>>> If I add a role_transition rule to transition
>         the role to
>         >         system_r
>         >         >>>> when the executable is run:
>         >         >>>> role_transition sysadm_r mysqld_safe_exec_t
>         system_r;
>         >         >>>> role_transition dbadm_r  mysqld_safe_exec_t
>         system_r;
>         >         >>>> I end up getting these errors:
>         >         >>>>
>         >         >>>> Nov  4 15:41:36 localhost kernel: type=1401
>         >         audit(1257378096.775:46):
>         >         >>>> security_compute_sid:  invalid context
>         >         >>>> dbadm_u:system_r:mysqld_safe_t:s0 for
>         >         >>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
>         >         >>>>
>         tcontext=system_u:object_r:mysqld_safe_exec_t:s0
>         >         tclass=process
>         >         >>>>
>         >         >>>> I believe I have the rules that should allow
>         this, but
>         >         obviously I am
>         >         >>>> missing something.
>         >         >>>> role dbadm_r types mysqld_safe_t;
>         >         >>>> role sysadm_r types mysqld_safe_t;
>         >         >>>> role system_r types mysqld_safe_t;
>         >         >>>> and this:
>         >         >>>> allow initrc_t mysqld_safe_t : process
>         transition ;
>         >         >>>> which is what the "security_compute_sid"
>         message looks
>         >         like it is
>         >         >>>>
>         >         >>> missing.
>         >         >>>
>         >         >>>> Does anyone know where I can find a good
>         description of
>         >         how to get a
>         >         >>>> service to transistion back into system_r when
>         started by
>         >         a user or
>         >         >>>> have any idea what I am missing?
>         >         >>>>
>         >         >>>
>         >         >>> The run_init program was designed to solve this
>         problem,
>         >         take a look at
>         >         >>> the man page.
>         >         >>>
>         >         >>> On Fedora at least, the "service" command calls
>         run_init
>         >         internally, so
>         >         >>> doing "service mysqld start" should in theory
>         start it up
>         >         in the
>         >         >>> system_r role.  If you're just running
>         "/etc/init.d/mysld
>         >         start" it
>         >         >>> won't transition.
>         >         >>>
>         >         >>>
>         >         >> That would be great, but I am trying to use this
>         as normal
>         >         users on a system
>         >         >> to which the root account is locked.  As far as I
>         know,
>         >         run_init always asks
>         >         >> for the root password.  Is there a way to use it
>         without
>         >         having access to
>         >         >> the root password?
>         >         >>
>         >         > I think you can use pam_rootok
>         in /etc/pam.d/run_init. I
>         >         dont know the details of the top of my head because
>         i use
>         >         Fedora and the policy that i posted earlier so that
>         i
>         >         automatically transition to initrc_t without
>         run_init.
>         >         >
>         >
>         >
>         >
>         >         Yes, /etc/pam.d/run_init controls the password check
>         done by
>         >         run_init.
>         >         Also, it only asks for the password of whatever user
>         is
>         >         running it, not
>         >         always the root password.  The only reason it asks
>         for a
>         >         password is to
>         >         verify that a human is present.
>         >
>         >         "run_init id -Z" from sysadm_r should print out
>         >         "system_u:system_r:initrc_t".  Other roles might
>         need the
>         >         following line
>         >         of policy to be able to run run_init (using the
>         example of
>         >         staff):
>         >
>         >         seutil_run_runinit(staff_t, staff_r)
>         >
>         >         The policy snippet Dominick posted earlier also
>         works.
>         >
>         > I get a syntax error when I try to use that snippet:
>         >
>         > # make -f /usr/share/selinux/devel/Makefile
>         > Compiling strict appmysql module
>         > /usr/bin/checkmodule:  loading policy configuration from
>         > tmp/appmysql.tmp
>         > appmysql.te:62:ERROR 'syntax error' at token
>         > 'init_labeled_script_domtrans' on line 92695:
>         > init_labeled_script_domtrans(mysqld_safe_t,
>         mysqld_safe_exec_t)
>         > /usr/bin/checkmodule:  error(s) encountered while parsing
>         > configuration
>         > make: *** [tmp/appmysql.mod] Error 1
>         >
>         > is init_labeled_script_domtrans defined for RHEL 5.3?  I see
>         it used
>         > in the files below:
>         >
>         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/virt.if:        init_labeled_script_domtrans($1, virtd_initrc_exec_t)
>         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/avahi.if:       init_labeled_script_domtrans($1, avahi_initrc_exec_t)
>         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/spamassassin.if:        init_labeled_script_domtrans($1,spamd_script_exec_t)
>         >
>         > but I don't see it defined anywhere.
>         
>         
>         If it is there then it should be defined in init.if.
>         
>         You could simply add this to your mysqladm interface file:
>         
>         ########################################
>         ## <summary>
>         ##      Transition to the init script domain
>         ##      on a specified labeled init script.
>         ## </summary>
>         ## <param name="domain">
>         ##      <summary>
>         ##      Domain allowed access.
>         ##      </summary>
>         ## </param>
>         ## <param name="init_script_file">
>         ##      <summary>
>         ##      Labeled init script file.
>         ##      </summary>
>         ## </param>
>         #
>         interface(`init_labeled_script_domtrans',`
>                gen_require(`
>                        type initrc_t;
>                ')
>         
>                domtrans_pattern($1, $2, initrc_t)
>                files_search_etc($1)
>         ')
>         
>         That should atleast make it work for that module. Hopefully
>         the other
>         policy in the snippit is supported.
>  
> I have seen this before, and I find it confusing, I get denials:
>  
> Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43):
> avc:  denied  { transition } for  pid=3799 comm="mysql"
> path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
> scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
> tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
> 
> I run that denial through audit2allow and I get this:
> #============= initrc_t ==============
> allow initrc_t mysqld_safe_t:process transition;
> 
> That rule is already present in the policy:
> allow initrc_t mysqld_safe_t:process transition;
> 
> Can anyone tell me why this happens?  Am I missing something?  Is
> audit2allow confused?  Is the rule not being honored for some reason?

Look for a SELINUX_ERR line. Are there any in your audit.log?

It may (or may not) be because you need might need: allow app_dbadm_r
system_r;

>  
>   -- Larry
>  
>  
>  
>         >   -- Larry
>         >
>         >
>         >
>         >
>         >         >
>         >         > BTW, I am using RHEL 5.3, do you know if service
>         there calls
>         >         run_init
>         >         > internally?
>         >
>         >
>         >         I was mistaken about this, as pointed out by Paul,
>         service
>         >         doesn't call
>         >         run_init.
>         >
>         >
>         >
>         >         --
>         >
>         >
>         >         Eamon Walsh
>         >         National Security Agency
>         >
>         >
>         >
>         
>         
>         
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: "security_compute_sid: invalid context" error when starting/stopping mysqld daemon

[Dominick Grift]

On Wed, 2009-11-11 at 10:32 +0100, Dominick Grift wrote:
> On Tue, 2009-11-10 at 15:54 -0800, Larry Ross wrote:
> > On Mon, Nov 9, 2009 at 1:27 PM, Dominick Grift <domg472@gmail.com>
> > wrote:
> >         
> >         On Mon, 2009-11-09 at 12:54 -0800, Larry Ross wrote:
> >         > On Fri, Nov 6, 2009 at 3:23 PM, Eamon Walsh
> >         <ewalsh@tycho.nsa.gov>
> >         > wrote:
> >         >
> >         >         On 11/06/2009 05:11 PM, Dominick Grift wrote:
> >         >         > On Fri, Nov 06, 2009 at 12:39:57PM -0800, Larry
> >         Ross wrote:
> >         >         >
> >         >         >> On Fri, Nov 6, 2009 at 12:10 PM, Eamon Walsh
> >         >         <ewalsh@tycho.nsa.gov> wrote:
> >         >         >>
> >         >         >>
> >         >         >>>  On 11/04/2009 06:57 PM, Larry Ross wrote:
> >         >         >>>
> >         >         >>>> I have two selinux users that need to be able
> >         to stop and
> >         >         start the
> >         >         >>>> mysql daemon, which is started by the
> >         initialization
> >         >         scripts.  When
> >         >         >>>> the daemon is stopped and started by the
> >         secadm_u user,
> >         >         it ends up in
> >         >         >>>> the context secadm_u:secadm_r:mysqld_t.  When
> >         it is
> >         >         stopped and
> >         >         >>>> started by the dbadm_u user, it ends up in the
> >         >         >>>> dbadm_u:dbadm_r:mysqld_t context.  When it is
> >         started by
> >         >         the init
> >         >         >>>> scripts it ends up in the
> >         system_u:system_r:mysqld_t
> >         >         domain.
> >         >         >>>>
> >         >         >>>> I would like it to alway end up in the
> >         system_r:mysqld_t
> >         >         domain, but
> >         >         >>>> can't seem to find any documentation that
> >         describes how
> >         >         to get that to
> >         >         >>>> work.
> >         >         >>>>
> >         >         >>>> If I add a role_transition rule to transition
> >         the role to
> >         >         system_r
> >         >         >>>> when the executable is run:
> >         >         >>>> role_transition sysadm_r mysqld_safe_exec_t
> >         system_r;
> >         >         >>>> role_transition dbadm_r  mysqld_safe_exec_t
> >         system_r;
> >         >         >>>> I end up getting these errors:
> >         >         >>>>
> >         >         >>>> Nov  4 15:41:36 localhost kernel: type=1401
> >         >         audit(1257378096.775:46):
> >         >         >>>> security_compute_sid:  invalid context
> >         >         >>>> dbadm_u:system_r:mysqld_safe_t:s0 for
> >         >         >>>> scontext=dbadm_u:dbadm_r:initrc_t:s0
> >         >         >>>>
> >         tcontext=system_u:object_r:mysqld_safe_exec_t:s0
> >         >         tclass=process
> >         >         >>>>
> >         >         >>>> I believe I have the rules that should allow
> >         this, but
> >         >         obviously I am
> >         >         >>>> missing something.
> >         >         >>>> role dbadm_r types mysqld_safe_t;
> >         >         >>>> role sysadm_r types mysqld_safe_t;
> >         >         >>>> role system_r types mysqld_safe_t;
> >         >         >>>> and this:
> >         >         >>>> allow initrc_t mysqld_safe_t : process
> >         transition ;
> >         >         >>>> which is what the "security_compute_sid"
> >         message looks
> >         >         like it is
> >         >         >>>>
> >         >         >>> missing.
> >         >         >>>
> >         >         >>>> Does anyone know where I can find a good
> >         description of
> >         >         how to get a
> >         >         >>>> service to transistion back into system_r when
> >         started by
> >         >         a user or
> >         >         >>>> have any idea what I am missing?
> >         >         >>>>
> >         >         >>>
> >         >         >>> The run_init program was designed to solve this
> >         problem,
> >         >         take a look at
> >         >         >>> the man page.
> >         >         >>>
> >         >         >>> On Fedora at least, the "service" command calls
> >         run_init
> >         >         internally, so
> >         >         >>> doing "service mysqld start" should in theory
> >         start it up
> >         >         in the
> >         >         >>> system_r role.  If you're just running
> >         "/etc/init.d/mysld
> >         >         start" it
> >         >         >>> won't transition.
> >         >         >>>
> >         >         >>>
> >         >         >> That would be great, but I am trying to use this
> >         as normal
> >         >         users on a system
> >         >         >> to which the root account is locked.  As far as I
> >         know,
> >         >         run_init always asks
> >         >         >> for the root password.  Is there a way to use it
> >         without
> >         >         having access to
> >         >         >> the root password?
> >         >         >>
> >         >         > I think you can use pam_rootok
> >         in /etc/pam.d/run_init. I
> >         >         dont know the details of the top of my head because
> >         i use
> >         >         Fedora and the policy that i posted earlier so that
> >         i
> >         >         automatically transition to initrc_t without
> >         run_init.
> >         >         >
> >         >
> >         >
> >         >
> >         >         Yes, /etc/pam.d/run_init controls the password check
> >         done by
> >         >         run_init.
> >         >         Also, it only asks for the password of whatever user
> >         is
> >         >         running it, not
> >         >         always the root password.  The only reason it asks
> >         for a
> >         >         password is to
> >         >         verify that a human is present.
> >         >
> >         >         "run_init id -Z" from sysadm_r should print out
> >         >         "system_u:system_r:initrc_t".  Other roles might
> >         need the
> >         >         following line
> >         >         of policy to be able to run run_init (using the
> >         example of
> >         >         staff):
> >         >
> >         >         seutil_run_runinit(staff_t, staff_r)
> >         >
> >         >         The policy snippet Dominick posted earlier also
> >         works.
> >         >
> >         > I get a syntax error when I try to use that snippet:
> >         >
> >         > # make -f /usr/share/selinux/devel/Makefile
> >         > Compiling strict appmysql module
> >         > /usr/bin/checkmodule:  loading policy configuration from
> >         > tmp/appmysql.tmp
> >         > appmysql.te:62:ERROR 'syntax error' at token
> >         > 'init_labeled_script_domtrans' on line 92695:
> >         > init_labeled_script_domtrans(mysqld_safe_t,
> >         mysqld_safe_exec_t)
> >         > /usr/bin/checkmodule:  error(s) encountered while parsing
> >         > configuration
> >         > make: *** [tmp/appmysql.mod] Error 1
> >         >
> >         > is init_labeled_script_domtrans defined for RHEL 5.3?  I see
> >         it used
> >         > in the files below:
> >         >
> >         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/virt.if:        init_labeled_script_domtrans($1, virtd_initrc_exec_t)
> >         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/avahi.if:       init_labeled_script_domtrans($1, avahi_initrc_exec_t)
> >         > /usr/src/redhat/BUILD/serefpolicy-2.4.6/policy/modules/services/spamassassin.if:        init_labeled_script_domtrans($1,spamd_script_exec_t)
> >         >
> >         > but I don't see it defined anywhere.
> >         
> >         
> >         If it is there then it should be defined in init.if.
> >         
> >         You could simply add this to your mysqladm interface file:
> >         
> >         ########################################
> >         ## <summary>
> >         ##      Transition to the init script domain
> >         ##      on a specified labeled init script.
> >         ## </summary>
> >         ## <param name="domain">
> >         ##      <summary>
> >         ##      Domain allowed access.
> >         ##      </summary>
> >         ## </param>
> >         ## <param name="init_script_file">
> >         ##      <summary>
> >         ##      Labeled init script file.
> >         ##      </summary>
> >         ## </param>
> >         #
> >         interface(`init_labeled_script_domtrans',`
> >                gen_require(`
> >                        type initrc_t;
> >                ')
> >         
> >                domtrans_pattern($1, $2, initrc_t)
> >                files_search_etc($1)
> >         ')
> >         
> >         That should atleast make it work for that module. Hopefully
> >         the other
> >         policy in the snippit is supported.
> >  
> > I have seen this before, and I find it confusing, I get denials:
> >  
> > Nov 10 15:03:43 localhost kernel: type=1400 audit(1257894223.988:43):
> > avc:  denied  { transition } for  pid=3799 comm="mysql"
> > path="/usr/bin/mysqld_safe" dev=dm-1 ino=460035
> > scontext=app_dbadm_u:app_dbadm_r:initrc_t:s0
> > tcontext=app_dbadm_u:system_r:mysqld_safe_t:s0 tclass=process
> > 
> > I run that denial through audit2allow and I get this:
> > #============= initrc_t ==============
> > allow initrc_t mysqld_safe_t:process transition;
> > 
> > That rule is already present in the policy:
> > allow initrc_t mysqld_safe_t:process transition;
> > 
> > Can anyone tell me why this happens?  Am I missing something?  Is
> > audit2allow confused?  Is the rule not being honored for some reason?
> 
> Look for a SELINUX_ERR line. Are there any in your audit.log?
> 
> It may (or may not) be because you need might need: allow app_dbadm_r
> system_r;
> 

Also make sure that you map system_r to your selinux user (app_dbadm_u)

example:

semanage user -m -L s0 -r s0 -R "staff_r system_r app_dbadm_r" -P user
app_dbadm_u

> >  
> >   -- Larry
> >  
> >  
> >  
> >         >   -- Larry
> >         >
> >         >
> >         >
> >         >
> >         >         >
> >         >         > BTW, I am using RHEL 5.3, do you know if service
> >         there calls
> >         >         run_init
> >         >         > internally?
> >         >
> >         >
> >         >         I was mistaken about this, as pointed out by Paul,
> >         service
> >         >         doesn't call
> >         >         run_init.
> >         >
> >         >
> >         >
> >         >         --
> >         >
> >         >
> >         >         Eamon Walsh
> >         >         National Security Agency
> >         >
> >         >
> >         >
> >         
> >         
> >         
> > 
> 
> 



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.