Has there been some policy change on F17?
by Tim St. Clair
Folks -
I'm the package maintainer for condor, and we've been trying to update our package and have run into a slew of SELinux issues under fedora 17 that we've never seen before and I was hoping some folks could help illuminate what some of the changes might have been, or if there are is a list of known issues.
There are ~34 errors which spew out now, when previous editions there were 0. I think they all stem from the 1st two though, any insight would be helpful.
-------------------------------------------------------------------------------------------
SELinux is preventing /usr/sbin/condor_master from create access on the directory condor.
***** Plugin catchall (100. confidence) suggests ***************************
If you believe that condor_master should be allowed create access on the condor directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep condor_master /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Additional Information:
Source Context system_u:system_r:condor_master_t:s0
Target Context system_u:object_r:var_lock_t:s0
Target Objects condor [ dir ]
Source condor_master
Source Path /usr/sbin/condor_master
Port <Unknown>
Host tstclair.redhat
Source RPM Packages condor-7.9.1-0.1.fc17.2.x86_64
Target RPM Packages
Policy RPM selinux-policy-3.10.0-142.fc17.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name tstclair.redhat
Platform Linux tstclair.redhat 3.5.0-2.fc17.x86_64 #1 SMP
Mon Jul 30 14:48:59 UTC 2012 x86_64 x86_64
Alert Count 1
First Seen Fri 10 Aug 2012 12:24:56 PM CDT
Last Seen Fri 10 Aug 2012 12:24:56 PM CDT
Local ID 4551e46a-0828-4bb3-8c03-bd6dfe62ce8f
Raw Audit Messages
type=AVC msg=audit(1344619496.816:576): avc: denied { create } for pid=8190 comm="condor_master" name="condor" scontext=system_u:system_r:condor_master_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir
type=SYSCALL msg=audit(1344619496.816:576): arch=x86_64 syscall=mkdir success=yes exit=0 a0=1a7b200 a1=1ff a2=ffffffffffffffff a3=7fffbd04d6b0 items=0 ppid=1 pid=8190 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=condor_master exe=/usr/sbin/condor_master subj=system_u:system_r:condor_master_t:s0 key=(null)
Hash: condor_master,condor_master_t,var_lock_t,dir,create
audit2allow
#============= condor_master_t ==============
allow condor_master_t var_lock_t:dir create;
audit2allow -R
#============= condor_master_t ==============
allow condor_master_t var_lock_t:dir create;
-------------------------------------------------------------------------------------------
Everything under that folder is created as condor:condor and the condor_master is running as condor, so I'm curious what the issue is?
Cheers,
Tim
11 years, 8 months
Allowing access to session dbus from sandbox
by Robin Green
I would like to allow chromium within a sandbox to access KWallet
running in KDE outside the sandbox, so that
(a) my website passwords cannot be directly read from within a sandbox
- access must be mediated by KWallet, which can prompt me for my
KWallet password to confirm. So if I am prompted by KWallet while on a
web page without a saved password, I will know something is amiss.
(b) my website passwords are shared between sandboxes
I say chromium because Firefox does not use an external wallet service.
I've got part-way there. Here is what I've done so far:
I found out that KWallet uses dbus to communicate (specifically, the
session bus, because it's a desktop daemon). Because the dbus session
bus is by default a unix socket in /tmp, which would be hidden by
seunshare, I created /etc/dbus-1/session-local.conf as follows:
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<listen>unix:tmpdir=/dev/shm</listen>
</busconfig>
and logged out and logged back in again in order to restart the session bus.
I then passed the dbus socket name into the sandbox at creation time using
env DBUS_SESSION_BUS_ADDRESS=unix:abstract=/dev/shm/dbus-wyOMqiEGrR,guid=8e741d603eb65ed7bf138cac00060be0
xterm
as the command for sandbox to run.
To run chromium I used
chromium-browser --no-sandbox --password-store=kwallet
A couple of iterations of audit2allow and semodule -i later, I had
this policy module installed:
allow sandbox_web_client_t unconfined_dbusd_t:unix_stream_socket connectto;
allow sandbox_web_client_t config_usr_t:dir read;
allow sandbox_web_client_t unconfined_t:unix_stream_socket connectto;
but chromium is still outputting to the terminal this when it tries to
communicate with KWallet:
** (exe:9107): WARNING **:
GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An SELinux policy
prevents this sender from sending this message to this recipient, 0
matched rules; type="method_call", sender="(null)" (inactive)
interface="org.freedesktop.DBus" member="Hello" error name="(unset)"
requested_reply="0" destination="org.freedesktop.DBus" (bus)
I can't find relevant entries in /var/log/audit.log at first glance,
so maybe these are checks done by the dbus daemon itself, rather than
the kernel.
11 years, 8 months
Some more (probably) Zarafa-related
by Matej Cepl
Hi,
I have found that I have my server (running RHEL 6 with plenty of EPEL
stuff, most interesting here is probably Zarafa) is still in the
permissive mode. Before switching to enforcing again I run ausearch -m
AVC -ts this-week and got the attached list of AVC denials. I am not
sure what about these, but before I blindly file bugs into bugzilla (or
blindly switch on various booleans), I thought to ask about advice here.
[root@luther selinux-research]# audit2allow <avc-this-week.txt \
|grep -v '^#'|grep -v '^\s*$'
allow httpd_t postfix_public_t:dir search;
allow httpd_t postfix_public_t:fifo_file { write getattr open };
allow httpd_t postfix_spool_maildrop_t:dir { write remove_name search
add_name };
allow httpd_t postfix_spool_maildrop_t:file { rename write getattr
setattr read create open };
allow httpd_t postfix_spool_t:dir search;
# is httpd_can_sendmail --> off really to blame? Or there is some weird
# interaction between Zarafa webmail and postfix?
allow httpd_t self:process setrlimit;
# this just happened once, and I don't feel well about switching the
httpd_setrlimit boolean on without knowing why it is required.
My booleans related to http:
[root@luther selinux-research]# getsebool -a|grep http
allow_httpd_anon_write --> off
allow_httpd_mod_auth_ntlm_winbind --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_check_spam --> off
httpd_can_network_connect --> off
httpd_can_network_connect_cobbler --> off
httpd_can_network_connect_db --> off
httpd_can_network_memcache --> off
httpd_can_network_relay --> off
httpd_can_sendmail --> off
httpd_dbus_avahi --> on
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> off
httpd_execmem --> off
httpd_manage_ipa --> off
httpd_read_user_content --> off
httpd_setrlimit --> off
httpd_ssi_exec --> off
httpd_tmp_exec --> off
httpd_tty_comm --> on
httpd_unified --> on
httpd_use_cifs --> off
httpd_use_gpg --> off
httpd_use_nfs --> off
httpd_use_openstack --> off
[root@luther selinux-research]#
Thanks for any advice,
Matěj
11 years, 8 months
Imposing contexts on sshfs
by Dalvik Khertel
Hello everyone,
I'm trying to figure out a way to get sshfs to play nicely with an SELinux enabled current Fedora host (current, in this context, means Fedora 17 at the time of writing).
Let's assume I have an external file server that I would like to connect to through sshfs, in order to provide access to email and sql data.
So I would naively do something like:
su - imapsshuser -C 'sshfs storagehost:/srv/imap /srv/imap'
su - sqlsshuser -C 'sshfs storagehost:/srv/sql /srv/sql'
in order to mount the directories I will use for my local email and sql services respectively.
The problem now is that neither the `sshfs` nor the similar `mount.fuse` calls properly accept any '-o context='-like options nor does sshfs (nor the underlying openssh sftp and maybe even fuse in general) support extended attributes that are used for managing SELinux contexts.
This means for starters that I cannot directly reuse any extended attributes that may or may not lie around on the file server and that I cannot even force a mount-wide SELinux context onto the respective trees.
The same seems to hold for tricks like
chcon -t dovecot_t /srv/imap
or
mount -o remount,context="system_u:object_r:dovecot_t:s0" /srv/imap
or
mount -o bind,context="system_u:object_r:dovecot_t:s0" /srv/imap /mnt/imap
Instead, both mount points remain to be mounted under the generic sshfs_t type (or, in other flavors of Linux distributions, fusefs_t).
In short, I haven't been able to figure out any way to give two distinct sshfs mount points two separate SELinux contexts that will allow me to use Fedora's default SELinux policy.
I've spent quite some time on google and various forums to find variations of my problem that might give me a clue on how to proceed, but rather unsuccessfully so far (for instance, apparently someone tried to push a patch to openssh that would allow extended attributes to pass through sftp about a year ago, but hasn't succeeded in getting it upstream yet due to developer resistance).
So, does anyone see a possibility for me to give different sshfs mount points separate SELinux contexts?
Is there, maybe, a way for me to modify the SELinux configuration in order to replace the sshfs_t default type based on the mount point path? (if possible, I'd rather not grant additional SELinux access rights to system accounts that are going to run the daemons I'm trying to use)
Thanks in advance for your advice!
11 years, 8 months
sealert and FC17
by mark
Dan,
I read your post at <http://danwalsh.livejournal.com/26053.html>, but
what I still don't understand is this: on a user's system (actually, my
manager's). What I need, and not just for his system, is a way to do
what setroubleshoot *used* to do: give me a sealert in a logfile so I
can run it from a command line.
mark, pro-command line
11 years, 8 months
Re: sealert and FC17
by Frank Murphy
On 03/08/12 16:50, m.roth(a)5-cent.us wrote:
>> Are you trying to find avc's in the audit.log?
>> sudo ausearch -m avc
>
> Nothing. All my avc's seem to be in messages, and I'm not getting what I
> used to get, the line with "run sealert ..." to move it to something
> comprehensible. With the examples, above, I don't know what the ID is,
> either.
>
> mark
>
>
Is the audit service running?
systemctl status auditd.service
If is disabled try:
systemctl enable auditd.service
systemctl start auditd.service
--
Regards,
Frank
"Jack of all, fubars"
11 years, 8 months
Bug or feature, absent authorized_hosts
by Vadym Chepkov
Hi,
Not sure if it's a bug or a "feature"
RHEL6.3
selinux-policy-targeted-3.7.19-155.el6_3.noarch
was getting bunch of these:
----
time->Tue Jul 31 11:22:21 2012
type=SYSCALL msg=audit(1343733741.446:154): arch=c000003e syscall=2 success=no exit=-13 a0=7f740329e7d0 a1=800 a2=1 a3=24 items=0 ppid=946 pid=1291 auid=4294967295 uid=0 gid=0 euid=1001 suid=0 fsuid=1001 egid=513 sgid=0 fsgid=513 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1343733741.446:154): avc: denied { read } for pid=1291 comm="sshd" name="authorized_keys" dev=xvdb ino=3368578 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=file
authorized_keys file didn't even exist for root user, it is not allowed to login remotely.
Silenced it down by creating empty authorized_keys file with ssh_home_t context.
Cheers,
Vadym
11 years, 8 months
Proprietary telnet daemon fails login when SELinux is enabled
by Dave Stoner
I apologise in advance for asking questions which I feel I should have
been able to answer from sources on the internet. If you could possibly
give me some pointers on where to look it would be so much appreciated.
My system is centos 6.2 -
Linux MyHostName 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22
GMT 2011 x86_64 x86_64 x86_64 GNU/Linux
SELinux mode is set 'enforced'.
I have a proprietary telnet daemon which upon a telnet to port 52000, is
started OK when SELinux is disabled. But when it is enabled the same
telnet results in /var/log/audit/audit.log showing:
type=USER_LOGIN msg=audit(1343048458.345:69): user pid=2536 uid=0
auid=799 ses=7 subj=system_u:system_r:inetd_t:s0-s0:c0.c1023
msg='op=login id=799 exe="/bin/login" hostname=0.0.0.0 addr=0.0.0.0
termi
nal=pts/2 res=success'
A normal telnet gives a message similar to above, my telnet adds the
following:
type=AVC msg=audit(1343048458.353:70): avc: denied { entrypoint } for
pid=2543 comm="login" path="/bin/bash" dev=sda2 ino=135083
scontext=unconfined_u:system_r:qmail_tcp_env_t:s0-s0:c0.c1023 tconte
xt=system_u:object_r:shell_exec_t:s0 tclass=file
I believe I can create a policy to overcome this using audit2allow, i.e.
it comes up with:
module mypola 1.0;
require {
type qmail_tcp_env_t;
type shell_exec_t;
class file entrypoint;
}
#============= qmail_tcp_env_t ==============
allow qmail_tcp_env_t shell_exec_t:file entrypoint;
But it seems to me what I ought to be doing is somehow to get my daemon
to run with a domain of 'remote_logon_t' as is used by the standard
telnet daemon, as here:
type=USER_LOGIN msg=audit(1343058924.928:212): user pid=3759 uid=0
auid=799 ses=29 subj=system_u:system_r:remote_login_t:s0-s0:c0.c1023
msg='op=login id=799 exe="/bin/login" hostname=localhost addr=::
1 terminal=pts/2 res=success'
This is unfamiliar territory and any hints or pointers would really be
appreciated.
Dave.
Dave Stoner
Principal Systems Architect
Northgate Reality
Direct: +44 (0)1442 272071 - VPN: 872 2071
www.northgate-is.com/reality <http://www.northgate-is.com/reality>
-----------------------------------------------------------------------------------------
This email is sent on behalf of Northgate Information Solutions Limited and its associated companies ("Northgate") and is strictly confidential and intended solely for the addressee(s).
If you are not the intended recipient of this email you must: (i) not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully; (ii) contact Northgate immediately on +44 (0)1442 232424 quoting the name of the sender and the addressee then delete it from your system.
Northgate has taken reasonable precautions to ensure that no viruses are contained in this email, but does not accept any responsibility once this email has been transmitted. You should scan attachments (if any) for viruses.
Northgate Information Solutions Limited. Registered in England no. 06442582 - Northgate Information Solutions UK Limited. Registered in England no. 968498 - NorthgateArinso UK Limited .Registered in England no. 1587537 - Moorepay Limited. Registered in England no. 891686 - First Business Support Limited. Registered in England no. 3056267 - Registered Office: Peoplebuilding 2, Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire HP2 4NW
Northgate Managed Services Limited (NI). Registered in Northern Ireland no. NI032979 - LearnServe Limited (NI). Registered in Northern Ireland no. NI043825
Registered Office: Hillview House, 61 Church Road, Newtownabbey, Co. Antrim, BT36 7LQ
-----------------------------------------------------------------------------------------
11 years, 8 months
