Re: SELinux blocking Samba share mounting?
by Paul Howarth
Steven Stromer wrote:
>> What's the output of:
>>
>> # audit2allow < /var/log/audit/audit.log
>>
>> Paul.
>>
>
>
> Paul,
>
> Thanks for the time! I understand what you are saying. I have set:
>
> chcon -R -h -t home_root_t /home
>
> so that the entire path's heirarchy will be consistent,
No no, this is wrong. home_root_t is for directories that *contain* home
directories, not the home directories and their contents themselves.
I'd do a "restorecon -RF /home" to fix that, then put back the contexts
on your share areas as you wanted them (e.g. samba_share_t or
public_content_rw_t etc.).
Better still, I'd move your shares from under /home to under /srv if
that's a possibility.
> and then:
>
> setsebool -P use_samba_home_dirs 1
>
> Tried connecting, but still unsuccessful, so, output of audit2allow <
> /var/log/audit/audit.log is:
>
> #============= smbd_t ==============
> allow smbd_t home_root_t:dir { search getattr };
> allow smbd_t httpd_sys_content_t:dir search;
>
>
> Trying to mount /home/server1/PHFiles generates in
> /var/log/audit/audit.log:
>
> type=AVC msg=audit(1234540788.851:16207): avc: denied { search } for
> pid=26783 comm="smbd" name="/" dev=dm-2 ino=2
> scontext=root:system_r:smbd_t:s0
> tcontext=system_u:object_r:home_root_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234540788.851:16207): arch=c000003e syscall=4
> success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0 a2=7fff19c3c6a0 a3=3
> items=0 ppid=17598 pid=26783 auid=0 uid=500 gid=0 euid=500 suid=0
> fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=122 comm="smbd"
> exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null)
Contexts need repairing before looking at these again.
> Trying to mount /var/www/html generates in /var/log/audit/audit.log:
>
> type=AVC msg=audit(1234540890.725:16214): avc: denied { search } for
> pid=26785 comm="smbd" name="www" dev=dm-3 ino=6815745
> scontext=root:system_r:smbd_t:s0
> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234540890.725:16214): arch=c000003e syscall=4
> success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0 a2=7fff19c3c6a0 a3=3
> items=0 ppid=17598 pid=26785 auid=0 uid=500 gid=0 euid=500 suid=0
> fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=122 comm="smbd"
> exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null)
/var/www is supposed to be readable under httpd only, not samba, so it's
normal for these not to work. For both servers to be able to access the
files (and samba to write them), you'll need /var/www and everything
underneath it to be public_content_rw_t and to set the boolean
allow_smbd_anon_write. If you need CGI scripts rather than just static
content and built-in scripting (e.g. PHP) then you'll need a local
policy module to allow samba access using the existing httpd_* types
instead.
Paul.
15 years, 2 months
polgengui
by Konrad Azzopardi
I have policycoreutils-2.0.57-18.fc10 and the macro init_script_file()
is incorrectly named init_script_type()
tnx
konrad
15 years, 2 months
Re: SELinux blocking Samba share mounting?
by Paul Howarth
On Fri, 13 Feb 2009 16:45:41 -0500
Steven Stromer <filter(a)stevenstromer.com> wrote:
>
> >> Paul,
> >> Thanks for the time! I understand what you are saying. I have set:
> >> chcon -R -h -t home_root_t /home
> >> so that the entire path's heirarchy will be consistent,
> >
> > No no, this is wrong. home_root_t is for directories that
> > *contain* home directories, not the home directories and their
> > contents themselves.
> >
> > I'd do a "restorecon -RF /home" to fix that, then put back the
> > contexts on your share areas as you wanted them (e.g.
> > samba_share_t or public_content_rw_t etc.).
>
> Executed:
> restorecon -RF /home
> chcon -R -h -t samba_share_t /home/server1/PHFiles/
>
> > Better still, I'd move your shares from under /home to under /srv
> > if that's a possibility.
>
> Due to partitioning and backup schema, this would not be an ideal
> solution, if avoidable.
>
> > > and then:
> > setsebool -P use_samba_home_dirs 1
>
> Done.
Whoops, I got the wrong boolean. The one you want is
samba_enable_home_dirs, not use_samba_home_dirs. The former allows
samba to serve out home dirs, the latter allows use of home dirs
mounted from a samba server.
> >> Tried connecting, but still unsuccessful, so, output of
> >> audit2allow < /var/log/audit/audit.log is:
> >> #============= smbd_t ==============
> >> allow smbd_t home_root_t:dir { search getattr };
> >> allow smbd_t httpd_sys_content_t:dir search;
> >> Trying to mount /home/server1/PHFiles generates in /var/log/audit/
> >> audit.log:
> >> type=AVC msg=audit(1234540788.851:16207): avc: denied
> >> { search } for pid=26783 comm="smbd" name="/" dev=dm-2 ino=2
> >> scontext=root:system_r:smbd_t:s0
> >> tcontext=system_u:object_r:home_root_t:s0 tclass=dir
> >> type=SYSCALL msg=audit(1234540788.851:16207): arch=c000003e
> >> syscall=4 success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0
> >> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=26783 auid=0 uid=500
> >> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500
> >> tty=(none) ses=122 comm="smbd" exe="/usr/sbin/smbd"
> >> subj=root:system_r:smbd_t:s0 key=(null)
> >
> > Contexts need repairing before looking at these again.
>
> New output of audit2allow < /var/log/audit/audit.log is:
>
> #============= smbd_t ==============
> allow smbd_t default_t:dir search;
> allow smbd_t home_root_t:dir { search getattr };
> allow smbd_t httpd_sys_content_t:dir search;
>
>
> New /var/log/audit/audit.log output is:
>
> type=AVC msg=audit(1234559350.144:16265): avc: denied { search }
> for pid=30226 comm="smbd" name="/" dev=dm-2 ino=2
> scontext=root:system_r:smbd_t:s0
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234559350.144:16265): arch=c000003e
> syscall=4 success=no exit=-13 a0=2b119e17f7d0 a1=7fff19c3c6a0
> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=30226 auid=0 uid=500
> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
> ses=122 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0
> key=(null) type=AVC msg=audit(1234559350.276:16266): avc: denied
> { search } for pid=30229 comm="smbd" name="/" dev=dm-2 ino=2
> scontext=root:system_r:smbd_t:s0
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> type=SYSCALL msg=audit(1234559350.276:16266): arch=c000003e
> syscall=4 success=no exit=-13 a0=2b119e17f7d0 a1=7fff19c3c6a0
> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=30229 auid=0 uid=500
> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none)
> ses=122 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0
> key=(null)
The root directory of one of the filesystems mounted on your system is
labelled default_t it would seem. See if you can find it and do a
non-recursive restorecon on it.
Also try to find the audit log entry associated with the
httpd_sys_content_t AVC.
> >> Trying to mount /var/www/html generates
> >> in /var/log/audit/audit.log: type=AVC
> >> msg=audit(1234540890.725:16214): avc: denied { search } for
> >> pid=26785 comm="smbd" name="www" dev=dm-3 ino=6815745
> >> scontext=root:system_r:smbd_t:s0
> >> tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir
> >> type=SYSCALL msg=audit(1234540890.725:16214): arch=c000003e
> >> syscall=4 success=no exit=-13 a0=2b119e168ff0 a1=7fff19c3c6a0
> >> a2=7fff19c3c6a0 a3=3 items=0 ppid=17598 pid=26785 auid=0 uid=500
> >> gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500
> >> tty=(none) ses=122 comm="smbd" exe="/usr/sbin/smbd"
> >> subj=root:system_r:smbd_t:s0 key=(null)
> >
> > /var/www is supposed to be readable under httpd only, not samba,
> > so it's normal for these not to work. For both servers to be able
> > to access the files (and samba to write them), you'll need /var/www
> > and everything underneath it to be public_content_rw_t and to set
> > the boolean allow_smbd_anon_write.
>
>
> Success here! Thought I'd tried this previously without success
> (shrug...) However, this time the following worked a charm! Thank
> you for your patience!
>
> chcon -R -h -t public_content_rw_t /var/www
> setsebool -P allow_smbd_anon_write=1
>
> Maybe I had accidentally executed the following without realizing:
> chcon -R -h -t public_content_rw_t /var/www/html
>
> (By way of explanation, this host acts as a web site development
> environment, and having samba access to the web files makes some
> tasks, such as searching and replacing text in multiple files,
> faster and easier for some developers than via sftp or the command
> line.)
>
>
> > If you need CGI scripts rather than just static content and
> > built-in scripting (e.g. PHP) then you'll need a local policy
> > module to allow samba access using the existing httpd_* types
> > instead.
>
> Thanks. I'm aware to set .cgi, .pl, .sh and similar to
> httpd_sys_script_exec_t.
Once you've done that you'll no longer be able to access those files
using samba of course...
Paul.
>
15 years, 2 months
Strange Mailman/Sendmail Audit messages in Fedora-10?
by Derek Atkins
Hey,
I'm working on getting a new Fedora-10 server up and running. I've
set up mailman and have lists configured. Mail even seems to be
flowing, but for some reason I'm getting a strange audit message on
each incoming message. I find it interesting that there are three
unix_socket AVCs and I have three milters connected to sendmail.
The settroubleshoot viewer gives me the following information.
I'm hoping someone could help me understand these log messages,
and maybe help me make them go away?
Thanks,
-derek
Summary
SELinux is preventing mailman (mailman_mail_t) "read write" sendmail_t.
Detailed Description
SELinux denied access requested by mailman. It is not expected that this access is required by mailman and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.
Allowing Access
You can generate a local policy module to allow this access - see FAQ
Or you can disable SELinux protection altogether. Disabling SELinux
protection is not recommended. Please file a bug report against this
package.
Additional Information
Source Context: system_u:system_r:mailman_mail_t:s0
Target Context: system_u:system_r:sendmail_t:s0
Target Objects: socket [ unix_stream_socket ]
Source: mailman
Source Path: /usr/lib/mailman/mail/mailman
Port: <Unknown>
Host: <redacted>
Source RPM Packages: mailman-2.1.11-3.fc10
Target RPM Packages:
Policy RPM: selinux-policy-3.5.13-41.fc10
Selinux Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing
Plugin Name: catchall
Host Name: code.gnucash.org
Platform: Linux code.gnucash.org 2.6.27.12-170.2.5.fc10.i686 #1 SMP Wed Jan 21 02:09:37 EST 2009 i686 athlon
Alert Count: 1
First Seen: Sun 08 Feb 2009 11:28:40 AM EST
Last Seen: Sun 08 Feb 2009 03:04:01 PM EST
Local ID: 606e93dc-55fc-4454-acfa-1081a87deb63
Line Numbers:
Raw Audit Messages :
node=code.gnucash.org type=AVC msg=audit(1234123441.829:421): avc:
denied { read write } for pid=17455 comm="mailman"
path="socket:[105075]" dev=sockfs ino=105075
scontext=system_u:system_r:mailman_mail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket
node=code.gnucash.org type=AVC msg=audit(1234123441.829:421): avc:
denied { read write } for pid=17455 comm="mailman"
path="socket:[105077]" dev=sockfs ino=105077
scontext=system_u:system_r:mailman_mail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket
node=code.gnucash.org type=AVC msg=audit(1234123441.829:421): avc:
denied { read write } for pid=17455 comm="mailman"
path="socket:[105079]" dev=sockfs ino=105079
scontext=system_u:system_r:mailman_mail_t:s0
tcontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket
node=code.gnucash.org type=SYSCALL msg=audit(1234123441.829:421):
arch=40000003 syscall=11 success=yes exit=0 a0=8d42e38 a1=8d42f20
a2=8d42508 a3=0 items=0 ppid=17454 pid=17455 auid=4294967295 uid=8
gid=12 euid=8 suid=8 fsuid=8 egid=41 sgid=41 fsgid=41 tty=(none)
ses=4294967295 comm="mailman" exe="/usr/lib/mailman/mail/mailman"
subj=system_u:system_r:mailman_mail_t:s0 key=(null)
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord(a)MIT.EDU PGP key available
15 years, 2 months
Re: SELinux blocking Samba share mounting?
by Steven Stromer
On Feb 12, 2009, at 4:43 PM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Paul Howarth wrote:
>> On Thu, 12 Feb 2009 14:20:34 -0500
>> Steven Stromer <filter(a)stevenstromer.com> wrote:
>>
>>> Hopefully posting to the right list!
>>>
>>> I'm starting to migrate a few Fedora boxes over to the latest
>>> version
>>> of CentOS 5 running the latest version of samba:
>>>
>>> [~]# smbstatus
>>> Samba version 3.0.28-1.el5_2.1
>>>
>>>
>>> However, I am having a hard time getting SELinux to permit the
>>> mounting of shares on the first CentOS box. Disabling SELinux
>>> permits
>>> the shares to mount without problem:
>>>
>>> [~]# setenforce 1
>>> [~]# mount -t cifs //192.168.10.3/PHFiles /mnt/samba -o
>>> username=****,password=****,rw retrying with upper case share name
>>> mount error 6 = No such device or address
>>> [~]# setenforce 0
>>> [~]# mount -t cifs //192.168.10.3/PHFiles /mnt/samba -o
>>> username=****,password=****,rw [~]# ls -la /mnt/samba/
>>> total 8
>>> d---rws---+ 6 samba samba 0 Feb 10 11:17 .
>>> drwxr-xr-x 3 root root 4096 Feb 12 11:13 ..
>>> d---rws---+ 2 technology technology 0 Feb 10 11:14 Computing
>>> d---rws---+ 2 development development 0 Feb 10 11:17 Development
>>> d---rws---+ 2 root public 0 Feb 10 11:16 Marketing &
>>> Design d---rws---+ 2 root public 0 Feb 10 11:14
>>> Public
>>> Computing [~]# umount /mnt/samba/
>>> [~]# setenforce 1
>>>
>>>
>>> Installed policy version is:
>>> selinux-policy.noarch 2.4.6-137.1.el5
>>> selinux-policy-targeted.noarch 2.4.6-137.1.el5
>>>
>>>
>>> The two shared directories are:
>>>
>>> [~]# ls -laZ /home/server1/PHFiles/
>>> d---rws---+ samba samba
>>> system_u:object_r:samba_share_t .
>>> drwxr-xr-x root root root:object_r:user_home_dir_t
>>> .. d---rws---+ technology technology root:object_r:samba_share_t
>>> Computing d---rws---+ development development
>>> root:object_r:samba_share_t Development d---rws---+ root
>>> public root:object_r:samba_share_t Marketing &
>>> Design d---rws---+ root public
>>> root:object_r:samba_share_t Public Computing
>>>
>>> and
>>>
>>> [~]# ls -laZ /var/www/html
>>> d---rwsr-x+ development development
>>> system_u:object_r:public_content_rw_t . drwxr-xr-x root root
>>> system_u:object_r:httpd_sys_content_t .. ----rwxr-x+
>>> development development root:object_r:public_content_rw_t .DS_Store
>>> d---rwsr-x+ development development
>>> root:object_r:public_content_rw_t
>>> private d---rwsr-x+ development development
>>> root:object_r:public_content_rw_t public
>>>
>>> (I am aware that my permissions seem a bit untraditional. I am
>>> running an experiment with extended ACL configuration on samba
>>> shares. However, I do not believe this to have any bearing on my
>>> present problems, as I have numerous other production servers
>>> running
>>> with these permissions under SELinux, and, again, turning SELinux
>>> off
>>> resolves my problems instantly.)
>>>
>>>
>>> The following has been executed with no apparent effect:
>>> setsebool -P allow_smbd_anon_write=1
>>>
>>>
>>> The following have been executed with no apparent effect (so these
>>> have been turned back off): setsebool -P smbd_disable_trans=1
>>> setsebool -P nmbd_disable_trans=1
>>>
>>>
>>> I've added the new contexts to file_contexts, and executed
>>> 'restorecon -R' to the two shared
>>> directories: /home/server1/PHFiles(/.*)? --
>>> system_u:object_r:samba_share_t /var/www/html(/.*)? --
>>> system_u:object_r:public_content_rw_t
>>>
>>>
>>> setroubleshoot-server is installed, but no AVC denials are reported
>>> to /var/log/messages. Instead, when SELinux is enforcing, I get the
>>> error: smbd[11852]: '/home/server1/PHFiles' does not exist or
>>> permission denied when connecting to [PHFiles] Error was Permission
>>> denied
>>>
>>>
>>> And, finally, I've rebooted. All to no avail. Any assistance would
>>> be
>>> much appreciated!
>>
>> If the audit daemon is running, the AVC denials will be
>> in /var/log/audit/audit.log rather than /var/log/messages.
>>
>> fedora-selinux-list would probably be more appropriate for this by
>> the
>> way.
>>
>> Paul.
>>
>>
>> --
>> This message was distributed to subscribers of the selinux mailing
>> list.
>> If you no longer wish to subscribe, send mail to majordomo(a)tycho.nsa.gov
>> with
>> the words "unsubscribe selinux" without quotes as the message.
>
> setsebool -P use_samba_home_dirs 1
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkmUl/YACgkQrlYvE4MpobMOOgCeMPI1VZu86N93qfBY5bxfhk71
> o/4AnjypHIr5wCY3L6S6INi/w8LHSXuK
> =PIJ/
> -----END PGP SIGNATURE-----
>
Daniel, thanks for the reply. No success. I omitted mentioning that I
had tried this, as well. However, I just confirmed again that this is
not the fix. I'm not even sure why home directories would need to be
permitted, as I am not using them. I even have [homes] commented out
in smb.conf, which I'll include for reference:
# Samba config file
[global]
# WINS
wins support = yes
local master = yes
os level = 99
domain master = yes
preferred master = yes
workgroup = 478FIRST
# NETBIOS/DNS
netbios name = server1
name resolve order = wins lmhosts hosts bcast
dns proxy = yes
# SMB/CIFS
smb ports = 139
server string = server1
# AUTHENTICATION
interfaces = eth0
security = user
passdb backend = tdbsam
encrypt passwords = yes
# LOGGING
log file = /var/log/samba/%m.log
max log size = 50
# CUPS
load printers = yes
cups options = raw
#[homes]
# comment = Home Directories
# read only = No
# browseable = No
# [printers]
# comment = All Printers
# path = /usr/spool/samba
# printable = Yes
# browseable = No
[PHFiles]
path = /home/server1/PHFiles
writable = yes
browseable = yes
available = yes
create mask = 0660
force create mode = 0660
directory mask = 0770
force directory mode = 0770
inherit acls = yes
inherit owner = yes
hosts allow = 127. 192.168.5.
map archive = no
map readonly = no
map acl inherit = yes
[html]
path = /var/www/html
writable = yes
browseable = yes
available = yes
create mask = 0660
force create mode = 0660
directory mask = 0770
force directory mode = 0770
inherit acls = yes
inherit owner = yes
hosts allow = 127. 192.168.5.
map archive = no
map readonly = no
map acl inherit = yes
15 years, 2 months
new flood of avc's
by Antonio Olivares
Dear fellow Selinux experts,
Now setroubleshoot(er) is working fine and I see a great flood of avc's, some are repeating offenders :( ***.kde*** one especially :(
Summary:
SELinux prevented kde4-config from writing .kde.
Detailed Description:
SELinux prevented kde4-config from writing .kde. If .kde is a core file, you may
want to allow this. If .kde is not a core file, this could signal a intrusion
attempt.
Allowing Access:
Changing the "allow_daemons_dump_core" boolean to true will allow this access:
"setsebool -P allow_daemons_dump_core=1."
Fix Command:
setsebool -P allow_daemons_dump_core=1
Additional Information:
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh
Target Context system_u:object_r:root_t
Target Objects .kde [ dir ]
Source kde4-config
Source Path /usr/bin/kde4-config
Port <Unknown>
Host localhost.localdomain
Source RPM Packages kdelibs-4.2.0-10.fc11
Target RPM Packages
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name allow_daemons_dump_core
Host Name localhost.localdomain
Platform Linux localhost.localdomain
2.6.29-0.110.rc4.git3.fc11.i586 #1 SMP Wed Feb 11
16:25:38 EST 2009 i686 i686
Alert Count 1
First Seen Thu 12 Feb 2009 08:38:30 AM CST
Last Seen Thu 12 Feb 2009 08:38:30 AM CST
Local ID d108c183-459e-4b03-a811-e45ea3323dad
Line Numbers
Raw Audit Messages
node=localhost.localdomain type=AVC msg=audit(1234449510.598:8): avc: denied { create } for pid=2607 comm="kde4-config" name=".kde" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir
node=localhost.localdomain type=SYSCALL msg=audit(1234449510.598:8): arch=40000003 syscall=39 success=no exit=-13 a0=8794358 a1=1c0 a2=749e38c a3=1 items=0 ppid=2606 pid=2607 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kde4-config" exe="/usr/bin/kde4-config" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Summary:
SELinux is preventing the gdm-session-wor from using potentially mislabeled
files (.xsession-errors).
Detailed Description:
SELinux has denied gdm-session-wor access to potentially mislabeled file(s)
(.xsession-errors). This means that SELinux will not allow gdm-session-wor to
use these files. It is common for users to edit files in their home directory or
tmp directories and then move (mv) them to system directories. The problem is
that the files end up with the wrong file context which confined applications
are not allowed to access.
Allowing Access:
If you want gdm-session-wor to access this files, you need to relabel them using
restorecon -v '.xsession-errors'. You might want to relabel the entire directory
using restorecon -R -v ''.
Additional Information:
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh
Target Context system_u:object_r:xauth_home_t
Target Objects .xsession-errors [ file ]
Source gdm-session-wor
Source Path /usr/libexec/gdm-session-worker
Port <Unknown>
Host localhost.localdomain
Source RPM Packages gdm-2.25.2-3.fc11
Target RPM Packages
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name home_tmp_bad_labels
Host Name localhost.localdomain
Platform Linux localhost.localdomain
2.6.29-0.110.rc4.git3.fc11.i586 #1 SMP Wed Feb 11
16:25:38 EST 2009 i686 i686
Alert Count 1
First Seen Thu 12 Feb 2009 08:38:37 AM CST
Last Seen Thu 12 Feb 2009 08:38:37 AM CST
Local ID c26924ad-8d28-4294-b100-a403fb00932b
Line Numbers
Raw Audit Messages
node=localhost.localdomain type=AVC msg=audit(1234449517.666:18): avc: denied { read write } for pid=2665 comm="gdm-session-wor" name=".xsession-errors" dev=dm-0 ino=426067 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xauth_home_t:s0 tclass=file
node=localhost.localdomain type=SYSCALL msg=audit(1234449517.666:18): arch=40000003 syscall=33 success=no exit=-13 a0=82088a8 a1=6 a2=c4225c a3=ad69bc items=0 ppid=2660 pid=2665 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Summary:
SELinux is preventing the gdm-session-wor from using potentially mislabeled
files (.dmrc).
Detailed Description:
SELinux has denied gdm-session-wor access to potentially mislabeled file(s)
(.dmrc). This means that SELinux will not allow gdm-session-wor to use these
files. It is common for users to edit files in their home directory or tmp
directories and then move (mv) them to system directories. The problem is that
the files end up with the wrong file context which confined applications are not
allowed to access.
Allowing Access:
If you want gdm-session-wor to access this files, you need to relabel them using
restorecon -v '.dmrc'. You might want to relabel the entire directory using
restorecon -R -v ''.
Additional Information:
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh
Target Context system_u:object_r:xauth_home_t
Target Objects .dmrc [ file ]
Source gdm-session-wor
Source Path /usr/libexec/gdm-session-worker
Port <Unknown>
Host localhost.localdomain
Source RPM Packages gdm-2.25.2-3.fc11
Target RPM Packages
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name home_tmp_bad_labels
Host Name localhost.localdomain
Platform Linux localhost.localdomain
2.6.29-0.110.rc4.git3.fc11.i586 #1 SMP Wed Feb 11
16:25:38 EST 2009 i686 i686
Alert Count 2
First Seen Thu 12 Feb 2009 08:38:37 AM CST
Last Seen Thu 12 Feb 2009 08:38:37 AM CST
Local ID 33f693b3-35dc-4b77-be00-95cf19cefdc8
Line Numbers
Raw Audit Messages
node=localhost.localdomain type=AVC msg=audit(1234449517.325:11): avc: denied { read } for pid=2660 comm="gdm-session-wor" name=".dmrc" dev=dm-0 ino=426068 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xauth_home_t:s0 tclass=file
node=localhost.localdomain type=SYSCALL msg=audit(1234449517.325:11): arch=40000003 syscall=5 success=no exit=-13 a0=81a9868 a1=8000 a2=0 a3=8000 items=0 ppid=2626 pid=2660 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=4294967295 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Summary:
SELinux is preventing 0logwatch (logwatch_t) "read" to /root (user_home_dir_t).
Detailed Description:
SELinux denied access requested by 0logwatch. /root may be a mislabeled. /root
default SELinux type is admin_home_t, but its current type is user_home_dir_t.
Changing this file back to the default type, may fix your problem.
File contexts can be assigned to a file in the following ways.
* Files created in a directory receive the file context of the parent
directory by default.
* The SELinux policy might override the default label inherited from the
parent directory by specifying a process running in context A which creates
a file in a directory labeled B will instead create the file with label C.
An example of this would be the dhcp client running with the dhclient_t type
and creates a file in the directory /etc. This file would normally receive
the etc_t type due to parental inheritance but instead the file is labeled
with the net_conf_t type because the SELinux policy specifies this.
* Users can change the file context on a file using tools such as chcon, or
restorecon.
This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.
However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.
If you believe this is a bug, please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Allowing Access:
You can restore the default system context to this file by executing the
restorecon command. restorecon '/root', if this file is a directory, you can
recursively restore using restorecon -R '/root'.
Fix Command:
restorecon '/root'
Additional Information:
Source Context system_u:system_r:logwatch_t:SystemLow-SystemHigh
Target Context system_u:object_r:user_home_dir_t
Target Objects /root [ dir ]
Source 0logwatch
Source Path /usr/bin/perl
Port <Unknown>
Host localhost.localdomain
Source RPM Packages perl-5.10.0-56.fc11
Target RPM Packages filesystem-2.4.19-1.fc10
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name restorecon
Host Name localhost.localdomain
Platform Linux localhost.localdomain
2.6.29-0.110.rc4.git3.fc11.i586 #1 SMP Wed Feb 11
16:25:38 EST 2009 i686 i686
Alert Count 1
First Seen Thu 12 Feb 2009 09:15:02 AM CST
Last Seen Thu 12 Feb 2009 09:15:02 AM CST
Local ID f4899a3b-7541-45fa-826e-a0b28973be00
Line Numbers
Raw Audit Messages
node=localhost.localdomain type=AVC msg=audit(1234451702.307:33): avc: denied { read } for pid=3199 comm="0logwatch" path="/root" dev=dm-0 ino=32769 scontext=system_u:system_r:logwatch_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
node=localhost.localdomain type=SYSCALL msg=audit(1234451702.307:33): arch=40000003 syscall=11 success=yes exit=0 a0=9174c20 a1=91744f8 a2=91728a8 a3=91744f8 items=0 ppid=3195 pid=3199 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=2 comm="0logwatch" exe="/usr/bin/perl" subj=system_u:system_r:logwatch_t:s0-s0:c0.c1023 key=(null)
Summary:
SELinux is preventing sendmail (system_mail_t) "read" to /root
(user_home_dir_t).
Detailed Description:
SELinux denied access requested by sendmail. /root may be a mislabeled. /root
default SELinux type is admin_home_t, but its current type is user_home_dir_t.
Changing this file back to the default type, may fix your problem.
File contexts can be assigned to a file in the following ways.
* Files created in a directory receive the file context of the parent
directory by default.
* The SELinux policy might override the default label inherited from the
parent directory by specifying a process running in context A which creates
a file in a directory labeled B will instead create the file with label C.
An example of this would be the dhcp client running with the dhclient_t type
and creates a file in the directory /etc. This file would normally receive
the etc_t type due to parental inheritance but instead the file is labeled
with the net_conf_t type because the SELinux policy specifies this.
* Users can change the file context on a file using tools such as chcon, or
restorecon.
This file could have been mislabeled either by user error, or if an normally
confined application was run under the wrong domain.
However, this might also indicate a bug in SELinux because the file should not
have been labeled with this type.
If you believe this is a bug, please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.
Allowing Access:
You can restore the default system context to this file by executing the
restorecon command. restorecon '/root', if this file is a directory, you can
recursively restore using restorecon -R '/root'.
Fix Command:
restorecon '/root'
Additional Information:
Source Context system_u:system_r:system_mail_t:SystemLow-
SystemHigh
Target Context system_u:object_r:user_home_dir_t
Target Objects /root [ dir ]
Source sendmail
Source Path /usr/sbin/sendmail.sendmail
Port <Unknown>
Host localhost.localdomain
Source RPM Packages sendmail-8.14.3-4.fc11
Target RPM Packages filesystem-2.4.19-1.fc10
Policy RPM selinux-policy-3.6.5-3.fc11
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Enforcing
Plugin Name restorecon
Host Name localhost.localdomain
Platform Linux localhost.localdomain
2.6.29-0.110.rc4.git3.fc11.i586 #1 SMP Wed Feb 11
16:25:38 EST 2009 i686 i686
Alert Count 1
First Seen Thu 12 Feb 2009 09:30:33 AM CST
Last Seen Thu 12 Feb 2009 09:30:33 AM CST
Local ID 748a8584-58e2-4487-afba-48a6e2951d7d
Line Numbers
Raw Audit Messages
node=localhost.localdomain type=AVC msg=audit(1234452633.639:34): avc: denied { read } for pid=11298 comm="sendmail" path="/root" dev=dm-0 ino=32769 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir
node=localhost.localdomain type=SYSCALL msg=audit(1234452633.639:34): arch=40000003 syscall=11 success=yes exit=0 a0=804d6f0 a1=bfb3981c a2=82320a0 a3=4 items=0 ppid=3162 pid=11298 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=2 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0-s0:c0.c1023 key=(null)
I will be patient here, but the .kde one, I don't understand what is wrong, is it with KDe or with selinux. I keep seeing it over and over. It goes away and then it comes back :(
Thanks,
Antonio
15 years, 2 months
RE: SELinux blocking Samba share mounting?
by Steven Stromer
To add to my last post...
Just learned that AVC denials will be sent to /var/log/audit/audit.log rather than /var/log/messages. Here's what I'm getting:
type=AVC msg=audit(1234474415.612:15330): avc: denied { search } for pid=14702 comm="smbd" name="/" dev=dm-2 ino=2 scontext=root:system_r:smbd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1234474415.612:15330): arch=c000003e syscall=4 success=no exit=-13 a0=2b9f623cbeb0 a1=7fff581e3850 a2=7fff581e3850 a3=3 items=0 ppid=11661 pid=14702 auid=0 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=105 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null)
type=AVC msg=audit(1234474415.621:15331): avc: denied { search } for pid=14704 comm="smbd" name="/" dev=dm-2 ino=2 scontext=root:system_r:smbd_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1234474415.621:15331): arch=c000003e syscall=4 success=no exit=-13 a0=2b9f623cbeb0 a1=7fff581e3850 a2=7fff581e3850 a3=3 items=0 ppid=11661 pid=14704 auid=0 uid=500 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=105 comm="smbd" exe="/usr/sbin/smbd" subj=root:system_r:smbd_t:s0 key=(null)
15 years, 2 months
SELinux blocking Samba share mounting?
by Steven Stromer
Hi,
I'm starting to migrate a few Fedora boxes over to the latest version of CentOS 5 running the latest version of samba:
[~]# smbstatus
Samba version 3.0.28-1.el5_2.1
However, I am having a hard time getting SELinux to permit the mounting of shares on the first CentOS box. Disabling SELinux permits the shares to mount without problem:
[~]# setenforce 1
[~]# mount -t cifs //192.168.10.3/PHFiles /mnt/samba -o username=****,password=****,rw
retrying with upper case share name
mount error 6 = No such device or address
[~]# setenforce 0
[~]# mount -t cifs //192.168.10.3/PHFiles /mnt/samba -o username=****,password=****,rw
[~]# ls -la /mnt/samba/
total 8
d---rws---+ 6 samba samba 0 Feb 10 11:17 .
drwxr-xr-x 3 root root 4096 Feb 12 11:13 ..
d---rws---+ 2 technology technology 0 Feb 10 11:14 Computing
d---rws---+ 2 development development 0 Feb 10 11:17 Development
d---rws---+ 2 root public 0 Feb 10 11:16 Marketing & Design
d---rws---+ 2 root public 0 Feb 10 11:14 Public Computing
[~]# umount /mnt/samba/
[~]# setenforce 1
Installed policy version is:
selinux-policy.noarch 2.4.6-137.1.el5
selinux-policy-targeted.noarch 2.4.6-137.1.el5
The two shared directories are:
[~]# ls -laZ /home/server1/PHFiles/
d---rws---+ samba samba system_u:object_r:samba_share_t .
drwxr-xr-x root root root:object_r:user_home_dir_t ..
d---rws---+ technology technology root:object_r:samba_share_t Computing
d---rws---+ development development root:object_r:samba_share_t Development
d---rws---+ root public root:object_r:samba_share_t Marketing & Design
d---rws---+ root public root:object_r:samba_share_t Public Computing
and
[~]# ls -laZ /var/www/html
d---rwsr-x+ development development system_u:object_r:public_content_rw_t .
drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ..
----rwxr-x+ development development root:object_r:public_content_rw_t .DS_Store
d---rwsr-x+ development development root:object_r:public_content_rw_t private
d---rwsr-x+ development development root:object_r:public_content_rw_t public
(I am aware that my permissions seem a bit untraditional. I am running an experiment with extended ACL configuration on samba shares. However, I do not believe this to have any bearing on my present problems, as I have numerous other production servers running with these permissions under SELinux, and, again, turning SELinux off resolves my problems instantly.)
The following has been executed with no apparent effect:
setsebool -P allow_smbd_anon_write=1
The following have been executed with no apparent effect (so these have been turned back off):
setsebool -P smbd_disable_trans=1
setsebool -P nmbd_disable_trans=1
I've added the new contexts to file_contexts, and executed 'restorecon -R' to the two shared directories:
/home/server1/PHFiles(/.*)? -- system_u:object_r:samba_share_t
/var/www/html(/.*)? -- system_u:object_r:public_content_rw_t
setroubleshoot-server is installed, but no AVC denials are reported to /var/log/messages. Instead, when SELinux is enforcing, I get the error:
smbd[11852]: '/home/server1/PHFiles' does not exist or permission denied when connecting to [PHFiles] Error was Permission denied
And, finally, I've rebooted. All to no avail. Any assistance would be much appreciated!
15 years, 2 months
Re: selinux issue
by John Oliver
On Tue, Feb 10, 2009 at 02:58:38PM -0500, Daniel J Walsh wrote:
>
> # grep execstack /var/log/audit/audit.log | audit2allow -M myexecstack
> # semodule -i myexecstack.pp
[root@localhost ~]# semodule -i valicert.pp
tomcat homedir /usr/share/tomcat5 or its parent directory conflicts with
a
defined context in /etc/selinux/targeted/contexts/files/file_contexts,
/usr/sbin/genhomedircon will not create a new context. This usually
indicates an incorrectly defined system account. If it is a system
account please make sure its login shell is /sbin/nologin.
The tomcat user appears to require a valid shell. And I cannot find any
reference to /usr/share/tomcat5 in
/etc/selinux/targeted/contexts/files/file_contexts
Thanks!
--
***********************************************************************
* John Oliver http://www.john-oliver.net/ *
* *
***********************************************************************
15 years, 2 months
Query regarding booleans
by Deependra Singh Shekhawat
Greetings,
I have written a selinux policy in fedora which actually have a boolean
declared within the policy and when the boolean is on some allow rules are
written which actually come into picture. But if the boolean is off the
SELinux denial message doesn't suggest the user to actually switch on the
boolean. I have seen in the normal case with the default booleans this is
not the case and the denial actually suggest the user to switch on the
boolean. I believe I need to do something more then what I am currently
doing that's why I am asking here.
Can you suggest me anything regarding this ?
Warm Regards
Deependra Singh Shekhawat
--
Type bits /keyID Date User ID
pub 1024D/483B234C 2007/06/29 Deependra Singh Shekhawat (Fedora Project) <
jeevanullas(a)gmail.com>
Key fingerprint = ED45 62EA A4D7 53FB 44C7 774A D55B F3F0 483B 234C
15 years, 2 months
