selinux March 2005

selinux@lists.fedoraproject.org

64 participants
70 discussions

Re: Desktop apps interoperability
by Casey Schaufler 28 Mar '05

28 Mar '05

--- Tom <tom(a)lemuria.org> wrote: > On Mon, Mar 28, 2005 at 12:27:31AM -0500, Ivan > Gyurdiev wrote: > > Part of the problem seems to be the way Linux apps > treat /home, as the > > place for everything. > > It doesn't. It treats $HOME as the only place that > the user has > permission to store his stuff. On a well-configured > system, that > assumption is correct. Windows and MacOS are designed as single user systems. Unix and Linux are designed as multiuser systems. Configuring a Windows system for multiple concurrent users is quite painful. Configuring unix for a single user seems unnecessarily difficult. Interestly, when we did the B1/LSPP versions of unix the home directory model helped reduce the problem of user sensitivity restrictions by isolating the part of the directory hierarchy that had to be customized for the user. Casey Schaufler casey(a)schaufler-ca.com __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

selinux error and kernel lockups
by Justin Conover 28 Mar '05

28 Mar '05

The last 3 kernels in rawhide have hung my box on reboot with this being the last error i see on screen: SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts Any ideas? Kernel-1177 works fine I get the error with these 3 1191 1202 1208

2 2

Re: Fedora Core 3 Test Update: kernel-2.6.11-1.7_FC3
by Ivan Gyurdiev 28 Mar '05

28 Mar '05

On Mon, 2005-03-28 at 14:31 +0200, Aurelien Bompard wrote: > Ivan Gyurdiev wrote: > > > On Mon, 2005-03-28 at 13:46 +0200, Aurelien Bompard wrote: > >> Ivan Gyurdiev wrote: > >> > On Mon, 2005-03-28 at 12:55 +0200, Aurelien Bompard wrote: > >> >> Dave Jones wrote: > >> >> > Product : Fedora Core 3 > >> >> > Name : kernel > >> >> > Version : 2.6.11 > >> >> > Release : 1.7_FC3 > >> >> > >> >> With this kernel, snmpd fails to start, probably due to a selinux > >> >> error : snmpd: /usr/sbin/snmpd: error while loading shared libraries: > >> >> libbeecrypt.so.6: cannot enable executable stack as shared object > >> >> requires: Permission denied > >> > > >> > Are there any related avc messages in the log (dmesg) ? > >> > >> Yes: > >> audit(1112010219.531:0): avc: denied { execmem } for pid=4806 > >> comm=snmpd scontext=user_u:system_r:snmpd_t > >> tcontext=user_u:system_r:snmpd_t tclass=process > > > > I don't get this denial on rawhide - maybe it was fixed. > > See if there is an allow_execmem boolean, and enable that to > > work around the denial. > > Thanks, but the only boolean about snmp on FC3 is snmpd_disable_trans. > Could we have a selinux update too if this kernel is pushed to the official > updates ? cc-ed fedora-selinux-list. -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

1 0

libicudata.so.26.0, prelink, symbolic link, ...
by Tom London 25 Mar '05

25 Mar '05

Running targeted/enforcing, latest rawhide. Noticed the following AVC in log: Mar 25 07:38:36 localhost kernel: audit(1111765116.214:0): avc: denied { execmod } for pid=13994 comm=ld-linux.so.2 path=/usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 dev=dm-0 ino=164963 scontext=user_u:system_r:crond_t tcontext=system_u:object_r:lib_t tclass=file This appears to be generated by prelink run from cron. Here are entries from prelink.log: Prelinking /usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 /usr/sbin/prelink: /usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 Could not trace symbol resolving /usr/sbin/prelink: Could not prelink /usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0 because its dependency /usr/lib/openoffice.org1.9.87/program/libicudata.so.26.0 could not be prelinked /usr/sbin/prelink: Could not prelink /usr/lib/openoffice.org1.9.87/program/libicule.so.26.0 because its dependency /usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0 could not be prelinked Prelinking /usr/lib/openoffice.org1.9.87/program/libjvmaccessgcc3.so.3 /usr/sbin/prelink: Could not prelink /usr/lib/openoffice.org1.9.87/program/libvcl680li.so because its dependency /usr/lib/openoffice.org1.9.87/program/libicuuc.so.26.0 could not be prelinked <<<< etc. >>> Interestingly, the AVC seems to be showing the the type of the link instead of the type of the real file: [root@tlondon program]# ls -lZ libicudata* lrwxrwxrwx root root system_u:object_r:lib_t libicudata.so -> libicudata.so.26.0 lrwxrwxrwx root root system_u:object_r:lib_t libicudata.so.26 -> libicudata.so.26.0 -r--r--r-- root root system_u:object_r:shlib_t libicudata.so.26.0 Any significance to this? tom -- Tom London

3 2

Re: append only file system - selinux?
by Colin Walters 25 Mar '05

25 Mar '05

