selinux May 2010

selinux@lists.fedoraproject.org

22 participants
31 discussions

rhel6 beta mls enforcing seeing lots of these ...
by Ted Toth 12 May '10

12 May '10

type=AVC msg=audit(1273678015.579:14138): avc: denied { connectto } for pid=1073 comm="sedispatch" path="/var/run/dbus/system_bus_socket" scontext=system_u:system_r:audisp_t:s15:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s15:c0.c1023 tclass=unix_stream_socket Ted

2 1

Fwd: talking to mcstrans in MLS enforcing on rhel6 beta
by Ted Toth 12 May '10

12 May '10

---------- Forwarded message ---------- From: Xavier Toth <txtoth(a)gmail.com> Date: Wed, May 12, 2010 at 10:38 AM Subject: Re: talking to mcstrans in MLS enforcing on rhel6 beta To: Stephen Smalley <sds(a)tycho.nsa.gov> On Tue, May 11, 2010 at 4:13 PM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote: > On Tue, 2010-05-11 at 11:10 -0500, Xavier Toth wrote: >> I'm a bit confused about something. mcstransd creates a socket and >> through a transition rule it get labeled setrans_var_run_t (this is >> also the type used with mls_trusted_object in the setrans policy) >> however when other apps try and connect to it the target context type >> is setrans_t which of course isn't trusted so no one can connect. As >> an experiment I added setrans_t as a mls trusted object and then other >> apps could connect. Not sure where the target context comes from on >> connectto because the socket file is label setrans_var_run_t on the >> disk. Something needs fixing just not sure what. Doesn't seem right to >> add 'mls_trusted_object(setrans_t)'. > > When you create and bind a Unix domain socket in the file system > namespace (as opposed to the abstract namespace), there are two objects: > the socket itself (created upon the socket call, labeled with the label > of the creating process), and the file (created upon the bind call, > labeled in accordance with the usual file labeling behavior). > Connecting to such a socket requires both write access to the file and > connectto permission to the socket. So connectto is a socket-to-socket > (which looks like process-to-process since sockets are labeled based on > creating process and act as proxies/queues between processes) check. > > -- > Stephen Smalley > National Security Agency > > So mls_trusted_object(setrans_t) needs to be added.

2 1

talking to mcstrans in MLS enforcing on rhel6 beta
by Ted Toth 11 May '10

11 May '10

I'm a bit confused about something. mcstransd creates a socket and through a transition rule it get labeled setrans_var_run_t (this is also the type used with mls_trusted_object in the setrans policy) however when other apps try and connect to it the target context type is setrans_t which of course isn't trusted so no one can connect. As an experiment I added setrans_t as a mls trusted object and then other apps could connect. Not sure where the target context comes from on connectto because the socket file is label setrans_var_run_t on the disk. Something needs fixing just not sure what. Doesn't seem right to add 'mls_trusted_object(setrans_t)'. Ted

3 2

Re: Need new secret sauce
by Dominick Grift 10 May '10

10 May '10

