need advice for ld_so_cache_t errors

need advice for ld_so_cache_t errors

[Greg Norris]

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

OK, I've finally reached a point where I'm switching my system from
permissive to enforcing mode (and there was much rejoicing! ;-).  Things
seem to be working pretty well, but I'm noticing a number of
ld_so_cache_t errors logged...  in particular, restarting postfix causes
an absolute FLOOD of messages such as the one below (reformatted for my
own sanity).

   Oct  1 17:16:34 sasami kernel: audit(1096668994.071:0): avc:
     denied  { execute } for  pid=3039 path=/etc/ld.so.cache
     dev=hda5 ino=1022 scontext=system_u:system_r:postfix_master_t 
     tcontext=system_u:object_r:ld_so_cache_t tclass=file

This happens for a number of other domains as well, but postfix seems to
have an exceptional affinity.  Should I just go ahead and grant execute
privileges to all the various domains (it seems like this would be a
pain to manage)?  If not, what's the preferred way of squashing these
messages?  I've browsed through CVS, but didn't notice any policy
updates which would obviously affect this issue.


The system in question is an old Pentium II box running Debian sid, with 
the SELinux packages from Russell Coker's repository.  The kernel 
version is 2.6.9-rc3.

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

Re: need advice for ld_so_cache_t errors

[Russell Coker]

On Sat, 2 Oct 2004 09:35, Greg Norris <haphazard@kc.rr.com> wrote:
>    Oct  1 17:16:34 sasami kernel: audit(1096668994.071:0): avc:
>      denied  { execute } for  pid=3039 path=/etc/ld.so.cache
>      dev=hda5 ino=1022 scontext=system_u:system_r:postfix_master_t
>      tcontext=system_u:object_r:ld_so_cache_t tclass=file
>
> This happens for a number of other domains as well, but postfix seems to
> have an exceptional affinity.  Should I just go ahead and grant execute

Strange, I don't have any such problems with the Debian machines I have 
running Postfix.  What versions of Postfix and libc6?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: need advice for ld_so_cache_t errors

[Greg Norris]

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

On Sat, Oct 02, 2004 at 10:59:57AM +1000, Russell Coker wrote:
> Strange, I don't have any such problems with the Debian machines I have 
> running Postfix.  What versions of Postfix and libc6?

Postfix is at 2.1.4-5, and libc6 is 2.3.2.ds1-17... both are current 
according to "apt-cache policy postfix libc6".  I'm getting essentially 
the same message for quite a few other daemons as well... I just picked 
on postfix because it's the most obvious offender.


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

Re: need advice for ld_so_cache_t errors

[Russell Coker]

On Sat, 2 Oct 2004 09:35, Greg Norris <haphazard@kc.rr.com> wrote:
> OK, I've finally reached a point where I'm switching my system from
> permissive to enforcing mode (and there was much rejoicing! ;-).  Things
> seem to be working pretty well, but I'm noticing a number of
> ld_so_cache_t errors logged...  in particular, restarting postfix causes
> an absolute FLOOD of messages such as the one below (reformatted for my
> own sanity).
>
>    Oct  1 17:16:34 sasami kernel: audit(1096668994.071:0): avc:
>      denied  { execute } for  pid=3039 path=/etc/ld.so.cache
>      dev=hda5 ino=1022 scontext=system_u:system_r:postfix_master_t
>      tcontext=system_u:object_r:ld_so_cache_t tclass=file

I have installed the same versions of libc6 and postfix as you but can not 
reproduce this.

Please show me the output of "ls -li /etc/ld.so.cache" on that machine.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: need advice for ld_so_cache_t errors

[Greg Norris]

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

On Sat, Oct 02, 2004 at 01:09:46PM +1000, Russell Coker wrote:
> I have installed the same versions of libc6 and postfix as you but can not 
> reproduce this.
> 
> Please show me the output of "ls -li /etc/ld.so.cache" on that machine.

1022 -rw-r--r--    1 root     root        11997 Sep 29 18:09 /etc/ld.so.cache

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

Re: need advice for ld_so_cache_t errors