On Thu, 2005-03-24 at 15:58 -0500, Chris Stankaitis wrote: > If there is no 2.4 kernel solution, is there a 2.6/selinux solution to > my problem? that would not allow anyone (even root) to do anything but > append to logs? Yes, definitely. SELinux provides a fine-grained "append" permission for files that one can grant to specific domains for specific file types (such as log files). How exactly you implement this depends on which threats you are trying to counter. If you are simply trying to prevent a compromised daemon program which runs as uid 0 from changing logs, you could probably stick with the default Fedora "targeted" policy, which for a number of daemons such as Apache HTTPD already enforces this restriction. If you have daemons outside the targeted set, it is typically not too difficult to pull in the relevant policy from the "strict" into targeted, although there are a few gotchas which we can help with on fedora-selinux-list. In order to confine user logins (e.g. someone logging in as root via sshd), you will need to use the "strict" policy. You then have to make a decision on exactly what permissions to grant to the login. One option is to simply place root into the user_r role (i.e. not sysadm_r). There, the login is restricted in a way similar in effect to a Linux non-zero uid. However, system administration such as restarting daemons is not possible. It is theoretically possible to have a role similar to sysadm_r/sysadm_t but that prevents direct access to log files. However, it seems very likely to me that someone with privileges similar to sysadm_t could indirectly influence log files in other ways; e.g. by simply installing a malicious version of a daemon package. I imagine the same is true of the BSD securitylevel, of course. One nice thing about SELinux though is that you can use a tool such as "apol" to find all of those means of influence; i.e. what is the information flow from user_t to httpd_log_t. With BSD security levels you don't have any such assurance. If you have more questions about SELinux, please ask on fedora-selinux-list.

2 2

(newbie)Troubles with SE-Linux
by Paul Rumin 23 Mar '05

23 Mar '05

I would like to preface this with "I am not new to linux, but new to SE-Linux." I am not sure where to begin with this problem. After a clean install of Fedore Core 3 (at least I thought clean), I tried to login in with a user account a few days later. This did not work, so I logged in as root to change my user's password. 1. First, I tried changing the user's password with passwd. Although the program seemed to accept the new password. I still was unable to login in afterwards. 2. So I tried to manually change it within the /etc/passwd file. Knowing that there was a shadow file, I deleted the encrypted password in shadow and the "x" in the /etc/password file. Then, I ran passwd, followed by pwconv. But still nothing. 3. Finally, I tried to just use "su" command into my user's account to no avail. Now I am stuck. My understanding of SE is that you must match securities contents of the files, by using the -Z delimiter, which I did verify. If someone could steer me in the right direction I would appreciate it. Thx, Paul BTW, I did also try userdel/useradd with no success.

4 4

system-config-printer/cups: unconfined_t:fifo_file {read write} ?
by Tom London 23 Mar '05

23 Mar '05

Running targeted, latest development stuff. Configuring a 'new' USB printer from 'Desktop->System Settings->Printing' produces a wealth of avcs like: Mar 23 08:08:14 localhost kernel: audit(1111594094.345:0): avc: denied { read } for pid=19983 exe=/usr/sbin/cupsd path=pipe:[194059] dev=pipefs ino=194059 scontext=root:system_r:cupsd_t tcontext=root:system_r:unconfined_t tclass=fifo_file Mar 23 08:08:14 localhost kernel: audit(1111594094.345:0): avc: denied { write } for pid=19983 exe=/usr/sbin/cupsd path=pipe:[194059] dev=pipefs ino=194059 scontext=root:system_r:cupsd_t tcontext=root:system_r:unconfined_t tclass=fifo_file Appears to be asking for allow cupsd_t unconfined_t:fifo_file { read write }; This denial appears not to cause a problem, since the printer works. Should this be a 'dontaudit'? Something else (like a missing transition)? thanks, tom -- Tom London

3 6

Re: SELinux policy for ndiswrapper
by Ryan Gall 23 Mar '05

23 Mar '05

> > > > #Context for the driver configuration files > > > > /etc/ndiswrapper/ -- system_u:object_r:loadndis_content_t > > > > > > you probably want this: > > > > > > /etc/ndiswrapper(/.*)? system_u:object_r:loadndis_content_t > > > > > > so you can label all of the driver stuff tha'ts stored under that > > > directory and it's subdirectories. I don't think your pattern will > > > match anything. > > > > > Actually everything does get the correct labels here. I guess it is > > setting the label on the ndiswrapper directory and then all the child > > directories and files are inheriting that context. > > Well if the directory is labeled correctly, and files are created in > that directory, then it would get loadndis_content_t. However, if you > relabeled, I bet they would end up having the wrong labels. Try running > matchpathcon on a file in /etc/ndiswrapper, to see what file context > matches. (`matchpathcon /etc/ndiswrapper/somefile`). > > -- > Chris PeBenito > Tresys Technology, LLC > (410) 290-1411 x150 > You were right Chris, it did not work correctly when I relabeled. Thanks for all your help. Ryan

1 0

Recent SEL problems on FC3 box - named & dhcpd
by Ruth Ivimey-Cook 22 Mar '05