On 05/08/2010 04:20 AM, David Highley wrote: I took a quick look at the README file enclosed with the archive, and i think the second route may be the better solution since you might be able to isolate sshdfilter from ssh for a large part. This is in my view important because sshd is a trusted service, meaning it is allowed much access becuase it needs it and we rely on sshd for security. Below you will find a starting point for policy for sshdfilter in the second scenario. This policy is incomplete and it may also have errors. You might be able to use it as a starting point and to perfect the policy. That would require testing, extending policy (using audit2allow and common sense) rebuilding, reinstalling policy , retesting etc. until it is perfect. To do that you must ensure that you have configured the service properly and that you do the development ofthe policy and testing in a secure environment. 1. Establishing sshdfilter object locations: So from the README file i understand theres 3 files: - The initscript (/etc/rc.d/init.d/sshdfilter - The config file(s) (/etc/sshdfilterrc.*) - The sshdfilter application executable file (/usr/sbin/sshdfilter) 2. Declare types for sshdfilter objects, the sshdfilter subject, then makes the types usable type for their purpose and define file context specifications for the sshdfilter file objects. Additionally make the sshdfilter subject type permissive (will not work in el5) to make testing more easy and secure. 3. Source policy module for sshdfilter. Create a work directory. This is where we will store the source policy module for our sshdfilter application. Keep the source policy module, as you may need to extend, modify, rebuild it later. A Selinux source policy module has 3 files. A type enforcement file ("modulename".te), A interface file ("modulename.if"), and a file context specification file ("modulename".fc). The type enforcement file has declarations and policy that are local to the module. The interface file has policy where the target of the interaction is a type declared in the type enforcement file of the module. e.g. shared policy. If external domains want to interact with sshdfilter in anyway, then the sshdfilter.if file should facilitate any access required for other domains to interact with it. The file context specification file has file object context specifications for file object types that are declared in the type enforcement file. 4. sshdfilter.te touch a file called sshdfilter.te in your working directory. The file will be split in two parts: first the personal declarations and second the personal policy. Add the following to the sshdfilter.te file: policy_module(sshdfilter, 1.0.0) type sshdfilter_t; type sshdfilter_exec_t; init_daemon_domain(sshdfilter_t, sshdfilter_exec_t) type sshdfilter_initrc_exec_t; init_script_file(sshdfilter_initrc_exec_t) type sshdfilter_etc_t; files_config_file(sshdfilter_etc_t) # permissive domains will not work in el5. permissve sshdfilter_t; # policy below (todo) So above we declared types for the 3 files and te process. We started by declaring a new policy module called sshdfilter and gave it a version number of 1.0.0. Once the module is installed you can use semodule -l to list these policy module details. sshdfilter_t is the type that is declared for the sshdfilter process. sshdfilter_exec_t is the type declared for the sshdfilter application executable file (/usr/sbin/sshdfilter) Both type are made a init daemon domain by calling the init_daemon_domain() interface with the two types as parameters. This is just a macro that gets expanded with m4 to actual policy that the kernel can understand. The macros are used to make policy maintainable for humans. Basically its a way to group policy. The type sshdfilter_initrc_exec_t type is the type for the sshdfilter init script (/etc/rc.d/init.d/sshdfilter) This type is made a valid init script file type by calling the init_script_file interface and supplying the type used for the init script as a parameter. The next type declared is sshdfilter_etc_t, This is the type for the sshdfilter configuration files (/etc/sshdfilterrc.*) The type is made usuable for configuration files by calling files_config_file(), with the type that we have declared for sshdfilters file objects in /etc as its parameter. Finally we made the subject type sshdfilter_t a "permissive domain". This may not work on older selinux implementations. Permissive domains is a way to run a single domain in permissive mode as opposed to running the full system in permissive mode when one runs the setenforce 0 command. This allows you to test a single domain. We did not add any policy yet to out type enforcement file. This is because i do not know what access the application needs. You can find out by testing, editing policy, testing etc. The audit2allow command and ausearch command can help parse AVC denials which can be used to extend your sshdfilter_t domain. 5. sshdfilter.fc We declared the types for sshdfilter in our type enforcement source policy file. Now we must assign the file object types to actual objects on the file system. e.g. create file object context specifications. Add the following to the sshdfilter.fc file: /etc/rc\.d/init\.d/sshdfilter -- gen_context(system_u:object_r:sshdfilter_initrc_exec_t, s0) /etc/sshdfilterrc.* -- gen_context(system_u:object_r:sshdfilter_etc_t, s0) /usr/sbin/sshdfilter -- gen_context(system_u:object_r:sshdfilter_exec_t, s0) That will tell the system what file object to label with the types we declared for our domain. 6. sshdfilter.if We will skip this section for simplicity. We may need it later, if it turns out some other domain wants to interact with out sshdfilter_t domain or any file object types it owns. 7. Building and installing. By now we should have a solid foundation for our new domain. By solid i mean that the domain type is declared (sshfilter_t) and all (known) objects own by the sshdfilter_t domain have types declared and file object contexts specified. The init_daemon_domain() interface call provides all policy that is needed for init to transition into the sshdfilter_t domain. The permissive domain sshdfilter_t will allow sshdfilter_t all access but will log "would be denied" access vectors. If you are using an older selinux implementation, you may want to comment that line out and do the policy testing with selinux in permissive mode instead. cd into your working dir and run the following to build a binary representation of the sshdfilter source policy module: make -f /usr/share/selinux/devel/Makefile sshdfilter.pp ( on el5 this requires that you have the selinux-policy-devel package installed ) If all goes well this should create the binary policy module which we can load into the policy store with the following command: sudo semodule -i sshdfilter.pp Use the semodule command to list, install , reinstall , remove modules. Now all you have to do is restore the contexts of the objects defined in the sshdfilter.fc file to reflect the type we declared in our type enforcement file. Then just run and test the app, either in permissive mode or if possible using the permissive domain declaration described above. Collect any AVC denials for dmesg , /var/log/messages /var/log/audit/audit.log and use those AVC denials to make policy decisions and extend your type enforcement file. Rebuild a new binary representation afterward, reinstall it into the policy store and test it all over again. Repeat this untill all AVC denials are gone and untill your application works like it should. Any questions? Please let me know. Disclaimer: The may be errors above. Try at your own risk. > > I'm attaching the down load. It has two methods of installation so the > files vary depending on approach. I wonder if there would be some way to > get this into the repo.

1 0

Need new secret sauce
by David Highley 07 May '10

07 May '10

Did the usual dance after selinux policy seemed to get wiped out. Does not appear to be working. I also did an semodule -r mysshdfilter just to make sure there was not some thing fouled up. grep sshdfilter /var/log/audit/audit.log | tail -2 | audit2allow -M mysshdfilter semodule -i mysshdfilter.pp type=SYSCALL msg=audit(1273152205.754:30341): arch=c000003e syscall=2 success=no exit=-13 a0=1f16088 a1=241 a2=1b6 a3=7f26f5e60920 items=0 ppid=24925 pid=24926 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=731 comm="sshdfilter" exe="/usr/bin/perl" subj=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1273152205.754:30341): avc: denied { write } for pid=24926 comm="sshdfilter" name="sshdfilter.pid.SSHD" dev=dm-0 ino=539 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file

