selinux February 2007

selinux@lists.fedoraproject.org

21 participants
23 discussions

audit message on shutdown
by Davide Bolcioni 04 Feb '07

04 Feb '07

Greetings, I have been seeing an elusive message on shutdown, along the lines of audit(...) user uid=0 auid=4294967295 subj=system_u:system_r:hwclock_t:s0 msg='changing system time ... res=success)' and apparently harmless, since the clock is running ok on subsequent boot (but I am using NTP). Is it safe to ignore this or should I dig deeper ? Thank you for your consideration, Davide Bolcioni -- There is no place like /home.

2 1

making a user create files as "user_u:system_r:httpd_t"
by Hugo Martin Campos V. 01 Feb '07

01 Feb '07

Hello list, I am analyzing a HTTPd server working with SELinux in permissive mode before I enforce it. The problem I've seen so far begins when the .html .php files get uploaded by the person in charge and they are labeled as "system_u:object_r:default_t" and the label needs to be "user_u:system_r:httpd_t" The resulting error: avc: denied { getattr } for pid=8244 comm="httpd" name="/" dev=hda5 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir I added that folder to be labeled as "user_u:system_r:httpd_t" in "/etc/selinux/targeted/src/policy/file_contexts/file_contexts" to relabel it with "fixfiles restore" (and it works) but it's not practical to relabel everything everytime that user uploads a webpage. What should I do?? My knowledge goes as far as labeling, do I need to set roles? or should I follow audit2allow advice for now. It would just be cool to autolabel every file uploaded by that user as "user_u:system_r:httpd_t" Thanks, Hugo Martin --------------------------------- Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). Probalo ya!

3 3

Java problems on FC6/strict
by Ted Rule 01 Feb '07

01 Feb '07

To begin at the beginning... I was trying to configure my FC6 machine so that I could run the OpenOffice SVG Import Filter here: http://www.ipd.uka.de/~hauma/svg-import/ I also wanted to be able to run Java as a plugin to Firefox-2.0.0.1. FFX2 runs Ok on FC6 - it just needs a few minor SELinux workrounds. The big problem with the SVG Import Filter is that it requires Java 1.5, so I've always assumed that the GNU Java 1.4.2 compatible RPMs won't support some of the more esoteric Java API functions. Hence the perceived need to install the latest Sun Java RPMs. I previously had both Sun-Java/Firefox and OpenOffice/SVG-Import working Ok on FC4 - again with a few minor policy patches. So I duly installed Sun's jre-1.5.0_10 RPM, and for good measure I manually adjusted the /etc/alternatives/java settings to make /usr/bin/java point to Sun. I also "execstack -l"'ed all the Sun Libraries so as to reduce the propensity for it to need exectack/execmem/execmod permissions. With all this in place, I ran up OpenOffice, going to Tools -> Options -> Java in an attempt to select Sun Java as the prefered JVM. Needless to say, avc's galore showed up in /var/log/messages. After quite a while trying to tweak SELinux policy to suit, I gave up the fight and decided that my next best option was to simply tweak file labels and policy so that Java was executed in user_t rather than user_javaplugin_t. I therefore gave bin/java bin/java_vm and bin/javaws in Sun-jre a "java_notrans_exec_t" label, and added can_exec(user_t, java_notrans_exec_t) The last hurdle was that Sun JRE is full of execstack/execmem/execmod problems - still - so I had to enable the global allow_execmem boolean - only. With all of this in place, and with NO relabel of the GNU Java binaries on the same box or any other policy changes to user_t permissions, I was finally able to see Sun Java as a valid JVM from inside OpenOffice. However, I noted that GNU Java was still throwing up lots of avc's when I opened OpenOffice -> Tools -> Options -> Java As an example of the avc's generated by staff_javaplugin_t trying to open GNU Java from OpenOffice, I have this log snippet: [root@topaz log]# grep gij messages| grep 14:26:47 | grep -v granted Feb 1 14:26:47 topaz kernel: audit(1170340007.573:4914): avc: denied { write } for pid=6774 comm="gij" name="[32609]" dev=pipefs ino=32609 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4915): avc: denied { write } for pid=6774 comm="gij" name="[32610]" dev=pipefs ino=32610 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4916): avc: denied { read } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4917): avc: denied { write } for pid=6774 comm="gij" name="[32525]" dev=pipefs ino=32525 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4918): avc: denied { read } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4919): avc: denied { write } for pid=6774 comm="gij" name="[32528]" dev=pipefs ino=32528 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4920): avc: denied { read } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4921): avc: denied { write } for pid=6774 comm="gij" name="[32529]" dev=pipefs ino=32529 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:staff_r:staff_t:s0 tclass=fifo_file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4922): avc: denied { read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6 ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4923): avc: denied { read } for pid=6774 comm="gij" name="ofa680en-US.res" dev=hda6 ino=1760866 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4924): avc: denied { read } for pid=6774 comm="gij" name="ooo680en-US.res" dev=hda6 ino=1760867 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4925): avc: denied { read } for pid=6774 comm="gij" name="sfx680en-US.res" dev=hda6 ino=1760876 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4926): avc: denied { read } for pid=6774 comm="gij" name="vcl680en-US.res" dev=hda6 ino=1760888 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4927): avc: denied { read } for pid=6774 comm="gij" name="sw680en-US.res" dev=hda6 ino=1760881 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4928): avc: denied { read } for pid=6774 comm="gij" name="svx680en-US.res" dev=hda6 ino=1760880 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4929): avc: denied { read } for pid=6774 comm="gij" name="svt680en-US.res" dev=hda6 ino=1760879 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.574:4930): avc: denied { read write } for pid=6774 comm="gij" name="svdb.tmp" dev=hda5 ino=219746 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=staff_u:object_r:staff_tmp_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4952): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.826:4953): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4954): avc: denied { getattr } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.827:4955): avc: denied { read } for pid=6774 comm="gij" name="JREProperties.class" dev=hda6 ino=1729341 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file Feb 1 14:26:47 topaz kernel: audit(1170340007.847:4960): avc: denied { execute } for pid=6783 comm="gij" name="addr2line" dev=hda6 ino=359825 scontext=staff_u:staff_r:staff_javaplugin_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file [root@topaz log]# Running up Sun Java inside Firefox I came across a similar set of problems, and was similarly forced to run Sun java in user_mozilla_t instead of user_javaplugin_t to get it to work. I haven't bothered to try and run GNU Java inside Firefox, as yet. As with user_t, I had to grant user_mozilla_t execmem permissions because of the broken Sun binaries. The Java "test page" I was using in Firefox is here, FWIW: http://www.java.com/en/download/help/testvm.xml Meanwhile, for historical background: Looking back at the FC4 policy, I seems that Java run from user_t has no corresponding javaplugin_domain() definition in base_user_macros.te and hence would always have run in user_t. Meanwhile, on FC4, Java run from user_mozilla_t would run in user_mozilla_javaplugin_t. By contrast, FC6 seems to run java in user_javaplugin_t irrespective of whether one starts from user_t or user_mozilla_t; this just seems a bit odd to me. To ease the problems associated with running Java from OpenOffice, could I therefore request that an extra boolean be added to policy, namely "disable_java_trans", which defaults OFF, and can be enabled to achieve the same effect as my manual relabel for both user_t and user_mozilla_t domains. I would also like to try and disable the execmem boolean, but obviously that requires a recompile of the entire Sun RPM from scratch. Does anyone on this list know who we might approach at Sun so as to get them to rebuild their JVM with a newer/cleaner compiler toolkit? As with previous postings, I'm currently running selinux-policy-strict-2.4.6-27 -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux February 2007