June 2007 - selinux - Fedora Mailing-Lists

Memory protection and system-config-securitylevel

by Kamil J. Dudek

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

14 years, 8 months

2
3
0 / 0

mount point labels

by Clarkson, Mike R (US SSA)

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

14 years, 9 months

3
7
0 / 0

Confining TeX

by Jan Kasprzak

Hello, I am implementing a remote TeX server for our users, and I would like to confine it using SELinux (FC6, targeted policy). I need help or suggestions on possible approaches. What I want to do is the following: - I have a TeX installation in a separate directory - I want local users to be able to run TeX commands without restrictions - I want to have a daemon, running under a separate user, which will handle remote requests for TeX compilation. Under this user/daemon the TeX commands should be confined, so that they can only read TeX data files (the texmf/ tree), execute the TeX sub-commands (i.e. files under <texroot>/bin/ directory) - including the rights to the system libraries, locales, etc. as necessary. And the confined processes should write only to the texmf-var tree (autogenerated bitmap fonts, etc.) and to the temporary directory, reserved for TeX outputs (logs, DVI files, dvips outputs, etc.). My current solution is to create the tex_t domain, and tex_exec_t, tex_data_t, and tex_tmp_t file types, and make the daemon run "runcon -t tex_t -- tex myfile.tex" instead of plain "tex myfile.tex". Maybe there are better approaches than this: - maybe the "runcon" is not necessary, and TeX executables can be made to enter the tex_t domain automatically, when started by the UNIX user under which the daemon runs. - or maybe I should use SELinux users or roles instead of domains (?) - or maybe the daemon should run under its own special domain? The "runcon" approach allows local users to compile also untrusted TeX sources - i.e. they can be able to run TeX either under their own context, or via "runcon" in the confined mode. Any suggestions? -Yenya -- | Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > I will never go to meetings again because I think face to face meetings < > are the biggest waste of time you can ever have. --Linus Torvalds <

16 years, 8 months

2
2
0 / 0

Nagios Web Interface and SELinux

by Ryan Skadberg

I have been trying to get nagios up and running on 2 different machines. One running FC5 and one running FC6. Nagios itself starts up fine, but the web interface fails miserably. When looking at /var/log/messages, I see things like: Dec 3 11:38:17 xray kernel: audit(1165174697.348:289): avc: denied { execute_no_trans } for pid=22237 comm="httpd" name="tac.cgi" dev=dm-0 ino=11272226 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file I noticed in the selinux-policy-targeted Changelog: * Wed Jul 26 2006 Dan Walsh <dwalsh(a)redhat.com> 2.3.3-13 - Add nagios policy This may have been for the program itself or maybe the web interface, but it sure doesn't seem to be working for me. Both systems are set to: SELINUX=enforcing SELINUXTYPE=targeted SETLOCALDEFS=0 Anyone have any advice on how to fix this? Thanks! Skadz

16 years, 9 months

3
4
0 / 0

AVC Denied Dhcp and Iptables.

by piotreek

Hi guys i found some strange messages in my logs. It seams that selinux is blocking a dhcp an Iptables. I found similar post on group about DHCP but my messages are different.I am using FC7 latest policy update didn't resolve the problem. P.S I am using firestater as my firewall. Have a look Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:4): avc: denied { execute } for pid=1775 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:5): avc: denied { getattr } for pid=1775 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:6): avc: denied { getattr } for pid=1775 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:7): avc: denied { execute } for pid=1776 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:8): avc: denied { getattr } for pid=1776 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:9): avc: denied { getattr } for pid=1776 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:10): avc: denied { execute } for pid=1778 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:11): avc: denied { getattr } for pid=1778 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.475:12): avc: denied { getattr } for pid=1778 comm="sh" name="iptables" dev=sdb1 ino=3793910 scontext=system_u:system_r:dhcpc_t:s0 tcontext=system_u:object_r:iptables_exec_t:s0 tclass=file Jun 7 08:08:54 c79-70 kernel: audit(1181196527.975:13): audit_pid=1863 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0 Greatings Peter

16 years, 11 months

3
3
0 / 0

Proactive SELinux fixes from automatic collection of logs

by Rahul Sundaram