2 3

Need new secret sauce
by David Highley 06 May '10

06 May '10

1 0

about selinux_validate_context
by Sandra Rueda 05 May '10

05 May '10

Hello, I am getting the following rule in my SELinux policy: allow user_t security_t:file {read write}; I traced it and I found the interface selinux_validate_context grants permissions to read and write files with type security_t. Are these permissions required to validate a security context? Should they be granted to user_t? Thanks, Sandra

2 3

Apache CGI scripts - how to run them cleanly
by Lars Poulsen 05 May '10

05 May '10

I am trying to get my Fedora 12 systems to run cleanly with SELinux enabled. Previously I had just been running in permissive mode and mostly ignoring the alerts, but my ambition level has gone up! After a few days of following up on every alert I saw by tweaking booleans and file context types appropriately, I am pleased with how few violations are being reported, but I am now getting to some that I cannot figure out, such as the one below. It originates in a CGI script written in PERL. In my installations, the base of the website data is in /home/httpd rather than in /var/www; this choice is because I try to keep permanent data that should be kept across OS version updates out of the root filesystem, and the website is too small to merit a filesystem of its own. It does mean that I need to tweek a bunch of labels, such as * setsebool -P httpd_read_user_content 1 * setsebool -P httpd_enable_home_dirs 1 * setsebool -P httpd_read_user_content 1 * setsebool -P samba_enable_home_dirs 1 * setsebool -P use_samba_home_dirs 1 * setsebool -P samba_export_all_rw 1 * * chcon -R -t httpd_user_content_t /var/log/phone * chcon -R -t httpd_user_content_t /home/httpd/twiki/data * chcon -R -t httpd_sys_script_exec_t /home/httpd/twiki/bin * chcon -R -t httpd_sys_script_exec_t /home/httpd/cgi-bin * chcon -t httpd_sys_content_t /home/httpd * chcon -R -t httpd_sys_content_t /home/httpd/html * chcon -R -t httpd_user_content_t /home/sales/serial * chcon -R -t htppd_user_content_t /home/sales/leads But the one that baffles me the most is this one, which comes up when I trigger the CGI script /home/httpd/cgi-bin/serial.cgi (written in PERL). I *think* the "search" access is triggered when the script is launched. SELinux says that / is labeled as user_home_dir_t, but this is not true; ls -Zd confirms that it is indeed labeled as root_t. And even if it were labeled user_homme_dir_t, should the boolean httpd_enable_home_dirs not make it allright ? Any insights would be appreciated. Lars Poulsen Afar Communications ------------------------------------------------------------------------------------------------------------------------- Summary: SELinux is preventing /usr/bin/perl "search" access to /. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by serial.cgi. / may be a mislabeled. / default SELinux type is root_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 creating 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 against this package. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon '/', if this file is a directory, you can recursively restore using restorecon -R '/'. Fix Command: /sbin/restorecon '/' Additional Information: Source Context system_u:system_r:httpd_sys_script_t:s0 Target Context unconfined_u:object_r:user_home_dir_t:s0 Target Objects / [ dir ] Source serial.cgi Source Path /usr/bin/perl Port <Unknown> Host shadow.afar.net Source RPM Packages perl-5.10.0-87.fc12 Target RPM Packages filesystem-2.4.30-2.fc12 Policy RPM selinux-policy-3.6.32-113.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name restorecon Host Name shadow.afar.net Platform Linux shadow.afar.net 2.6.32.11-99.fc12.i686.PAE #1 SMP Mon Apr 5 16:15:03 EDT 2010 i686 i686 Alert Count 6 First Seen Tue 04 May 2010 10:27:30 AM PDT Last Seen Tue 04 May 2010 11:15:28 AM PDT Local ID 6cee89bd-3559-4483-9802-fa2dc320bd26 Line Numbers Raw Audit Messages node=shadow.afar.net type=AVC msg=audit(1272996928.152:22292): avc: denied { search } for pid=15632 comm="serial.cgi" name="/" dev=dm-7 ino=2 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir node=shadow.afar.net type=SYSCALL msg=audit(1272996928.152:22292): arch=40000003 syscall=5 success=yes exit=3 a0=8b6767c a1=8000 a2=0 a3=0 items=0 ppid=31549 pid=15632 auid=4294967295 uid=48 gid=489 euid=48 suid=48 fsuid=48 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm="serial.cgi" exe="/usr/bin/perl" subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)

