selinux October 2005

selinux@lists.fedoraproject.org

52 participants
53 discussions

mailman cgi-bin denied search
by Tim Fenn 20 Oct '05

20 Oct '05

I recently installed mailman on my FC3 box (using the redhat based RPMs), and it seems to be working just fine, except for the numerous avc messages it cranks out whenever I run one of the cgi scripts associated with mailman (e.g. via the web interface): Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied { search } for pid=18761 comm="listinfo" name="run" dev=sda1 ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ u:object_r:var_run_t tclass=dir I have selinux-policy-targeted-1.17.30-3.16, and # getsebool httpd_enable_cgi httpd_enable_cgi --> active # getsebool httpd_enable_homedirs httpd_enable_homedirs --> active # getsebool httpd_ssi_exec httpd_ssi_exec --> active # getsebool httpd_builtin_scripting httpd_builtin_scripting --> active # getsebool httpd_unified httpd_unified --> active set, is there something I'm missing? Thanks for any help, Tim

2 4

Cron Security Problem
by work＠janburroughs.com 19 Oct '05

19 Oct '05

Does anyone know how to resolve this cron error? Oct 18 06:41:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/popmail) Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/loadmysql) Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/pop-perl) Oct 18 07:01:02 la1 crond[16105]: (root) CMD (run-parts /etc/cron.hourly)

2 1

acpid needs to talk to d-bus
by Matthew Saltzman 18 Oct '05

18 Oct '05

The latest Network Manager does some useful things across a suspend/resume cycle, but it relies on a dbus-send signal from the /etc/acpi/actions/sleep script. My script fails to deliver that signal when invoked from acpid in enforcing mode, but it works fine from the command line or in permissive mode. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs

2 5

seinfo on default umodified policy.conf reports policy syntax error
by rhp 18 Oct '05

18 Oct '05

14-oct-05 Hello: Problem Summary: Two FC3 systems running permissive-targeted with identical error messages. targeted source rpm: selinux-policy-targeted-sources-1.17.30-3.16 'seinfo' run on umodified policy.conf reports syntax error in policy. 'sestatus' shows policy version 19 but policy files are policy.18 'checkpolicy' errors out on failure to open policy.conf Details: I have just started to work with SELinux, on my two Fedora Core 3, i686 systems. I am getting identical errors on both systems that I hope can be easily explained: During initial installation of FC3, I installed the targeted-binary policy and have been running in the default permissive-targeted mode. Recently I downloaded and installed the policy-targeted-source, policy-strict-source, and policy-strict rpm packages via yum so that I could begin to learn more about SELinux policy configuration. Here are the system identifications: 65 ellipse:~> uname -a Linux ellipse 2.6.12-1.1378_FC3.stk16 #1 Thu Sep 22 13:41:41 EDT 2005 i686 i686 i386 GNU/Linux 41 torus:~> uname -a Linux torus 2.6.13 #1 Mon Sep 5 16:37:24 ICT 2005 i686 i686 i386 GNU/Linux Here is a listing of the installed selinux packages on both systems: selinux-policy-targeted-sources-1.17.30-3.16 selinux-policy-strict-1.19.10-2 libselinux-1.19.1-8 selinux-policy-targeted-1.17.30-3.16 libselinux-devel-1.19.1-8 selinux-policy-strict-sources-1.19.10-2 selinux-doc-1.14.1-1 setools-1.4.1-5 setools-gui-1.4.1-5 checkpolicy-1.17.5-1.2 The following error/status conditions are identical on both systems: When running a test of seinfo against the default installation on both systems I get this error message: 'seinfo /etc/selinux/targeted/src/policy/policy.conf' error in the statement ending on line 3675 (token 'typeattribute'): syntax errorerror(s) encountered while parsing configuration (first pass, line: 3675) error reading policy A partial listing of policy.conf showing the putative syntax error location: 3666 3667 type unconfined_t, domain, privuser, privhome, privrole, privowner, admi 3667 n, auth_write, fs_domain, privmem; 3668 role system_r types unconfined_t; 3669 role user_r types unconfined_t; 3669 role user_r types unconfined_t; 3671 3672 #line 11 3673 3674 #line 11 -->> 3675 typeattribute unconfined_t unrestricted; 3676 #line 11 3677 I find it hard to believe that the default, umodified policy.conf would be released with syntax errors. Running seinfo against the binary policy returns: 66 ellipse:~> seinfo /etc/selinux/targeted/policy/policy.18 Statistics for policy file: /etc/selinux/targeted/policy/policy.18 Policy Version: v.18 Policy Type: binary Classes: 55 Permissions: 205 Types: 343 Attributes: 0 Users: 3 Roles: 4 Booleans: 30 Cond. Expr.: 32 Allow: 17620 Neverallow: 0 Auditallow: 3 Dontaudit: 1204 Type_trans: 201 Type_change: 0 Role allow: 5 Role trans: 0 Initial SIDs: 0 Note the policy version is 18. Running sestatus, on both systems I get this: SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 19 Policy from config file:targeted ... Note the Policy Version is listed as 19. However, checking the policy file extents I see they are policy.18: ls /etc/selinux/targeted/policy/ policy.18 ls /etc/selinux/strict/policy/ policy.18 However, checking the contents of the /etc/selinux/targeted/src/policy/VERSION and /etc/selinux/strict/src/policy/VERSION files I get 1.17 & 1.19 respectively. Additionally, a check of the contents of /selinux/policyvers returns '19'. Running 'checkpolicy', 'checkpolicy -c 18', & 'checkpolicy -d -c 18' all fail with this error message: checkpolicy: loading policy configuration from policy.conf checkpolicy: unable to open policy.conf running checkpolicy with '-c 19' returns an 'out of range' error message Uninstalling the 'selinux-policy-strict' and 'selinux-policy-strict-sources' rpms on one of the systems removes the /etc/selinux/strict tree from that system but does not change the policy version showed by sestatus, nor the error messages from seinfo and checkpolicy. Any help will be appreciated. Brgds Bob -- rhp.lpt(a)gmail.com

