selinux March 2008

selinux@lists.fedoraproject.org

30 participants
57 discussions

Memory protection and system-config-securitylevel
by Kamil J. Dudek 28 Sep '09

28 Sep '09

Hello everybody Forgive me, if this subject has already been mentioned here, but I simply couldn't find answer anywhere. Few days ago I started system-config-securitylevel. I found something interesting in "Modify SELinux policies". A memory protection - there are four options in there. Two of them are enabled, with a description that if having this enabled is required by some program, it should be reported to bugzilla. I didn't do it, because of very strange effects after turning it off. Disabling "Allow all executable files to map memory areas as executable and readable, which is dangerous and such program should be reported to bugzilla" and "Allow all executable files to mark stack as executable.That shouldn't ever be required" option(translation from polish) made system act very strange. First thing I've observed was that Kobo game stopped working. GMPC stopped playing. Also stuff outside of Fedora like Java and NVidia drivers failed. So I should have "reported to bugzilla" to many application to make it have any sense. Such bug report would be only annoying but according to system-config-securitylevel... What is it with these two options? To make everything work properly they should be enabled, but their description that they should be disabled is confusing. Thank you and forgive me any mess I've done by this post -- Pozdrawiam - Kamil J. Dudek

2 3

mount point labels
by Clarkson, Mike R (US SSA) 14 Sep '09

14 Sep '09

I'm attempting to create the labeled mount point with the following command: mount -t nfs -o context=system_u:object_r:import_file_t:s0 nas:/vol/home /home/SimulatedImport/output/home The mount point is created without any errors, but the label that I specify in the mount command is not used. Instead of system_u:object_r:import_file_t, the context of the /home/SimulatedImport/output/home is system_u:object_r:nfs_t:s0. ls -dZ /home/SimulatedImport/output/home drwxr-xr-x root root system_u:object_r:nfs_t:s0 /home/m252/SimulatedImport/output/home I'm running RHEL5 with a policy built as mls off of the targeted policy. Does anyone know why the context label is not taking? Thanks

3 7

xinetd rsync --daemon problems
by Chuck Anderson 03 Jul '08

03 Jul '08