2 6

SELinux preventing printing.
by Steve Blackwell 03 May '10

03 May '10

My wife got a Lexmark X2670 printer with her new laptop and I connected it to my Fedora 11 system, and downloaded the driver from Lexmark. SELinux is preventing me from printing to it. At first I got 4 AVCs about attempting to load shared libraries that require text relocation. This I fixed with: # semanage fcontext -a -t textrel_shlib_t '/usr/local/lexmark/lxk08/lib(/.*)?' # restorecon -R -v /usr/local/lexmark/lxk08/lib but now I'm getting this one: Raw Audit Messages : node=steve.blackwell type=AVC msg=audit(1272894966.836:66): avc: denied { search } for pid=29536 comm="printdriver" name="lib" dev=dm-0 ino=7635564 scontext=system_u:system_r:cupsd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:textrel_shlib_t:s0 tclass=dir node=steve.blackwell type=SYSCALL msg=audit(1272894966.836:66): arch=40000003 syscall=5 success=no exit=-13 a0=93cf620 a1=0 a2=0 a3=389660 items=0 ppid=1655 pid=29536 auid=4294967295 uid=4 gid=7 euid=4 suid=4 fsuid=4 egid=7 sgid=7 fsgid=7 tty=(none) ses=4294967295 comm="printdriver" exe="/usr/local/lexmark/lxk08/bin/printdriver" subj=system_u:system_r:cupsd_t:s0-s0:c0.c1023 key=(null) What is the "correct" way to solve this? Create am audit2allow rule? Thanks, Steve