2 4

FC4, SELinux, virtual hosts, upload web content
by Valery Khamenya 18 Oct '05

18 Oct '05

Dear Daniel and all, I am trying to enable upload for all my virtual hosts placed in /var/www . The goal is to allow users upload their content via ftp/sftp/scp . First I tried vsftpd as a basis for upload, but got problem: httpd_sys_content_t is needed by apache and user_home_t is needed by chrooted vsftpd access. Togeter httpd_sys_content_t and user_home_t probably might be combined by editing SELinux targeted polices, but i'd better deny to do it myself. Then I tried scp. The similar problem appeared. Q: What is the Right Way to organize upload of web content to the virtual hosts with enabled SELinux? here I imply that ideology of FC4 and SELinux targeted policy should probably allow private user to host few virtual hosts with upload function, but without diving in jungle of policy develoment :-) Any good links and hints are highly appreciated! P.S. Please Cc to me, and sorry if missed something in maillist. -- Valery A.Khamenya

5 9

fc4 procmail audit.log entries
by Jeff MacDonald 18 Oct '05

18 Oct '05

Greetings, I'm running procmail and spamassassin on a fully patched FC4 box. I have the following procmail related entries in audit.log: type=AVC msg=audit(1129564863.023:3868): avc: denied { search } for pid=5450 comm="procmail" name="tmp" dev=dm-0 ino=262145 scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=SYSCALL msg=audit(1129564863.023:3868): arch=40000003 syscall=196 success=no exit=-2 a0=93f8eb0 a1=bfc64dac a2=8b7ff4 a3=93f8ec1 items=1 pid=5450 auid=4294967295 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 comm="procmail" exe="/usr/bin/procmail" type=CWD msg=audit(1129564863.023:3868): cwd="/home/jam" type=PATH msg=audit(1129564863.023:3868): item=0 name="/tmp/_KVB +8q8UDB.eros.zoidtechnolo" flags=310 type=AVC msg=audit(1129564863.023:3869): avc: denied { write } for pid=5450 comm="procmail" name="tmp" dev=dm-0 ino=262145 scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=AVC msg=audit(1129564863.023:3869): avc: denied { add_name } for pid=5450 comm="procmail" name="_KVB+8q8UDB.eros.zoidtechnolo" scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=SYSCALL msg=audit(1129564863.023:3869): arch=40000003 syscall=5 success=yes exit=5 a0=93f8eb0 a1=80c1 a2=124 a3=80c1 items=1 pid=5450 auid=4294967295 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 comm="procmail" exe="/usr/bin/procmail" Regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2