I'm using Fedora Core 6, and trying to start a rsync daemon via xinetd. The default configuration is: # default: off # description: The rsync server is a good addition to an ftp server, as it \ # allows crc checksumming etc. service rsync { disable = no socket_type = stream wait = no user = root server = /usr/bin/rsync server_args = --daemon log_on_failure += USERID } With this rsyncd.conf: motd file = /etc/rsyncd.motd pid file = /var/run/rsyncd.pid port = 873 uid = rsyncd gid = mirror use chroot = yes max connections = 10 log file = /var/log/rsyncd.log read only = yes hosts allow = 127.0.0.1, ::1, etc.... #hosts deny = 0.0.0.0/0, :: ignore nonreadable = yes transfer logging = yes timeout = 600 dont compress = * [fedora-linux-core] path = /srv/ftp/pub/fedora/linux/core comment = Fedora Linux Core [fedora-linux-core-updates] path = /srv/ftp/pub/fedora/linux/core/updates comment = Fedora Linux Core Updates [fedora-linux-extras] path = /srv/ftp/pub/fedora/linux/extras comment = Fedora Linux Extras [fedora-linux-core-test] path = /srv/ftp/pub/fedora/linux/core/test comment = Fedora Linux Core Test [fedora-linux-releases] path = /srv/ftp/pub/fedora/linux/releases comment = Fedora Linux Releases [fedora-linux-development] path = /srv/ftp/pub/fedora/linux/development comment = Fedora Linux Development [fedora-enchilada] path = /srv/ftp/pub/fedora comment = Fedora - The whole enchilada [fedora-linux-updates] path = /srv/ftp/pub/fedora/linux/updates comment = Fedora Linux Updates [fedora-web] path = /srv/ftp/pub/fedora/web comment = Web content for Fedora Linux mirrors I get these AVCs when running from xinetd and making a client connection that I don't get if I start the daemon directly via "rsync --daemon" as root: type=AVC msg=audit(1192132336.713:3464): avc: denied { lock } for pid=8488 comm="rsync" name="rsyncd.lock" dev=dm-4 ino=2064435 scontext=user_u:system_r:rsync_t:s0 tcontext=root:object_r:var_run_t:s0 tclass=file type=SYSCALL msg=audit(1192132336.713:3464): arch=40000003 syscall=221 success=no exit=-13 a0=4 a1=d a2=bff80730 a3=bff80730 items=0 ppid=8167 pid=8488 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) type=AVC_PATH msg=audit(1192132336.713:3464): path="/var/run/rsyncd.lock" type=AVC msg=audit(1192132400.044:3465): avc: denied { bind } for pid=8499 comm="rsync" scontext=user_u:system_r:rsync_t:s0 tcontext=user_u:system_r:rsync_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1192132400.044:3465): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bf8f4674 a2=4df50ff4 a3=3 items=0 ppid=8167 pid=8499 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) I tried creating and loading a policy module: # grep "rsync" /var/log/audit/audit.log | audit2allow -M rsyncd # semodule -i rsyncd.pp Here is rsyncd.te: module rsyncd 1.0; require { type var_run_t; type rsync_t; class netlink_route_socket create; class file { read write }; } #============= rsync_t ============== allow rsync_t self:netlink_route_socket create; allow rsync_t var_run_t:file { read write }; But I still get these AVCs: type=AVC msg=audit(1192139751.238:3586): avc: denied { bind } for pid=9311 comm="rsync" scontext=user_u:system_r:rsync_t:s0 tcontext=user_u:system_r:rsync_t:s0 tclass=netlink_route_socket type=SYSCALL msg=audit(1192139751.238:3586): arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfbb6144 a2=4df50ff4 a3=3 items=0 ppid=8732 pid=9311 auid=10002 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="rsync" exe="/usr/bin/rsync" subj=user_u:system_r:rsync_t:s0 key=(null) Additionally, when using xinetd I don't ever get any log messages in /var/log/rsyncd.log like I do when I run "rsync --daemon" directly: 2007/10/11 17:08:01 [8613] rsyncd version 2.6.9 starting, listening on port 873 2007/10/11 17:08:13 [8616] connect from dustpuppy.wpi.edu (2001:468:616:8c9:213:72ff:fe74:da15) 2007/10/11 17:08:13 [8616] rsync on fedora-enchilada/linux/ from dustpuppy.wpi.edu (2001:468:616:8c9:213:72ff:fe74:da15) 2007/10/11 21:08:13 [8616] building file list 2007/10/11 21:08:13 [8616] sent 1629 bytes received 106 bytes total size 19

2 2

Sendmail milters in Fedora 8
by Paul Howarth 03 Jun '08

03 Jun '08

Since upgrading my mail server from Fedora 7 to Fedora 8, I've come across some problems with the sockets used for communication between sendmail and two of the "milter" plugins I'm using with it, namely milter-regex and spamass-milter. It's very likely that other milters will have similar issues. The sockets used are created when the milter starts, as follows: milter-regex: /var/spool/milter-regex/sock (var_spool_t, inherited from parent directory) spamass-milter: /var/run/spamass-milter/spamass-milter.sock (spamd_var_run_t, in policy) These are pretty well the upstream locations, though I'm open to moving the milter-regex socket from /var/spool to /var/run or elsewhere for consistency. Since moving to Fedora 8, I've had to add the following to local policy to get these milters working: allow sendmail_t spamd_var_run_t:dir { search getattr }; allow sendmail_t spamd_var_run_t:sock_file { getattr write }; allow sendmail_t var_spool_t:sock_file { getattr write }; allow sendmail_t initrc_t:unix_stream_socket { read write connectto }; The last of these is the strangest, and relates to Bug #425958 (https://bugzilla.redhat.com/show_bug.cgi?id=425958). Whilst the socket file itself has the context listed above, the unix domain socket that sendmail connects to is still initrc_t, as can be seen from the output of "netstat -lpZ": ... unix 2 [ ACC ] STREAM LISTENING 14142 5853/spamass-milter system_u:system_r:initrc_t:s0 /var/run/spamass-milter/spamass-milter.sock unix 2 [ ACC ] STREAM LISTENING 13794 5779/milter-regex system_u:system_r:initrc_t:s0 /var/spool/milter-regex/sock ... So, my questions are: 1. Why are the sockets still initrc_t? 2. Is this a kernel issue or a userspace issue that should be fixed in the milters? 3. Should there be a standard place for milter sockets to live, and if so, where? 4. How come this worked OK in Fedora 7 and previous releases? Paul.