2 3

Mod-security (mlogc) problem
by Arthur Dent 03 May '10

03 May '10

Hello all, I believe in a multi-layered approach towards security, so as well as SELinux I use Mod-Security to protect the web server on my F11 machine. Recently I started using the ModSecurity Community Console to analyse the mod-security denials. This requires using the mlogc logging application that comes bundled with the mod_security-2.5.12-1.fc11.i586 package. Now every time a mod-security denial is triggered I get 3 SEL AVCs (currently in permissive mode while I sort this out). They say: SELinux has denied the mlogc access to potentially mislabeled files /var/run/pcscd.pid. This means that SELinux will not allow httpd to use these files. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access. If you want to change the file context of /var/run/pcscd.pid so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t '/var/run/pcscd.pid'. A similar one for /var/run/pcsd.pub and then one for: SELinux is preventing the mlogc from using potentially mislabeled files 636F6F6C6B6579706B313173452D47617465203020302D30 (auth_cache_t). (Actual AVCs below) If I try doing the chcon -t httpd_sys_content_t '/var/run/pcscd.xxx' as recommended by sealert I only get the one with the strange filename each time I get a mod-sec alert. However, now of course I get this: SELinux denied access requested by certwatch. /var/run/pcscd.pub may be a mislabeled. /var/run/pcscd.pub default SELinux type is pcscd_var_run_t, but its current type is httpd_sys_content_t. Changing this file back to the default type, may fix your problem. (and another one for .pid) So I need to put the file context back to what it was using restorecon.... Audit2allow suggests this: require { type auth_cache_t; type httpd_t; type pcscd_var_run_t; class file { read write getattr open }; } #============= httpd_t ============== allow httpd_t auth_cache_t:file { read write }; allow httpd_t pcscd_var_run_t:file { read getattr open }; What do you think is the best solution to this problem? Thanks in advance for any help or suggestions... Mark AVCs ==== Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { read } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file node=troodos.org.uk type=AVC msg=audit(1270480904.700:37928): avc: denied { open } for pid=9674 comm="mlogc" name="pcscd.pid" dev=sda5 ino=362220 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file node=troodos.org.uk type=SYSCALL msg=audit(1270480904.700:37928): arch=40000003 syscall=5 success=yes exit=10 a0=d348ea a1=0 a2=1b6 a3=d348e8 items=0 ppid=9643 pid=9674 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1270488357.977:38184): avc: denied { getattr } for pid=10531 comm="mlogc" path="/var/run/pcscd.pub" dev=sda5 ino=362221 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:pcscd_var_run_t:s0 tclass=file node=troodos.org.uk type=SYSCALL msg=audit(1270488357.977:38184): arch=40000003 syscall=195 success=yes exit=0 a0=d345ab a1=b64279ac a2=d1eff4 a3=3 items=0 ppid=9643 pid=10531 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null) Raw Audit Messages : node=troodos.org.uk type=AVC msg=audit(1270488685.640:38200): avc: denied { read write } for pid=10661 comm="mlogc" name=636F6F6C6B6579706B313173452D47617465203020302D30 dev=sda5 ino=372384 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:auth_cache_t:s0 tclass=file node=troodos.org.uk type=SYSCALL msg=audit(1270488685.640:38200): arch=40000003 syscall=5 success=yes exit=12 a0=b5830dc0 a1=20002 a2=180 a3=b5830da8 items=0 ppid=10644 pid=10661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mlogc" exe="/usr/bin/mlogc" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

5 42

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux May 2010