[Greg Norris]

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

I'm not sure if this will help, but here's a quick look at the generated 
rules.  There are a lot more entries, of course, but they all seem to be 
granting the exact same privileges against ld_so_cache_t (except for 
ldconfig_t itself, of course).

   $ grep ld_so_cache_t policy.conf | head -5
   # ld_so_cache_t is the type of /etc/ld.so.cache.
   type ld_so_cache_t, file_type, sysadmfile;
   allow sysadm_t ld_so_cache_t:file { read getattr lock ioctl };
   allow sysadm_chkpwd_t ld_so_cache_t:file { read getattr lock ioctl };
   allow sysadm_mail_t ld_so_cache_t:file { read getattr lock ioctl };

Could you check one of your Debian machines, and see if "execute" is 
being included somehow?  I'm not sure how we'd have different results, 
tho, as I'm using your selinux-policy-default package (1.14-2).

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

Re: need advice for ld_so_cache_t errors

[Russell Coker]

On Sun, 3 Oct 2004 02:50, Greg Norris <haphazard@kc.rr.com> wrote:
> Could you check one of your Debian machines, and see if "execute" is
> being included somehow?  I'm not sure how we'd have different results,
> tho, as I'm using your selinux-policy-default package (1.14-2).

I've just run apol from setools and it tells me that no execute access is 
being granted.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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: need advice for ld_so_cache_t errors

[Greg Norris]

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

On Mon, Oct 04, 2004 at 01:08:35AM +1000, Russell Coker wrote:
> I've just run apol from setools and it tells me that no execute access is 
> being granted.

Hmmm... unfortunately, I'm stumped at this point.  If I have some time 
tomorrow I'll try out the 1.16 policy from the NSA website, and see if 
it makes any difference.

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

Re: need advice for ld_so_cache_t errors

[Greg Norris]

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

Another (probably related) oddity... I'm seeing a number of the 
following messages logged.  This one isn't near as frequent as the 
ld_so_cache_t error, but it seems to be a fairly regular occurrence.  

   Oct  4 19:14:48 sasami kernel: audit(1096935288.401:0): avc:
     denied  { execute } for  pid=2786 
     path=/usr/lib/locale/locale-archive dev=hdb5 
     ino=16191 scontext=gnorris:staff_r:staff_t 
     tcontext=system_u:object_r:locale_t tclass=file

What I'm finding really confusing is why anything would be trying to
execute either ld.so.cache or locale-archive... neither have execute
permissions set normally anyway.

Ponderous!


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

Re: need advice for ld_so_cache_t errors

[Greg Norris]

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