2 13

Starting stunnel from xinetd
by Ian Pilcher 04 May '08

04 May '08

Running fully updated Fedora 8, trying to start stunnel from xinetd, and getting a couple of denials: type=AVC msg=audit(1205149512.996:2338): avc: denied { write } for pid=14322 comm="stunnel" name="random_seed" dev=md1 ino=819429 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:stunnel_etc_t:s0 tclass=file type=AVC msg=audit(1205149512.998:2339): avc: denied { name_bind } for pid=14322 comm="stunnel" src=2873 scontext=unconfined_u:system_r:stunnel_t:s0-s0:c0.c1023 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket Aren't these things that stunnel should be expected to do? -- ======================================================================== Ian Pilcher arequipeno(a)gmail.com ========================================================================

2 9

Content type in public_html/DocumentRoot folder
by ashok harnal 29 Mar '08

29 Mar '08

Dear Gentlemen, Should web pages in public_html or DocumentRoot folder be of type user_t or httpd_sys_content_t or httpd_user_content_t? phpMyAdmin on installation from RPM package has contents of type user_t, drupal on installation from rpm package has contents of type httpd_sys_content_t. I am not clear about it? Is it possible to please clarify? Thanks, Ashok Harnal Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/

2 1

SELinux problem whith totem.
by Pedro Jose 29 Mar '08

29 Mar '08

Hello, I received this warning after installing totem-xine and run this for the first time. I am concerned because the solution will affect all applications on the system. (SELinux warning). This is: Resúmen: SELinux is preventing totem from changing the access protection of memory on the heap. Descripción Detallada: The totem application attempted to change the access protection of memory on the heap (e.g., allocated using malloc). This is a potential security problem. Applications should not be doing this. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If totem does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Permitiendo Acceso: If you want totem to continue, you must turn on the allow_execheap boolean. Note: This boolean will affect all applications on the system. El siguiente comando permitirá este acceso: setsebool -P allow_execheap=1 Información Adicional: Contexto Fuente system_u:system_r:unconfined_t:s0 Contexto Destino system_u:system_r:unconfined_t:s0 Objetos Destino None [ process ] Source totem Source Path /usr/bin/totem Port <Desconocido> Host localhost.localdomain Source RPM Packages totem-xine-2.20.1-1.lvn8 Target RPM Packages RPM de Políticas selinux-policy-3.0.8-93.fc8 SELinux Activado True Tipo de Política targeted MLS Activado True Modo Obediente Enforcing Nombre de Plugin allow_execheap Nombre de Equipo localhost.localdomain Plataforma Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686 Cantidad de Alertas 2 First Seen lun 24 mar 2008 22:26:42 CET Last Seen lun 24 mar 2008 22:26:42 CET Local ID c06e8b85-a4b1-4b69-8672-76e95d189cf9 Números de Línea Mensajes de Auditoría Crudos host=localhost.localdomain type=AVC msg=audit(1206394002.429:87): avc: denied { execheap } for pid=5071 comm="totem" scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1206394002.429:87): arch=40000003 syscall=125 success=no exit=-13 a0=808f000 a1=ad4000 a2=5 a3=bfe0eff0 items=0 ppid=1 pid=5071 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="totem" exe="/usr/bin/totem" subj=system_u:system_r:unconfined_t:s0 key=(null) How can I do? Thanks -- Saludos, Pedro

2 1

Problem with SELinux and rkhunter on Fedora 8
by Pedro Jose 29 Mar '08

29 Mar '08