Hi There are many instances where SELinux policy causes AVC denials while running programs. Some of these are policy issues, some actual bugs in the program or security issues and others where the denial is rather harmless and can be ignored for all practical purposes. It is sometimes tedious to go and file a bug report methodologically on all these denials in hope that we uncover and fix real policy issues. What would be better is for users to run in some opt-in program that automatically sends either the audit or messages log or both to central server and the SELinux developers proactively fix policy issues without the overhead of users filing bug reports. I would gladly run a program and I would guess that many users would find this a much better and easier way to report issues. We could even tie this to a GUI and first boot in the installer. Kind of a smolt (http://smolt.fedoraproject.org/stats) for SELinux if you will. Comments? Rahul

16 years, 11 months

4
5
0 / 0

Relabeling question

by Tony Molloy

Hi, This is on CentOS but it's a SELinux question. I have a filesystem which I need to make available under ftp ( vsftpd ) httpd ( apache ) and NFS. It contains our local mirrors. What should the permissions and the SELInux context be on the filesystem and how can I relabel it so that it can be available under all three. The current permissions/SELinux context are drwxr-xr-x root root system_u:object_r:default_t mirrors and I want something like drwxr-xr-x root root root:object_r:public_content_t TEST Thanks, Tony

16 years, 12 months

3
5
0 / 0

Re: Proactive SELinux fixes from automatic collection of logs

by John Dennis

On Fri, 2007-06-29 at 17:33 +0200, Paulo Santos wrote: > John and Daniel, > > In which case would then be used the application[1] that Daniel wants > the Infrastructure Team to host ? > > [1] http://fedoraproject.org/wiki/Infrastructure/RFR/SELinux > > From what you say, the setroubleshoot tool is already a pretty > complete application. Let me explain Dan's request so you can see it in context. One of the features of setroubleshoot is its ability to scan a log file and analyze AVC denials. You can already do this in the GUI. But for folks who don't have setroubleshoot installed the idea was folks could go to a web page and upload the log file and have the CGI script perform the analysis and display the results. The request you cite was for CGI support for this. I believe the CGI is already written, it just needs "a place to live". BTW, log file analysis is a compromise because the analysis parts of the tool cannot interrogate the system for information not in the log, this may result in a less thorough analysis. BTW, I realized after sending my earlier reply it contained a number of typos and I didn't proofread it, my apologies if it made it hard to read. -- John Dennis <jdennis(a)redhat.com>

16 years, 12 months

1
0
0 / 0

SeLinux and Fc 6

by shazyboy khan

Hi I use fedora core 6. I need to work on ipsec netlabels but cannot understand some tutorials because things change very frequency. How I understand selinux? Loadable Policy Modules? Ipsec? Any simple and complete tutorial? Where is policy in text format? How I compile? Any good gui tools? Do I need lspp kernel? What mode is suitable for mentioned work: strict or targeted? Whats the difference? Permissive I guess on the other side is suitable for experimentation. Any other suggestions? tankoo shazyboy.

16 years, 12 months

1
0
0 / 0

Targeted/MCS feedback on F7

by Bruno Wolff III

I played around a bit with using MCS under the targeted policy and wanted to provide some feedback. Adding labels for context levels doesn't seem to work quite right. For example: [root@cerberus ~]# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:sysadm_r:unconfined_t [root@cerberus ~]# semanage translation -a -T test1 s0:c1 /etc/init.d/functions: line 19: /sbin/consoletype: Permission denied /etc/profile.d/lang.sh: line 49: /sbin/consoletype: Permission denied basename: write error: Permission denied basename: write error: Permission denied env: /etc/init.d/mcstrans: Permission denied I have to restart the mcstrans service to get the label names to show up. Having the context type for new files include all of the labels is a pain. While this is probably more safe from a forgetting to label a file perspective, it ends up labelling a lot of files you aren't going to be aware of. For example when I tried ending my experiment and took away access to categories, I found that some of my gnome profile files had been labelled with categories and I could no longer access them. I think some system updates I did during the experiment also resulted in files being labelled with categories as some of the gnome default files were inaccessible to me. While trying to fix this I found that chcat doesn't seem to do recursive labelling. While I could use find and xargs, a -r option would be nice. However, instead of trying find and xargs I tried fixfiles instead. The good and bad news is that fixfiles solved my immediate problem and the files were relabelled without categories. However, that suggests that if people are using MCS labelling and do a relabel of their system for some reason, all of the category labels are going to be lost. I think if I were going to use such a system, I would want to have a command to set the default category labels to apply (and another to check what they are set to). And I would want to make sure things like config files didn't get labelled. Working at the shell level this wouldn't be a problem, but if you are doing things from the desktop this would be harder to do. Maybe there could be a new context for a user's config files and those wouldn't get labelled the same as other files do by default.

16 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux June 2007