1 0

need updated policy for postfix and /etc/aliases.db
by Jeff MacDonald 17 Oct '05

17 Oct '05

Greetings! I have the following in audit.log: type=AVC msg=audit(1129476522.717:3618): avc: denied { lock } for pid=20074 comm="smtpd" name="aliases.db" dev=dm-0 ino=3015628 scontext=root:system_r:postfix_smtpd_t tcontext=root:object_r:etc_t tclass=file type=SYSCALL msg=audit(1129476522.717:3618): arch=40000003 syscall=143 success=yes exit=0 a0=c a1=1 a2=809a4cc a3=1 items=0 pid=20074 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="smtpd" exe="/usr/libexec/postfix/smtpd" type=AVC_PATH msg=audit(1129476522.717:3618): path="/etc/aliases.db" Looks like there needs to be a policy update. Regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2

2 4

Evolution - /var/spool and OpenOffice launching
by Ted Rule 17 Oct '05

17 Oct '05

I have a couple of problems with Evolution/OpenOffice running on FC4/strict with policy: selinux-policy-strict-sources-1.27.1-2.3 The first, relatively simple, issue is that the user_evolution_t policy doesn't seem to have provision for reading /var/spool/mail. I have sendmail setup to forward root mail to my local non-root account, and then Evolution setup to read the ensuing Unix mail spool locally in addition to my remote IMAP/POP3 accounts. The extra var_spool_t and mail_spool_t policy listed below seems to do the trick, though obviously a more complete solution would require proper "macro-ising" to take account of staff_evolution_t and so on. As far as I can tell, there isn't a boolean switch to allow for this. The second, slightly more intractable problem is that of OpenOffice/Evolution integration. I have the allow_execmem boolean enabled to allow for a plain launch of OpenOffice, but I find that an additional execmem policy - see below - is needed to allow for the launch of OO from within Evolution's "attachment view dialog" as it now has its own user_evolution_t domain which seems to ignore the allow_execmem boolean. The execmem policy is still not sufficient to allow me to launch OO from Evolution. I've added some extra policy to cope with denial messages that I've seen for this socket file /tmp/OSL_PIPE_500_SingleOfficeIPC_2df8e6ac565346ee4ccc8ac992ddaa83 which OO creates, but this is still not enough to make OO fire up. The socket created by OO appears to get left behind once OO has finished, which makes me suspect that part of the problem is that the socket has a different file_context when created from user_t as opposed to user_evolution_t. With my current patched policy, I get no further SELinux denial messages, so debugging the problem has become trickier. Presumably there is a dontaudit policy somewhere suppressing the error message I'm interested in, but I haven't tracked it down yet. Any suggestions, folks? Current patches to strict policy: ================================================================= cat /etc/selinux/strict/src/policy/domains/program/localpolicy.te # Miscellaneous Local SELinux policy not # covered by other .te configuration ... ############################################################## # Patch to allow Evolution to read home mail spools # Seemingly still required as not included in default policy allow user_evolution_t var_spool_t:dir { search }; allow user_evolution_t mail_spool_t:dir { read getattr search }; allow user_evolution_t mail_spool_t:file { read getattr write }; ... ############################################################# # Patch to allow Evolution to launch OpenOffice.... allow user_evolution_t self:process { execmem }; auditallow user_evolution_t self:process { execmem }; ############################################################# # Patch to allow OpenOffice to write to a temporary socket.... allow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; auditallow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; ... # Patches to allow OpenOffice to write to a temporary socket....from Evolution allow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write unlink }; auditallow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write unlink }; -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/

2 2

Evolution: OpenOffice / Firefox integration problems
by Ted Rule 17 Oct '05

17 Oct '05