Ok, I've (finally) figured out what's actually failing.  When I strace a 
tail command on my selinux box, the following entries seem of interest:

   open("/etc/ld.so.cache", O_RDONLY)      = 3
   fstat64(3, {st_mode=S_IFREG|0644, st_size=11997, ...}) = 0
   old_mmap(NULL, 11997, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
   close(3)                                = 0

   open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
   fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0
   mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
   close(3)                                = 0

When I strace the same command on my non-selinux box (also running
Debian sid), both of the mmaps are successful.  So I guess I need to
figure out why the the mmaps are being blocked.

I'm not sure why selinux would log that as a denied execute, tho.

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

Re: need advice for ld_so_cache_t errors

[Tom London]

see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505

Believe there is a bug in mprotect().

tom

Greg Norris wrote:

>Ok, I've (finally) figured out what's actually failing.  When I strace a 
>tail command on my selinux box, the following entries seem of interest:
>
>   open("/etc/ld.so.cache", O_RDONLY)      = 3
>   fstat64(3, {st_mode=S_IFREG|0644, st_size=11997, ...}) = 0
>   old_mmap(NULL, 11997, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>   close(3)                                = 0
>
>   open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
>   fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0
>   mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>   close(3)                                = 0
>
>When I strace the same command on my non-selinux box (also running
>Debian sid), both of the mmaps are successful.  So I guess I need to
>figure out why the the mmaps are being blocked.
>
>I'm not sure why selinux would log that as a denied execute, tho.
>  
>

--
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: need advice for ld_so_cache_t errors

[Greg Norris]

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

On Mon, Oct 04, 2004 at 08:45:53PM -0700, Tom London wrote:
> see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505
> 
> Believe there is a bug in mprotect().

That sounds like a very similar issue, but unfortunately the patch
didn't seem to make any difference.  On the plus side, reverting from
2.6.9-rc3 to 2.6.8.1 (plus the kernel patch from the NSA website) seems
to have taken care of it... guess I'll try that first in the future. ;-)

Thanx to everyone for your assistance.


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

Re: need advice for ld_so_cache_t errors

[Stephen Smalley]

On Mon, 2004-10-04 at 21:00, Greg Norris wrote:
> Ok, I've (finally) figured out what's actually failing.  When I strace a 
> tail command on my selinux box, the following entries seem of interest:
> 
>    open("/etc/ld.so.cache", O_RDONLY)      = 3
>    fstat64(3, {st_mode=S_IFREG|0644, st_size=11997, ...}) = 0
>    old_mmap(NULL, 11997, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>    close(3)                                = 0
> 
>    open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
>    fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0
>    mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>    close(3)                                = 0
> 
> When I strace the same command on my non-selinux box (also running
> Debian sid), both of the mmaps are successful.  So I guess I need to
> figure out why the the mmaps are being blocked.
> 
> I'm not sure why selinux would log that as a denied execute, tho.

Legacy binary?  Read-only mmap/mprotect requests are now automatically
translated to read-execute for backward compatibility when executing
legacy binaries due to the NX support that was added to the upstream
kernel.  That translation happens before the SELinux hooks are
encountered, so SELinux just sees it as a read/execute request.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: need advice for ld_so_cache_t errors

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Mon, 2004-10-04 at 21:00, Greg Norris wrote:
>  
>
>>Ok, I've (finally) figured out what's actually failing.  When I strace a 
>>tail command on my selinux box, the following entries seem of interest:
>>
>>   open("/etc/ld.so.cache", O_RDONLY)      = 3
>>   fstat64(3, {st_mode=S_IFREG|0644, st_size=11997, ...}) = 0
>>   old_mmap(NULL, 11997, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>>   close(3)                                = 0
>>
>>   open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
>>   fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0
>>   mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
>>   close(3)                                = 0
>>
>>When I strace the same command on my non-selinux box (also running
>>Debian sid), both of the mmaps are successful.  So I guess I need to
>>figure out why the the mmaps are being blocked.
>>
>>I'm not sure why selinux would log that as a denied execute, tho.
>>    
>>
>
>Legacy binary?  Read-only mmap/mprotect requests are now automatically
>translated to read-execute for backward compatibility when executing
>legacy binaries due to the NX support that was added to the upstream
>kernel.  That translation happens before the SELinux hooks are
>encountered, so SELinux just sees it as a read/execute request.
>
>  
>
Ok I am seeing this stuff alot right now.  Mainly when running mozilla 
with java. 

Seems there is a problem with either glib or m_protect.

kernel-2.6.8-1.603
glibc-2.3.3-66


[-- Attachment #2: execute --]
[-- Type: text/plain, Size: 1242 bytes --]

Oct  8 16:57:13 celtics kernel: audit(1097269033.954:10750480): avc:  denied  { execute } for  pid=22541 path=/etc/ld.so.cache dev=dm-0 ino=624955 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:ld_so_cache_t tclass=file
Oct  8 16:57:13 celtics kernel: audit(1097269033.967:10750749): avc:  denied  { execute } for  pid=22541 path=/tmp/hsperfdata_dwalsh/22541 dev=dm-0 ino=3118259 scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_tmp_t tclass=file
Oct  8 16:57:14 celtics kernel: audit(1097269034.118:10751092): avc:  denied  { execute } for  pid=22541 path=/usr/java/jre1.5.0/lib/i386/client/classes.jsa dev=dm-0 ino=2380505 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:usr_t tclass=file
Oct  8 16:57:14 celtics kernel: audit(1097269034.172:10752097): avc:  denied  { execute } for  pid=22541 path=/usr/lib/locale/locale-archive dev=dm-0 ino=1786056 scontext=user_u:user_r:user_mozilla_t tcontext=root:object_r:locale_t tclass=file
Oct  8 16:57:14 celtics kernel: audit(1097269034.173:10752118): avc:  denied  { execute } for  pid=22541 path=/usr/lib/locale/en_US.utf8/LC_CTYPE dev=dm-0 ino=2032775 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:locale_t tclass=file

Re: need advice for ld_so_cache_t errors

[Stephen Smalley]

On Fri, 2004-10-08 at 17:02, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> 
> >On Mon, 2004-10-04 at 21:00, Greg Norris wrote:
> >  
> >
> >>Ok, I've (finally) figured out what's actually failing.  When I strace a 
> >>tail command on my selinux box, the following entries seem of interest:
> >>
> >>   open("/etc/ld.so.cache", O_RDONLY)      = 3
> >>   fstat64(3, {st_mode=S_IFREG|0644, st_size=11997, ...}) = 0
> >>   old_mmap(NULL, 11997, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
> >>   close(3)                                = 0
> >>
> >>   open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
> >>   fstat64(3, {st_mode=S_IFREG|0644, st_size=1589840, ...}) = 0
> >>   mmap2(NULL, 1589840, PROT_READ, MAP_PRIVATE, 3, 0) = -1 EACCES (Permission denied)
> >>   close(3)                                = 0
> >>
> >>When I strace the same command on my non-selinux box (also running
> >>Debian sid), both of the mmaps are successful.  So I guess I need to
> >>figure out why the the mmaps are being blocked.
> >>
> >>I'm not sure why selinux would log that as a denied execute, tho.
> >>    
> >>
> >
> >Legacy binary?  Read-only mmap/mprotect requests are now automatically
> >translated to read-execute for backward compatibility when executing
> >legacy binaries due to the NX support that was added to the upstream
> >kernel.  That translation happens before the SELinux hooks are
> >encountered, so SELinux just sees it as a read/execute request.
> >
> >  
> >
> Ok I am seeing this stuff alot right now.  Mainly when running mozilla 
> with java. 
> 
> Seems there is a problem with either glib or m_protect.
> 
> kernel-2.6.8-1.603
> glibc-2.3.3-66
> 
> 
> ______________________________________________________________________
> Oct  8 16:57:13 celtics kernel: audit(1097269033.954:10750480): avc:  denied  { execute } for  pid=22541 path=/etc/ld.so.cache dev=dm-0 ino=624955 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:ld_so_cache_t tclass=file
> Oct  8 16:57:13 celtics kernel: audit(1097269033.967:10750749): avc:  denied  { execute } for  pid=22541 path=/tmp/hsperfdata_dwalsh/22541 dev=dm-0 ino=3118259 scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_tmp_t tclass=file
> Oct  8 16:57:14 celtics kernel: audit(1097269034.118:10751092): avc:  denied  { execute } for  pid=22541 path=/usr/java/jre1.5.0/lib/i386/client/classes.jsa dev=dm-0 ino=2380505 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:usr_t tclass=file
> Oct  8 16:57:14 celtics kernel: audit(1097269034.172:10752097): avc:  denied  { execute } for  pid=22541 path=/usr/lib/locale/locale-archive dev=dm-0 ino=1786056 scontext=user_u:user_r:user_mozilla_t tcontext=root:object_r:locale_t tclass=file
> Oct  8 16:57:14 celtics kernel: audit(1097269034.173:10752118): avc:  denied  { execute } for  pid=22541 path=/usr/lib/locale/en_US.utf8/LC_CTYPE dev=dm-0 ino=2032775 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:locale_t tclass=file

Does this still occur with the latest rawhide kernel (or 2.6.9-rc3-bk8
or later upstream)?  Ingo said that there was one more NX fix committed
recently.

If this is going to be a problem, perhaps we should save the original
protection flags prior to alteration by the read_implies_exec logic and
pass the original flags to the security hook?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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.