initrc_t has no execmod in targeted policy

initrc_t has no execmod in targeted policy

[Vladimir Simonov]

Hi all,

Trying to launch my network daemon fron init.d on
Fedora Core 4 I see "avc:  denied  { execmod } ..."
in audit.log. The daemon loads some shared libraries
via dlopen. If I guessed right, code relocation at load
time modifies code segment and violates "no execmod
for initrc_t" rile.

The questions:
1. Is my guess correct?
2. If yes, should it be considered as policy drawback
(FC4 uses policy.19) or I'm missing something?
3. How to add execmod to system_u:system_r:initrc_t
type without full policy rebuild?

Best regards
Vladimir Simonov

--
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: initrc_t has no execmod in targeted policy

[Stephen Smalley]

On Mon, 2006-02-06 at 10:33 +0300, Vladimir Simonov wrote:
> Hi all,
> 
> Trying to launch my network daemon fron init.d on
> Fedora Core 4 I see "avc:  denied  { execmod } ..."
> in audit.log. The daemon loads some shared libraries
> via dlopen. If I guessed right, code relocation at load
> time modifies code segment and violates "no execmod
> for initrc_t" rile.
> 
> The questions:
> 1. Is my guess correct?

execmod usually indicates a text relocation, which reflects a problem in
the DSO that should be fixed if possible.  See:
http://people.redhat.com/drepper/selinux-mem.html
http://people.redhat.com/drepper/dsohowto.pdf

> 2. If yes, should it be considered as policy drawback
> (FC4 uses policy.19) or I'm missing something?

No, certainly not for initrc_t, as you shouldn't run your daemon
directly in that domain anyway.

> 3. How to add execmod to system_u:system_r:initrc_t
> type without full policy rebuild?

You don't want to do that - you want to define a new domain for your
daemon (or if it has the same security requirements as a daemon that
already has policy and you don't care about separating them, you could
just label it with the same entrypoint type).  

On FC4, you still have to install the policy sources package, add your
files defining your own rules, and rebuild the entire binary policy.
The modular policy support is coming in FC5.

-- 
Stephen Smalley
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: initrc_t has no execmod in targeted policy

[Vladimir Simonov]

Hi Stephen,

Thank you for your feedback.

Really dlopen-ed shared libs are quite typical -
created with --shared, -fpic, etc. They (and daemon itself)
do not use direct mmap/mprotect syscalls (just libc calls).
Daemon is called from simple bash init script located in
/etc/init.d. And I don't put bash script/demon/libs
into initrc_t domain directly. I suspect they are in initrc_t
by selinux magic.

So some question remains:
Does selinux (on FC4) permit dlopen call from initrc_t domain?
If not, then why?

I'm afraid even if I put all above staff into separate domain
(but start daemon from init scripts) the daemon will be moved
to initrc_t domain by selinux. Am I correct?

Thank you in advance
Vladimir Simonov


Stephen Smalley wrote:
> On Mon, 2006-02-06 at 10:33 +0300, Vladimir Simonov wrote:
> 
>>Hi all,
>>
>>Trying to launch my network daemon fron init.d on
>>Fedora Core 4 I see "avc:  denied  { execmod } ..."
>>in audit.log. The daemon loads some shared libraries
>>via dlopen. If I guessed right, code relocation at load
>>time modifies code segment and violates "no execmod
>>for initrc_t" rile.
>>
>>The questions:
>>1. Is my guess correct?
> 
> 
> execmod usually indicates a text relocation, which reflects a problem in
> the DSO that should be fixed if possible.  See:
> http://people.redhat.com/drepper/selinux-mem.html
> http://people.redhat.com/drepper/dsohowto.pdf
> 
> 
>>2. If yes, should it be considered as policy drawback
>>(FC4 uses policy.19) or I'm missing something?
> 
> 
> No, certainly not for initrc_t, as you shouldn't run your daemon
> directly in that domain anyway.
> 
> 
>>3. How to add execmod to system_u:system_r:initrc_t
>>type without full policy rebuild?
> 
> 
> You don't want to do that - you want to define a new domain for your
> daemon (or if it has the same security requirements as a daemon that
> already has policy and you don't care about separating them, you could
> just label it with the same entrypoint type).  
> 
> On FC4, you still have to install the policy sources package, add your
> files defining your own rules, and rebuild the entire binary policy.
> The modular policy support is coming in FC5.
> 

--
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: initrc_t has no execmod in targeted policy

[Stephen Smalley]

On Mon, 2006-02-06 at 22:35 +0300, Vladimir Simonov wrote:
> Really dlopen-ed shared libs are quite typical -
> created with --shared, -fpic, etc. They (and daemon itself)
> do not use direct mmap/mprotect syscalls (just libc calls).
> Daemon is called from simple bash init script located in
> /etc/init.d. And I don't put bash script/demon/libs
> into initrc_t domain directly. I suspect they are in initrc_t
> by selinux magic.

dlopen doesn't normally require text relocations - that reflects a
defect in how the DSO was built usually.  See the URLs I referenced for
more info.

Programs stay in the caller's domain unless a domain transition is
defined.  So your daemon stays in initrc_t unless you put it into its
own domain.

> So some question remains:
> Does selinux (on FC4) permit dlopen call from initrc_t domain?
> If not, then why?

See above.  The question is what DSO has text relocations, and why.

> I'm afraid even if I put all above staff into separate domain
> (but start daemon from init scripts) the daemon will be moved
> to initrc_t domain by selinux. Am I correct?

No, if you define a domain for the daemon and label its executable with
the corresponding entrypoint type, then executing it (directly or via
the init script) will transition into the daemon's domain when the
executable is run.  

-- 
Stephen Smalley
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: initrc_t has no execmod in targeted policy

[Vladimir Simonov]

Hi,

Ok. Thank you a lot.
I'll investigate deeper which code triggers
relocation.

Best regards
Vladimir Simonov

Stephen Smalley wrote:
> On Mon, 2006-02-06 at 22:35 +0300, Vladimir Simonov wrote:
> 
>>Really dlopen-ed shared libs are quite typical -
>>created with --shared, -fpic, etc. They (and daemon itself)
>>do not use direct mmap/mprotect syscalls (just libc calls).
>>Daemon is called from simple bash init script located in
>>/etc/init.d. And I don't put bash script/demon/libs
>>into initrc_t domain directly. I suspect they are in initrc_t
>>by selinux magic.
> 
> 
> dlopen doesn't normally require text relocations - that reflects a
> defect in how the DSO was built usually.  See the URLs I referenced for
> more info.
> 
> Programs stay in the caller's domain unless a domain transition is
> defined.  So your daemon stays in initrc_t unless you put it into its
> own domain.
> 
> 
>>So some question remains:
>>Does selinux (on FC4) permit dlopen call from initrc_t domain?
>>If not, then why?
> 
> 
> See above.  The question is what DSO has text relocations, and why.
> 
> 
>>I'm afraid even if I put all above staff into separate domain
>>(but start daemon from init scripts) the daemon will be moved
>>to initrc_t domain by selinux. Am I correct?
> 
> 
> No, if you define a domain for the daemon and label its executable with
> the corresponding entrypoint type, then executing it (directly or via
> the init script) will transition into the daemon's domain when the
> executable is run.  
> 

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