Re: other problems after selinux-policy-targeted-1.17.30-3.2
by Geoff Hogan
I have had the same problem with openoffice 1.9.104. I tried the
setsebool command suggested below without success. I have tried
restorecon -v /opt/openoffice.org1.9.104/program/libicudata.so.26.0.1
ls -alZ /opt/openoffice.org1.9.104/program/libicudata.so.26.0.1 returns:
-r--r--r-- root root system_u:object_r:usr_t
/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1
I am new to SELinux (it has just worked until now). Do I need the
policy source package installed to do these things (which I don't), or
just the policy rpm?
Many thanks.
Geoff
On Tue, 2005-06-14 at 14:23 +0200, Markus Ralser wrote:
> Dear all,
>
> an old error seems to reappear after uptdate to
> selinux-policy-targeted-1.17.30-3.2.
>
> When I try to start my openoffice now, i get
>
> /etc/openoffice.org-1.9/program/soffice.bin: error
> while loading shared libraries:
> /opt/openoffice.org1.9.104/program/libicudata.so.26:
> cannot restore segment prot after reloc: Permission
> denied
Try:
setsebool -P allow_execmod=true allow_execmem=true
This is a workaround for an upgrade bug.
18 years, 10 months
help with Kernel panic after update
by Steven Knight
Help!
Yesterday afternoon, my home FC3 system took a power hit (not
unusual, unfortunately). Nothing seemed particularly amiss, it
came back up on its own (while I was still at work) and I reconnected
and used it for several hours without noticing anything unsual.
This is probably unrelated to what follows, but I mention it just
in case it's not.
Upon arriving home, I logged back in on my desktop and noticed my
Red Hat update icon on the top taskbar was red and pulsing. I went
ahead and su'ed up and fired up "yum update". It asked for permission
to update about 17 packages (I noticed GAIM on the list, but otherwise
didn't pay much attention), but being used to reliable updates before,
I went ahead and installed all of them without a second thought.
First sign of trouble: I could no longer ls, df, or do just about
anything. Error messages were complaining about "Permission denied"
for /lib/tls/libc.so.6 (and possibly other libraries), even when I
tried to do anything from my su shell.
Figuring (naively) that I had some kind of package version skew, I
(naively) tried rebooting to see if that would clear things up.
Bad, hasty decision: I now get an immediate kernel panic as follows
(modulo typos from transcribing the information by hand):
Uncompressing Linux... Ok, booting the kernel.
ACPI: BIOS age (1999) fails cutoff (2001, acpi=force is required to enable ACPI
audit(1118711202.065:0): initialized
Red Hat nash version 4.1.18 starting
audit(1118711209.899:0): avc: denied { execmod } for pid=1 comm=init path=/lib/tls/libc-2.3.5.so dev=hdd2 ino=528350 scontext=user_u:system_r:unconfined_t tcontext=root:object_r:filet tcall=file
/sbin/init: error while loading shared libraries: /lib/tls/libc.so.6: cannot apply additional memory protection after relocation: Permission denied
Kernel panic - not syncing: Attempted to kill init!
After poking around, I figured out that this permission error was
connected to selinux. My guess is that selinux-policy-target might
have been part of the updates I installed, but like I said,
I wasn't paying attention. (Note that I installed the selinux
RPM(s) by default when I first installed FC, but I've never bothered
to really understand or do anything with them, so don't presume
any coherent administrative behavior on my part.)
Some additional searches pointed me to /sbin/fixfiles, and the idea
that relabelling might be necessary. So I tried booting up on
Knoppix and mounting my filesystems in their usual configuration
relative to each other. I then chroot'ed to the root of my
reconstructed file systems and ran "fixfiles relabel". This seemed
to relabel a bunch of stuff, but it wouldn't relabel anything on
my root partition, claiming that was mounted read-only. (It wasn't
relative to Knoppix, so I think that's an artifact of chroot
behavior.)
Interestingly enough, the /lib/tls/libc.so.6 file mentioned in the
error message never showed up as a file that fixfiles tried to
relabel.
I tried rebooting anyway with the same panic as above.
Since I'm not actually "doing anything" with selinux, I'd be fine
with completely disabling it and/or removing it from my system, but
I can't even figure out how to get to the point of being able to
do that. How can I either work the right magic to label the above
file appropriate and/or get past this panic, or else just disable/remove
selinux so I can get going again?
Thanks,
--SK
18 years, 10 months
CGI scripts stopped working
by Dr. Michael J. Chudobiak
Hi,
My CGI scripts stopped working on Friday, after yum pulled in the latest
updates. This is the error I was getting (in permissive mode):
Jun 13 08:04:27 www kernel: audit(1118664267.858:0): avc: denied {
execute_no_trans } for pid=3483 exe=/usr/sbin/httpd
path=/var/www/html/cgi-local/search_engine/search.pl dev=hda3
ino=7095032 scontext=user_u:system_r:httpd_t
tcontext=user_u:object_r:httpd_sys_content_t tclass=file
However, I fixed the problem by enabling httpd_builtin_scripting using
system-config-securitylevel.
httpd_enable_cgi and httpd_unified are enabled, as before.
Is this the expected behavior? Where is "httpd_builtin_scripting"
documented for the average user? Googling for it brings back a whopping
3 results...
- Mike
18 years, 10 months
acrobat 7 stopped working recently...
by Michael W. Carney
Likely related to recent targeted policy updates...:
Jun 14 10:03:09 lucy-01 kernel: audit(1118768589.854:0): avc: denied
{ execmod } for pid=5660 comm=acroread
path=/opt/Acrobat7.0/Reader/intellinux/plug_ins/AcroForm.api dev=sdb6
ino=65721 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:usr_t tclass=file
Jun 14 10:03:09 lucy-01 kernel: audit(1118768589.868:0): avc: denied
{ execmod } for pid=5660 comm=acroread
path=/opt/Acrobat7.0/Reader/intellinux/SPPlugins/ADMPlugin.apl dev=sdb6
ino=65676 scontext=user_u:system_r:unconfined_t
tcontext=system_u:object_r:usr_t tclass=file
62> ls -Z /opt/Acrobat7.0/Reader/intellinux/plug_ins/AcroForm.api
-rwxr-xr-x root root
system_u:object_r:usr_t /opt/Acrobat7.0/Reader/intellinux/plug_ins/AcroForm.api*
63> ls -Z /opt/Acrobat7.0/Reader/intellinux/SPPlugins/ADMPlugin.apl
-rwxr-xr-x root root
system_u:object_r:usr_t /opt/Acrobat7.0/Reader/intellinux/SPPlugins/ADMPlugin.apl*
64>
I'm running FC3, targeted policy:
47> rpm -q -a 'selinux*'
selinux-policy-strict-1.19.10-2
selinux-doc-1.14.1-1
selinux-policy-targeted-1.17.30-3.2
48>
Could some kind soul clue me into the right incantation to get this working
again? Thanks.
18 years, 10 months
avc: denied { ioctl }?
by Hongwei Li
Hi,
I have a fc3 linux system with targed selinux enforced, kernel
2.6.11-1.14_FC3, target policy 1.17.30-2.96.
After I updated the policy to this version (1.17.30-2.96), from time to time
the system log shows a lot of error messages like this:
Jun 6 17:51:04 morpheus kernel: audit(1118098264.336:0): avc: denied {
ioctl } for pid=17395 exe=/usr/bin/perl path=/proc/loadavg dev=proc
ino=-268435456 scontext=user_u:system_r:httpd_sys_script_t
tcontext=system_u:object_r:proc_t tclass=file
Can somebody help me to figure out what is going on? What should I check and
change to fix the problem?
Thanks!
Hongwei Li
18 years, 10 months
problems after selinux-policy-targeted-1.17.30-3.2 update
by varol kaptan
Hi,
I have a shared library that I create and use within my application.
After the update the thing stopped working. Here is some information:
ls -Z /usr/bin/lua
-rwxr-xr-x root root system_u:object_r:bin_t /usr/bin/lua
ls -Z /home/varol/src/lua/lib/memarray.so
-rwxrwxr-x varol varol user_u:object_r:user_home_t
/home/varol/src/lua/lib/memarray.so
tail -f /var/log/messages
Jun 13 12:03:45 thales kernel: audit(1118660625.243:0): avc: denied
{ execmod } for pid=3021 comm=lua
path=/home/varol/src/lua/lib/memarray.so dev=dm-1 ino=753702
scontext=user_u:system_r:unconfined_t
tcontext=user_u:object_r:user_home_t tclass=file
I had other problems too (acrobat 7) but was able to fix them by going
through the mailing lists.
My question is: How do I fix the above problem, and is there a way to
fix the mess introduced with the latest
selinux-policy-targeted-1.17.30-3.2 update once and for all?
Thanks in advance,
Varol Kaptan
18 years, 10 months
SELinux and RPM verification
by Göran Uddeborg
Some days ago it was explained here that RPM packages do not include
the context information for the files it contains. Rather it sets
context according to the current policy.
Occasionally "rpm --verify" puts a "C" in the list of attribute
checks:
........C c /root/.bash_logout
That bit isn't documented in the manual page for RPM. My assumption
was that it meant that the context differed from what the package
said.
But if the package doesn't say what the context should be, then what
does it mean?
18 years, 10 months
httpd and mysqld
by Andrzej Kąkolewski
Hello
I have this selinux warnings:
audit(1118492920.045:0): avc: denied { search } for pid=3285
exe=/usr/libexec/mysqld name=nscd dev=dm-0 ino=98349
scontext=user_u:system_r:mysqld_t
tcontext=system_u:object_r:nscd_var_run_t tclass=dir
audit(1118492923.767:0): avc: denied { search } for pid=3371
exe=/usr/sbin/httpd name=nscd dev=dm-0 ino=98349
scontext=user_u:system_r:httpd_t
tcontext=system_u:object_r:nscd_var_run_t tclass=dir
I did autorelabel but it didn't help.
What should I do ?
--
Pozdrawiam
Andrzej Kąkolewski
Mail: creasy.bear(a)gmail.com
JID: gnr(a)jabber.atman.pl
18 years, 10 months
home dir issues w/ latest policy
by Bob Kashani
I just upgraded to the latest targeted policy for FC3 and now every file
that I create in my home dir gets user_u context. Is this is a bug?
[medieval@chaucer ~]$ touch tmpfile
[medieval@chaucer ~]$ ls -Z tmpfile
-rw-rw-r-- medieval medieval user_u:object_r:user_home_t tmpfile
[medieval@chaucer ~]$ rpm -q selinux-policy-targeted
selinux-policy-targeted-1.17.30-3.2
[medieval@chaucer ~]$ /usr/sbin/sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 18
Policy from config file:targeted
Policy booleans:
allow_execmem active
allow_execmod active
allow_execstack active
allow_kerberos active
allow_ypbind active
dhcpd_disable_trans inactive
httpd_builtin_scripting inactive
httpd_can_network_connectinactive
httpd_disable_trans inactive
httpd_enable_cgi active
httpd_enable_homedirs active
httpd_ssi_exec active
httpd_tty_comm inactive
httpd_unified active
mysqld_disable_trans inactive
named_disable_trans inactive
named_write_master_zonesinactive
nscd_disable_trans inactive
ntpd_disable_trans inactive
portmap_disable_trans inactive
postgresql_disable_transinactive
snmpd_disable_trans inactive
squid_disable_trans inactive
syslogd_disable_trans inactive
use_nfs_home_dirs inactive
use_samba_home_dirs inactive
use_syslogng inactive
winbind_disable_trans inactive
ypbind_disable_trans inactive
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
18 years, 10 months
httpd denied write
by Tim Fenn
I'm still a bit new to selinux, so apologies if this is a silly
question. I've been running httpd in the past, but I've recently had
errors accessing my mythweb folder (lots of permission denied
messages) with the following logged in /var/log/messages:
Jun 11 19:11:16 agora kernel: audit(1118542276.660:0): avc: denied {
write } for pid=19303 exe=/usr/sbin/httpd name=image_cache dev=sda1
ino=1392658 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=dir
this is from the php scripts in mythweb attempting to write to an
image cache, which is also under the mythweb folder. httpd_unified is
set to 1, so I would have thought any write call by httpd would be
allowed... but I'm obviously missing something simple. Would putting:
allow httpd_t httpd_sys_content_t:dir write;
in my policy be an appropriate solution?
Thanks for any help,
Tim F
18 years, 10 months
