mailman cgi-bin denied search
by Tim Fenn
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
18 years, 7 months
Cron Security Problem
by work＠janburroughs.com
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)
18 years, 7 months
acpid needs to talk to d-bus
by Matthew Saltzman
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
18 years, 7 months
seinfo on default umodified policy.conf reports policy syntax error
by rhp
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
18 years, 7 months
FC4, SELinux, virtual hosts, upload web content
by Valery Khamenya
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
18 years, 7 months
fc4 procmail audit.log entries
by Jeff MacDonald
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
18 years, 7 months
need updated policy for postfix and /etc/aliases.db
by Jeff MacDonald
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
18 years, 7 months
Evolution - /var/spool and OpenOffice launching
by Ted Rule
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/
18 years, 7 months
Evolution: OpenOffice / Firefox integration problems
by Ted Rule
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/
18 years, 7 months
Binary policy modules
by Mike Hearn
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
18 years, 7 months