Hello: I'm a spanish user of Fedora 8, a great distribution. I send this mail because I see a alert of SElinux troubleshooter with rkhunter. I have received two alerts: ResúmenSELinux is preventing sendmail (system_mail_t) "append" to /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 (var_t). Descripción DetalladaSELinux denied access requested by sendmail. It is not expected that this access is required by sendmail 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. Permitiendo AccesoSometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /var/rkhunter/tmp/rkhcronlog.mFxQaF5049, restorecon -v '/var/rkhunter/tmp/rkhcronlog.mFxQaF5049' If this does not work, there is currently no automatic way to allow this access. Instead, 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. Información AdicionalContexto Fuente: system_u:system_r:system_mail_t:s0Contexto Destino: system_u:object_r:var_t:s0Objetos Destino: /var/rkhunter/tmp/rkhcronlog.mFxQaF5049 [ file ]Source: sendmailSource Path: /usr/sbin/sendmail.sendmailPort: <Desconocido>Host: localhost.localdomainSource RPM Packages: sendmail-8.14.2-1.fc8Target RPM Packages: RPM de Políticas: selinux-policy-3.0.8-93.fc8SELinux Activado: TrueTipo de Política: targetedMLS Activado: TrueModo Obediente: EnforcingNombre de Plugin: catchall_fileNombre de Equipo: localhost.localdomainPlataforma: Linux localhost.localdomain 2.6.24.3-34.fc8 #1 SMP Wed Mar 12 18:17:20 EDT 2008 i686 i686Cantidad de Alertas: 1First Seen: mié 26 mar 2008 18:47:43 CETLast Seen: mié 26 mar 2008 18:47:43 CETLocal ID: 65abd64d-1a3f-4d68-a9b0-5ea5cf268d85Números de Línea: Mensajes de Auditoría Crudos :host=localhost.localdomain type=AVC msg=audit(1206553663.4:30): avc: denied { append } for pid=21759 comm="sendmail" path="/var/rkhunter/tmp/rkhcronlog.mFxQaF5049" dev=sda6 ino=1766018 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1206553663.4:30): arch=40000003 syscall=11 success=yes exit=0 a0=805848b a1=956760c a2=bfc98a58 a3=956760c items=0 ppid=21758 pid=21759 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) The second alert it's same, because change the destiny file. How do I solve it? Sorry, because my english is very bad. -- Saludos, Pedro

3 3

Re: gconf alert
by Valent Turkovic 29 Mar '08

29 Mar '08

On Tue, Mar 25, 2008 at 10:51 AM, Valent Turkovic <valent.turkovic(a)gmail.com> wrote: > On Tue, Mar 25, 2008 at 10:34 AM, Valent Turkovic > > <valent.turkovic(a)gmail.com> wrote: > > On Tue, Mar 25, 2008 at 10:11 AM, Valent Turkovic > > > > <valent.turkovic(a)gmail.com> wrote: > > > > > On Sun, Mar 23, 2008 at 6:11 AM, Andrew Farris <lordmorgul(a)gmail.com> wrote: > > > > Valent Turkovic wrote: > > > > > Here are the latest ones from F8. > > > > > > > > > > I'll reboot to F9 beta and send those also. > > > > > > > > > > Valent. > > > > > > > > Can you try logging in via startx rather than GDM and see if it keeps happening? > > > > I'd be interested to know. My recent problem with GDM logging my user in as > > > > bootloader_t has just disappeared and I'm not sure why (although there was a > > > > policy and gdm version update, so it could have been fixed accidentally). > > > > > I updated gdm today and I still see issues, just look at my > > atachement. I deleted /tmp completely and relabeled my rawhide > > againg, and just look at the number of alerts I get! > > > > I'll try startx now to see if it helps. > > I went to VT1 and did init 3 as root and in VT2 as regular users I > started gnome with startx command. Before that I deleted all selinux > alerts and these are the alerts I get from logging to gnome only. If > you want or need some specific alert just tell me which one and I'll > send it to you. > > Please look at the attachement. > > > > Cheers, > Valent. > Has anybody taken a look at this? I'm seeing hundreds of selinux alerts with each command I start be it as root (yum install... ) or just as a regular user (firefox, gnome-terminal ...) Any idea why is this happening? Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic

3 4

mailman not confined
by Chad Sellers 28 Mar '08

28 Mar '08

On F8 (as well as RHEL5 from the looks of things), it seems that mailman is not actually confined. The policy for it is compiled into the base module, but the transition never happens. So, mailmanctl and qrunner run in initrc_t. This looks like it is due to the fact that the default init script for mailman calls "/usr/bin/python /usr/lib/mailman/bin/mailmanctl" and "/usr/bin/python /usr/lib/mailman/bin/qrunner" rather than executing the scripts directly. The simple fix is to remove python from the init script. Anyone else noticing this problem? Any other ideas for a fix? Thanks, Chad Sellers

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux March 2008