22 Mar '05

Hi folks, I have just started having some problems with selinux. I'm using FC3 with the targetted policy. It was running enforced; now merely permissive because of the problems. The box is running BIND/named in master mode (i.e. it is master for some domains, but not supplying those domains to other demons) and a dhcp server. I have today used yum to update both daemons from the updates-released repo, and am now getting errors of this sort (note this is a sample - there are many more): ... audit(1111501062.397:0): avc: denied { search } for pid=6809 exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:file_t tclass=dir audit(1111501062.397:0): avc: denied { search } for pid=6809 exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:file_t tclass=dir audit(1111501107.559:0): avc: denied { search } for pid=6828 exe=/usr/sbin/named name=/ dev=md1 ino=2 scontext=root:system_r:named_t tcontext=system_u:object_r:file_t tclass=dir ... audit(1111501250.295:0): avc: denied { write } for pid=6873 exe=/usr/sbin/named name=log dev=tmpfs ino=8452 scontext=root:system_r:named_t tcontext=user_u:object_r:device_t tclass=sock_file audit(1111501250.295:0): avc: denied { sendto } for pid=6873 exe=/usr/sbin/named path=/dev/log scontext=root:system_r:named_t tcontext=user_u:system_r:unconfined_t tclass=unix_dgram_socket audit(1111501302.433:0): avc: denied { search } for pid=6896 exe=/usr/sbin/dhcpd name=/ dev=md1 ino=2 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:file_t tclass=dir audit(1111501302.433:0): avc: denied { search } for pid=6896 exe=/usr/sbin/dhcpd name=etc dev=md1 ino=1368193 scontext=root:system_r:dhcpd_t tcontext=root:object_r:file_t tclass=dir audit(1111501302.437:0): avc: denied { read } for pid=6896 exe=/usr/sbin/dhcpd name=libc.so.6 dev=md1 ino=295646 scontext=root:system_r:dhcpd_t tcontext=root:object_r:file_t tclass=lnk_file ... Using audit2allow on the full set gives the following: allow dhcpd_t device_t:sock_file write; allow dhcpd_t file_t:dir { add_name search write }; allow dhcpd_t file_t:file { append create execute getattr link read unlink write }; allow dhcpd_t file_t:lnk_file read; allow dhcpd_t unconfined_t:unix_dgram_socket sendto; allow named_t device_t:sock_file write; allow named_t file_t:dir search; allow named_t file_t:file { execute getattr read }; allow named_t file_t:lnk_file read; allow named_t unconfined_t:unix_dgram_socket sendto; Now, would you expect that I should need to modify the settings? Might it be appropriate to recompile the policy even though I've not changed it myself? I have also been seeing many avc:s from attempts to run rndc. The following might be indicative (I just "prompted" these by doing service named status): audit(1111505098.098:0): avc: denied { search } for pid=12690 exe=/usr/sbin/rndc name=/ dev=md1 ino=2 scontext=root:system_r:ndc_t tcontext=system_u:object_r:file_t tclass=dir audit(1111505098.114:0): avc: denied { search } for pid=12690 exe=/usr/sbin/rndc name=etc dev=md1 ino=1368193 scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=dir audit(1111505098.114:0): avc: denied { read } for pid=12690 exe=/usr/sbin/rndc name=ld.so.cache dev=md1 ino=1370938 scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file audit(1111505098.114:0): avc: denied { getattr } for pid=12690 exe=/usr/sbin/rndc path=/etc/ld.so.cache dev=md1 ino=1370938 scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file audit(1111505098.114:0): avc: denied { read } for pid=12690 exe=/usr/sbin/rndc name=libcrypto.so.4 dev=md1 ino=211792 scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=lnk_file audit(1111505098.118:0): avc: denied { execute } for pid=12690 path=/lib/libcrypto.so.0.9.7a dev=md1 ino=214229 scontext=root:system_r:ndc_t tcontext=root:object_r:file_t tclass=file

4 8

[newbie] YUM hangs, can't update without reboot with selinux=0
by John Johnson 22 Mar '05

22 Mar '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone! Apologies for my lack of knowledge. If you are inclined to reply RTFM!, by all means do so, but include a link to TFM, please :-) When I run YUM, it runs briefly, then just sits there. Even when I do 'setenforce 0'. If I reboot with selinux=0 and the command line, it works. I can't find any complaints in any logs (tips on this appreciated too). Is there a way to allow updates without two complete shutdowns plus a file fix? Thanks in advance, JJ Fedora Core release 3 (Heidelberg) Linux www.johnjohnson.info 2.6.10-1.770_FC3 #1 Thu Feb 24 14:00:06 EST 2005 i686 i686 i386 GNU/Linux yum version 2.2.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCPtrB56Q2CqQ+d1wRAqdEAJ9EnOPtQ++Jmx9GsogIPmBj7hGrCQCdEST7 z6Hf/C3zcUKiZXQauhKEgLs= =Jx9V -----END PGP SIGNATURE-----

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux March 2005