|
> Subject: Re: SELinux problem on ARM: error while loading shared libraries > From: sds@xxxxxxxxxxxxx > To: harrytaurus2002@xxxxxxxxxxx > CC: selinux@xxxxxxxxxxxxx; refpolicy@xxxxxxxxxxxxxxx > Date: Mon, 3 May 2010 12:54:49 -0400 > > On Sun, 2010-05-02 at 04:22 +0000, TaurusHarry wrote: > > Hi SELinux experts, > > > > Thanks for reading my questions. I am trying refpolicy-2.20091117 with > > MLS enabled on the ARM architecture and run into a huge number of > > error messages of "error while loading shared libraries: cannot > > restore segment prot after reloc: Permission denied" during system > > booting up such as: > > > > 1. mount: error while loading shared libraries: cannot restore segment > > prot after reloc: Permission denied > > awk: cmd. line:1: fatal: cannot open file `/proc/mounts' for reading > > (No such fi! le or directory) > > awk: cmd. line:1: fatal: cannot open file `/proc/devices' for reading > > (No such file or directory) > > awk: cmd. line:1: fatal: cannot open file `/proc/misc' for reading (No > > such file or directory) > > awk: cmd. line:1: fatal: cannot open file `/proc/mounts' for reading > > (No such file or directory) > > > > 2. Enabling local filesystem quotas: /sbin/quot! aon: error while > > loading shared libraries: cannot restore segment prot after reloc: > > Permission denied > > > > 3. Starting sendmail: makemap: error while loading shared libraries: > > cannot restore segment prot after reloc: Permission denied > > makemap: error while loading shared libraries: cannot restore segment > > prot after reloc: Permission denied > > makemap: error while loading shared libraries: cannot restore segment > > pr! ot after reloc: Permission denied > > makemap: error while lo ading shared libraries: cannot restore segment > > prot after reloc: Permission denied > > > > 4. Starting sm-client: /usr/sbin/sendmail: error while loading shared > > libraries: cannot restore segment prot after reloc: Permission denied > > > > > > When I applied "enforcing=0" I could get below SELinux AVC denied > > messages about the domains of > > mount/udevd/cron/quota/sendmail/makemap/chkpwd has no "execmod" > > permissions on each of their own entry file: > > > > > > type=1400 audit(946684809.427:4): avc: denie! d { execmod } for > > pid=981 comm="mount" path="/bin/mount" d ev=mmcblk0p1 ino=32215 > > scontext=system_u:system_r:udev_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:mount_exec_t:s0 tclass=file > > > > type=1400 audit(946684815.880:5): avc: denied { execmod } for > > pid=999 co! mm="udevd" path="/sbin/udevd" dev=mmcblk0p1 ino=24158 > > scontext=system_u:system_r:udev_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:udev_exec_t:s0 tclass=file > > > > type=1400 audit(946684817.302:6): avc: denied { execmod } for > > pid=1092 comm="edd_id" path="/lib/udev/edd_id" dev=mmcblk0p1 ino=24407 > > scontext=system_u:system_r:udev_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:bin_t:s0 tclass=file > > > > type=1400 audit(946684853.786:9): avc: denied { execmod } for > > pid=1943 comm="quotaon" path="/sbin/quotaon" dev=mmcblk0p1 ino=24269 > > scontext=system_u:system_r:quota_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:quota_exec_t:s0 tclass=file > > > > type=1400 audit(946684860.224:15): avc: denied { execmod } for > > pid=! 2028 comm="portmap" path="/sbin/portmap" dev=mmcblk0p1 ino=24229 > > scontext=syste! m_u:system_r:portmap_t:s0-s15:c0.c255 > > tcontext=system_u:o bject_r:portmap_exec_t:s0 tclass=file > > > > type=1400 audit(946684883.638:19): avc: denied { execmod } for > > pid=2139 comm="makemap" path="/usr/sbin/makemap" dev=mmcblk0p1 > > ino=80801 scontext=system_u:system_r:initrc_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:bin_t:s0 tclass=file > > > > type=1400 audit(946684885.661:20): avc: denied { execmod } for > > pid=2143 comm="newaliases" path="/usr/sbin/sendmail" dev=mmcblk0p1 > > ino=80835 scontext=system_u:system_r:sendmail_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file > > > > type=1400 audit(946684889.403:22): avc: denied { execmod } for > > pid=2172 comm="crond" path="/usr/sbin/crond" dev=mmcblk0p1 ino=80575 > > scontext=system_u:system_r:crond_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:crond_exec_t:s0 tclass=file > > > &g! t; type=1400! audit(946684890.021:24): avc: denied { execmod } > > for  ; pid=2190 comm="atd" path="/usr/sbin/atd" dev=mmcblk0p1 > > ino=80569 scontext=system_u:system_r:crond_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:crond_exec_t:s0 tclass=file > > > > type=1400 audit(946684951.974:25): avc: denied { execmod } for > > pid=2246 comm="unix_chkpwd" path="/sbin/unix_chkpwd" dev=mmcblk0p1 > > ino=24262 scontext=system_u:system_r:chkpwd_t:s0-s15:c0.c255 > > tcontext=system_u:object_r:chkpwd_exec_t:s0 tclass=file > > > > > > From the book of <<SELinux By Example>>, the execmod privilege is used > > to protect a process domain from executing a memory-mapped file once > > it is modified, and I know that a UNIX system normally won't do > > loading relocation for the executables but for the shared libraries, I > > don'! t understand why the userspace domains(for example, mount_t) would > > ever need the execmod privilege on its entry point file(mount_exec_t)? > > > > BTW, above problems exist solely on the ARM target and I am able to > > run the same SELinux policy on! x86_64 or ppc32 targets, so I guess it > > may not be the policy itself but some architecture dependent thing > > that caused the problem. > > > > Any comments are greatly appreciated! > > Can you identify the specific ARM target and the compiler toolchain used > for it? > > Sounds like it is performing text relocations on the executable. That > could happen for example if the executable were linked with -pie but > contained an object that was not compiled with -fpic. > > http://people.redhat.com/drepper/textrelocs.html > Hi Stephen, Many many thanks for your suggestions! These days I have read through the articles written by Ulrich Drepper and! got a deeper understanding of execmod permission in SELinux. It turns out that my ARM cross-compiler has not handled the -pie option properly - If only the -fpie is used the executable is pure PIC code but if the -pie is used as well then the binary would require text reloc. The -pie will make the binary DYN rather than EXEC(readelf -h | grep Type) and only my ARM cross-compiler will introduce text reloc on the pair of "-fpie -pie", but other compilers such as local x86_32 compiler or ppc32 cross-compiler do not. Now that the culprit has been found, I will figure out how to fix it next. I will update you when I make any progress. Best regards, Harry > -- > Stephen Smalley > National Security Agency > 使用Messenger保护盾2.0，支持多账号登录！ 现在就下载！ |