I've noted before that Evolution has some some problems launching OpenOffice with SELinux enforcement in place. After some further experimentation with different policy settings, and also different sequences of opening and closing OpenOffice from GNOME and/or Evolution, some more findings. I've also found a similar issue relating to Firefox launching from Evolution. As mentioned before, I still need various extra permissions on /var/spool so as to be able to read Unix mail spools from Evolution: allow user_evolution_t var_spool_t:dir { search }; allow user_evolution_t mail_spool_t:dir { read getattr search }; allow user_evolution_t mail_spool_t:file { read getattr write }; I still need an extra execmem permission so as to be able to launch OpenOffice from Evolution's user_evolution_t domain: allow user_evolution_t self:process { execmem }; So as to avoid extra permissions on the user_t domain, I add a transition to the user_evolution_t domain for the Unix socket in /tmp/OSL_PIPE_500_SingleOfficeIPC_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx type_transition user_evolution_t tmp_t:sock_file user_tmp_t; The transition ensures that OpenOffice in user_t and from user_evolution_t create the socket in the same user_tmp_t domain. We add extra permissions so as to allow OpenOffice opened from Evolution, (Evo/OO), to write/delete/create the socket: allow user_evolution_t { user_tmp_t }:sock_file { getattr write unlink create }; We add an "optional" permission for OpenOffice opened from GNOME, ( raw/OO ), to be able to connect to the socket created by Evo/OO. allow user_t user_evolution_t:unix_stream_socket { connectto }; For completeness, it should be noted that the policy ALREADY contains the following permission: allow user_evolution_t user_t:unix_stream_socket { connectto }; i.e. "connect backwards". Without ALL of the extra permissions in the user_evolution_t domain, Evo/OO fails to launch. It is apparent from the logs that it does fire up, but once it spots the "broken" socket permissions, it shuts down again. With the combination of these extra permission in place, we find the following behaviour. If I launch Evo/OO with no copy of raw/OO already running, the Evo/OO process runs in the user_evolution_t domain. It first of all tries to write to the socket - which still exists in /tmp courtesy of the last invocation of raw/OO not 'cleaning up'. Probably because of catching an EPIPE or similar signal, it finds no-one listening on the socket, and proceeds to unlink/create a fresh socket. Just for luck, it then writes to it. If I then launch raw/OO with the Evo/OO already running, a new user_t swriter.bin process launches. Once running, it then appears to write to the existing user_evolution_t socket. As best I can judge, it then "pumps" the raw/OO document through the socket, whereupon it is visible in a 2nd Window running under the Evo/OO instance. Once the "pumping" has finished, the raw/OO process closes. This leaves the raw/OO document open inside the Evo/OO process. This leads to a significant problem. The 'raw/OO' document is now marked as "read-only", because if you've opened a user_home_t file, Evolution has no write permissions to the original file. The user "experience" is thus confused by a window which was apparently opened with sufficient permissions to edit the file being swapped for a window which has no such permissions. Conversely, if I launch Evo/OO with raw/OO already running, Evo/OO "connects back" to raw/OO via the existing socket and pumps the Evo/OO attachment into the raw/OO user_t process. At which point, of course, the Evo/OO user_evolution_t process closes, leaving the attachment open inside a process with "elevated" user_t permissions. If this permission: allow user_t user_evolution_t:unix_stream_socket { connectto }; is removed from the mix, then when launching raw/OO after Evo/OO is already open, it finds that it can't connect to the current socket and the document opens in a user_t window/process, with the original attachment open in a user_evolution_t window/process. If raw/OO is closed before Evo/OO, raw/OO still has sufficient permissions on the socket to confuse the Evo/OO instance, and Evo/OO fails to shut down cleanly, requiring a "Force Quit" dialog box. Having seen all of this behaviour, a number of potential corrective measures occur to me, some of which are OpenOffice rewrites, and some of which are SELinux policy changes. 1. If OpenOffice were recoded to gracefully allow for a situation where it had no rights to open/write/delete the Unix domain socket, the Evo/OO process/window could launch without error, and display the attachment with user_evolution_t permissions. This would allow two processes - one in user_t and one in user_evolution_t to run side by side, and would avoid the need for any extra user_evolution_t permissions diluting the strength of the policy. 2. OpenOffice should probably be corrected to remove the socket upon shutdown rather than rely on system reboot or tmpwatch to do the job. 3. From what I can see, I assume that the socket name is constructed from my Unix login id, and hence is unique to each login on the system. If OO were more SELinux aware it would construct the name based on login.SELinux-domain so that multiple attachment windows could share a user_evolution_t process, whilst a different socket allowed different documents to share a user_t process. This would probably be more difficult to code than 1. 4. The attachment is temporarily saved in ~/.evolution/cache/tmp/xxxxxx, and hence is created in the user_evolution_home_t domain. When Evo/OO launches, it would appear to have write permissions to the temporary copy. This feels wrong to me. Surely the "attachment viewer" process should only have read permissions on the original attachment. Sadly, this seems to require the creation of some sort of user_evolution_viewer_t domain for Evo/OO to run inside. A positive side-effect of this would be that the domain's networking permissions could be cut back as compared to user_evolution_t; a viewer domain would surely never need rights to speak IMAP/POP3 for instance. 5. The user_evolution_t domain appears to already have this set of permissions into the user_t domain: allow user_evolution_t user_t:unix_stream_socket connectto; allow user_evolution_t user_t:unix_stream_socket { read write }; The corresponding permissions in the other direction: allow user_t user_evolution_t:unix_stream_socket connectto; allow user_t user_evolution_t:unix_stream_socket { read write }; don't exist in the default policy. The former seems to be a side-effect of the ice_connect macros used by gnome_application macro. I can see there are some FIXMEs scattered in the ice_macros policy, so I presume a more specific ice domain fix is in hand. Having surmised what was happening with OpenOffice inside Evolution, I've had a look at what happens with Firefox opening a URL from Evolution, and Evince opening a PDF attachment from Evolution. With Evince, the operation is much cleaner. A separate user_evolution_t Evince process is launched irrespective of whether a user_t Evince process already exists. There is still the issue of the original attachment being read/write to the user_evolution_t Evince process, of course. With Firefox, a new window is created if a user_mozilla_t Firefox process already exists, but "of course", the window is shared with the single user_mozilla_t firefox.bin process. If no Firefox process already exists, the Evolution silently fails to open the URL. The policy appears to already allow for Evolution to launch Firefox courtesy of the mail_client_domain macro, so this appears to be an actual bug in the policy somewhere. FWIW, the firefox scripts detect whether another process exists, and launch "mozilla-xremote-client" instead if it does and firefox-bin if it doesn't. Following the trail of error messages that I can find, it seems that the failure relates to an inability to find various shared libraries, which in turn points to a missing LD_LIBRARY_PATH. By symlinking various mozilla libraries into /usr/lib, I can work round most of the errors, but this is not a proper fix. /usr/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory Searching for the launch path for firefox, we find that /usr/bin/firefox is a script which launches other scripts and binaries in /usr/lib/firefox and /usr/lib/mozilla... The gotcha which caught my eye was that the script /usr/bin/mozilla has a mozilla_exec_t label, whilst /usr/bin/firefox is labelled bin_t. Eventually /usr/bin/firefox calls /usr/lib/firefox-1.0.7/firefox-bin which is marked mozilla_exec_t. I therefore reasoned that the LD_LIBRARY_PATH setting was lost in the domain transition from /usr/bin/firefox running in user_evolution_t to /usr/lib/firefox-1.0.7/firefox-bin running in user_mozilla_t. By relabelling /usr/bin/firefox as mozilla_exec_t, I can now launch firefox from Evolution under all circumstances. This means that the PATH setup in /usr/bin/firefox is preserved as no domain transition takes place when invoking firefox-bin - it occurs when Evolution calls /usr/bin/firefox instead. This may not be the best fix, but given that the /usr/bin/mozilla script has a mozilla_exec_t label, it seems reasonable to me. -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/

1 0

Binary policy modules
by Mike Hearn 14 Oct '05

14 Oct '05

Hi, Can we have an update on this please - last I heard it was targetted for FC5. Is this still on the cards? If so, are there any docs on how to use it? I'm waiting for this feature so I can integrate autopackage with SELinux (for instance by preventing packages loading kernel modules and other risky things whilst still letting them run as root). thanks -mike

3 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux October 2005