From brett at eecs.tufts.edu Sun May 1 00:30:42 2005 From: brett at eecs.tufts.edu (brett) Date: Sat, 30 Apr 2005 20:30:42 -0400 (EDT) Subject: gpg through apache and php? In-Reply-To: <1114783937.9367.60.camel@moss-spartans.epoch.ncsc.mil> Message-ID: > > If you organize your /var/www > tree in a conventional manner, then it should work fairly smoothly. > Problems arise when people put CGIs all over the place (not just in cgi- > bin), and don't use any conventions in separating files that should be > read-only vs. read-write. OK, you are selling me on the /var/www tree. What is "a conventional manner." Needless to say you don't have to explain it all to me, perhaps you can point me to a resource that describes what you are talking about. For example, where do user PHP scripts live in this tree? Are they readable\writable by others? > Simplest thing to do is just to install policy sources and just allow > the permissions you want, e.g. > yum install selinux-policy-targeted-sources > cd /etc/selinux/targeted/src/policy > repeat: > audit2allow -d >> domains/misc/local.te > make load > > > > Might be quicker to switch to permissive mode (setenforce 0), run your > CGI via apache, then run audit2allow once, as that will then collect > _all_ of the audit messages that would have been denied in enforcing > mode. So selinux-policy-targeted-sources is something that lets me change policy? And audit2allow is something that monitors what processes are open and "allows" them to pass through SELinux? Thanks, -brett From dwalsh at redhat.com Mon May 2 15:09:05 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 May 2005 11:09:05 -0400 Subject: selinux-policy-strict-1.23.13-4: suggestions? In-Reply-To: <4c4ba1530504301416344ce68e@mail.gmail.com> References: <4c4ba1530504301416344ce68e@mail.gmail.com> Message-ID: <42764291.40702@redhat.com> Tom London wrote: >Running strict/enforcing, latest rawhide. > >I finally got around to 'blowing the dust off' of my strict PC. I >updated to latest rawhide, did a 'fixfiles relabel', and rebooted. > >Graphical login failed. Appears that xdm is failing on creating a sem: >Apr 30 13:20:44 fedora kernel: audit(1114892386.776:0): avc: denied >{ create } for key=1417649221 scontext=system_u:system_r:xdm_t >tcontext=system_u:system_r:xdm_t tclass=sem >Apr 30 13:25:35 fedora kernel: audit(1114892735.514:0): avc: denied >{ unix_read unix_write } for key=199061348 >scontext=system_u:system_r:xdm_t tcontext=system_u:system_r:xdm_t >tclass=sem > > >Adding: >allow xdm_t self:sem { create unix_read unix_write }; >to xdm.te seems to fix this. That OK? > > > I will add. >Also, running firefox proxied through privoxy generates: >Apr 30 13:48:23 fedora kernel: audit(1114894103.357:0): avc: denied >{ name_connect } for dest=8118 scontext=user_u:user_r:user_mozilla_t >tcontext=system_u:object_r:port_t tclass=tcp_socket >or >allow user_mozilla_t port_t:tcp_socket name_connect; >That right? > > > Better solution is to add 8118 to the list of http_cache_port_t in net_contexts portcon tcp 8118 system_u:object_r:http_cache_port_t Your solution allows mozilla to connect to any ports. >Going through /var/log/messages: >Early on, I get this: >Apr 30 13:27:05 fedora kernel: SELinux: Completing initialization. >Apr 30 13:27:05 fedora kernel: SELinux: Setting up existing superblocks. >Apr 30 13:27:05 fedora kernel: audit(1114867589.097:0): avc: denied >{ write } for path=pipe:[1886] dev=pipefs ino=1886 >scontext=system_u:system_r:kernel_t >tcontext=system_u:object_r:unlabeled_t tclass=fifo_file >Apr 30 13:27:05 fedora kernel: SELinux: initialized (dev hda2, type >ext3), uses xattr >Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev tmpfs, type >tmpfs), uses transition SIDs >and >Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev rootfs, type >rootfs), uses genfs_contexts >Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev sysfs, type >sysfs), uses genfs_contexts >Apr 30 13:27:06 fedora kernel: audit(1114867589.937:0): avc: denied >{ read } for name=class at vc@vcsa1 dev=tmpfs ino=1836 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: audit(1114867589.939:0): avc: denied >{ read } for name=class at vc@vcs1 dev=tmpfs ino=1830 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: SELinux: initialized (dev usbfs, type >usbfs), uses genfs_contexts >Apr 30 13:27:06 fedora kernel: audit(1114867590.492:0): avc: denied >{ create } for name=input scontext=system_u:system_r:udev_t >tcontext=system_u:object_r:tmpfs_t tclass=dir >Apr 30 13:27:06 fedora kernel: audit(1114867590.494:0): avc: denied >{ create } for name=input scontext=system_u:system_r:udev_t >tcontext=system_u:object_r:tmpfs_t tclass=dir >Apr 30 13:27:06 fedora kernel: audit(1114867591.604:0): avc: denied >{ write } for name=class at vc@vcs1 dev=tmpfs ino=1830 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: audit(1114867591.627:0): avc: denied >{ write } for name=class at vc@vcsa1 dev=tmpfs ino=1836 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: audit(1114867591.754:0): avc: denied >{ read } for name=class at vc@vcs1 dev=tmpfs ino=1830 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: audit(1114867591.764:0): avc: denied >{ read } for name=class at vc@vcsa1 dev=tmpfs ino=1836 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file >Apr 30 13:27:06 fedora kernel: audit(1114867592.051:0): avc: denied >{ write } for name=class at vc@vcsa1 dev=tmpfs ino=1836 >scontext=system_u:system_r:udev_t tcontext=system_u:object_r:tmpfs_t >tclass=file ><<<>>> >Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied >{ search } for name=485 dev=proc ino=31784962 >scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:init_t >tclass=dir >Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied >{ search } for name=494 dev=proc ino=32374786 >scontext=system_u:system_r:kernel_t >tcontext=system_u:system_r:initrc_t tclass=dir >Apr 30 13:27:06 fedora kernel: audit(1114867595.180:0): avc: denied >{ search } for name=545 dev=proc ino=35717122 >scontext=system_u:system_r:kernel_t >tcontext=system_u:system_r:hotplug_t tclass=dir > >and > >Apr 30 13:27:08 fedora kernel: ohci1394: fw-host0: OHCI-1394 1.0 >(PCI): IRQ=[11] MMIO=[ed100000-ed1007ff] Max Packet=[2048] >Apr 30 13:27:08 fedora kernel: audit(1114867609.739:0): avc: denied >{ getattr } for path=/etc/hotplug dev=hda2 ino=4472955 >scontext=system_u:system_r:insmod_t >tcontext=system_u:object_r:hotplug_etc_t tclass=dir >Apr 30 13:27:09 fedora kernel: audit(1114867609.739:0): avc: denied >{ search } for name=hotplug dev=hda2 ino=4472955 >scontext=system_u:system_r:insmod_t >tcontext=system_u:object_r:hotplug_etc_t tclass=dir > >and >Apr 30 13:27:10 fedora kernel: audit(1114892828.091:0): avc: denied >{ execute } for name=auto.net dev=hda2 ino=4474546 >scontext=system_u:system_r:initrc_t >tcontext=system_u:object_r:automount_etc_t tclass=file >Apr 30 13:27:10 fedora kernel: audit(1114892828.595:0): avc: denied >{ write } for name=/ dev=hda2 ino=2 >scontext=system_u:system_r:automount_t >tcontext=system_u:object_r:root_t tclass=dir >Apr 30 13:27:10 fedora kernel: audit(1114892828.677:0): avc: denied >{ dac_override } for capability=1 >scontext=system_u:system_r:automount_t >tcontext=system_u:system_r:automount_t tclass=capability >Apr 30 13:27:10 fedora kernel: audit(1114892828.787:0): avc: denied >{ write } for name=/ dev=hda2 ino=2 >scontext=system_u:system_r:automount_t >tcontext=system_u:object_r:root_t tclass=dir > > >Sorry if these are already fixed. > tom > > > Added a bunch of fixes, Thanks. -- From dwalsh at redhat.com Mon May 2 15:11:59 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 May 2005 11:11:59 -0400 Subject: snmpd proc monitoring problem In-Reply-To: References: <42728D7C.9040302@redhat.com> Message-ID: <4276433F.9080600@redhat.com> Carlos Pastorino wrote: >On 4/29/05, Daniel J Walsh wrote: > > >>Carlos Pastorino wrote: >> >> >> >>>Hello, >>> >>>I've inserted the following line on my /etc/snmpd.conf file: >>> >>> proc sshd >>> >>>Then I executed the following command: >>> >>>snmpwalk -On -v2c -c public localhost .1.3.6.1.4.1.2021.2.1 >>> >>>and got the answer: >>> >>>.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 >>>.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd >>>.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 1 >>>.1.3.6.1.4.1.2021.2.1.101.1 = STRING: No sshd process running. >>>.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.103.1 = STRING: >>> >>>But, if I execute the command below: >>> >>>setenforce 0 >>> >>>I get the correct answer: >>> >>>.1.3.6.1.4.1.2021.2.1.1.1 = INTEGER: 1 >>>.1.3.6.1.4.1.2021.2.1.2.1 = STRING: sshd >>>.1.3.6.1.4.1.2021.2.1.3.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.4.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.5.1 = INTEGER: 2 >>>.1.3.6.1.4.1.2021.2.1.100.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.101.1 = STRING: >>>.1.3.6.1.4.1.2021.2.1.102.1 = INTEGER: 0 >>>.1.3.6.1.4.1.2021.2.1.103.1 = STRING: >>> >>>The problem is, nothing shows up on /var/log/messages to allow me to >>>figure out how to tweak the >>>/etc/selinux/targeted/src/policy/domains/program/snmpd.te file. >>> >>>Any hints? >>> >>>Regards, >>> >>>Carlos >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>> >>> >>You are being bitten by a dontaudit rule. To disable dont audits >>cd /etc/selinux/targeted/src/policy >> >>make enableaudit >>make load >> >>The culprit line is the following. >> >>dontaudit snmpd_t domain:dir { getattr search }; >> >>If you change this to allow you will get further. >> >>-- >> >> > >Hi Daniel, > >On the snmpd.te file, I've changed the line above to: > >allow snmpd_t domain:dir { getattr search }; > >Then I executed "make load", and got the error: > >assertion on line 21719 violated by allow snmpd_t unconfined_t:dir { >getattr search }; >make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > >Now I'm stuck again :) mainly because I don't know if it's a good idea >to change the rule on line 21719, namely: > ># Confined domains must never see unconfined domain's /proc/pid entries. >neverallow { domain -unrestricted } unconfined_t:dir { getattr search }; > >Any advices? > >Many thanks, > >Carlos > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > typeattribute snmbt_t unristricted; Will get you beyond this. Dan -- From lfarkas at bppiac.hu Mon May 2 15:29:25 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 02 May 2005 17:29:25 +0200 Subject: nagios_log_t missing In-Reply-To: <426FA73A.1070609@redhat.com> References: <426E4937.7000604@bppiac.hu> <426E5AC7.2020703@redhat.com> <426F599D.4000506@bppiac.hu> <426FA73A.1070609@redhat.com> Message-ID: <42764755.2090502@bppiac.hu> Daniel J Walsh wrote: > Farkas Levente wrote: > >> Daniel J Walsh wrote: >> >>> Farkas Levente wrote: >>> >>>> hi, >>>> there is a nagios_log_t and used in nagios.fc but never defined >>>> (missing). so when we try to apply it we got these errors: >>>> --------------------------------------------- >>>> # chcon -R -t nagios_log_t /var/log/nagios >>>> chcon: failed to change context of /var/log/nagios to >>>> system_u:object_r:nagios_log_t: Invalid argument >>>> chcon: failed to change context of /var/log/nagios/rw to >>>> system_u:object_r:nagios_log_t: Invalid argument >>>> chcon: failed to change context of /var/log/nagios/archives to >>>> system_u:object_r:nagios_log_t: Invalid argument >>>> chcon: failed to change context of /var/log/nagios/.bash_history to >>>> user_u:object_r:nagios_log_t: Invalid argument >>>> --------------------------------------------- >>>> how can i fix it? >>>> dan could you create updated rpms which fix it in >>>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) >>>> yours. >>>> >>> nagios policy is not used in RHEL4. It should run unconfined_t. We >>> are only supporting the subset of network daemons in targeted policy. >>> >>> Using strict or other policies in RHEL4 requires a separate support >>> contract, professional services engagement. >> >> >> >> ok. i only think that if nagios_log_t used in the current >> selinux-policy-targeted than (in nagios.fc) than it should have to be >> defined also. but it's definition currently missing from >> selinux-policy-targeted, which is imho a bug. that's what i'd like to >> report. > > > We do not strip out fc files that we do not support. The way the make > file and hence the RPM works is it looks for *.te files in the > domains/program directory and uses those names to choose the > file_context files. We want to use the same policy source pool to > supoort targeted, strict, mls ... policy. And therefore get the best > bang for the buck from the open source community. So think of the > policy-src files like you do kernel sources. Just because there is > stuff in there does not mean we support them. the question what does the 'support' means? ie. in the kernel source there are unused part (ie. not compiled in the current kernel), but you can recompile it so you can use that part to. which means the source are coherent and there is not any reference to undefine type. in this case nagios.fc refere to a type nagios_log_t which is not defined anywhere. since you delete all unused .te files why? if you don't strip fc files while do you strip te files? why dont you simple ship with the policy-source and those who would like to use unsupported programs can simple add it (moved from unused to ..) and make reload. that owuld be much better, easier and cleaner the the current case when everyone start to hack their own systems. i'm sure many system used a few unsupported daemons. >> another thing even if nagios run in unconfined_t is ok since the log >> files can be generated and the daemon is running, but the web >> interface of nagios not working since it's try to read it's log files >> under /var/log/nagios which is currently var_log_t (inherited from >> it's parent). so currently i've a few options: >> - add a local.te as: >> allow httpd_sys_script_t var_log_t:dir search; >> allow httpd_sys_script_t var_log_t:file { getattr read }; >> - change /var/log/nagios to httpd_sys_content_t and add only >> allow httpd_sys_script_t var_log_t:dir search; >> - change /var/log/nagios to nagios_log_t and add >> allow httpd_sys_script_t var_log_t:dir search; >> allow httpd_sys_script_t nagios_log_t:file { getattr read }; >> and imho the best solution would be to add this last one to the global >> policy. >> yours. >> > How about adding > chcon -R -t httpd_sys_script_ro_t /var/log/nagios > > Then you don't need to change policy at all still need to add: allow httpd_sys_script_t var_log_t:dir search; -- Levente "Si vis pacem para bellum!" From dwalsh at redhat.com Mon May 2 15:48:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 02 May 2005 11:48:43 -0400 Subject: nagios_log_t missing In-Reply-To: <42764755.2090502@bppiac.hu> References: <426E4937.7000604@bppiac.hu> <426E5AC7.2020703@redhat.com> <426F599D.4000506@bppiac.hu> <426FA73A.1070609@redhat.com> <42764755.2090502@bppiac.hu> Message-ID: <42764BDB.4070904@redhat.com> Farkas Levente wrote: > Daniel J Walsh wrote: > >> Farkas Levente wrote: >> >>> Daniel J Walsh wrote: >>> >>>> Farkas Levente wrote: >>>> >>>>> hi, >>>>> there is a nagios_log_t and used in nagios.fc but never defined >>>>> (missing). so when we try to apply it we got these errors: >>>>> --------------------------------------------- >>>>> # chcon -R -t nagios_log_t /var/log/nagios >>>>> chcon: failed to change context of /var/log/nagios to >>>>> system_u:object_r:nagios_log_t: Invalid argument >>>>> chcon: failed to change context of /var/log/nagios/rw to >>>>> system_u:object_r:nagios_log_t: Invalid argument >>>>> chcon: failed to change context of /var/log/nagios/archives to >>>>> system_u:object_r:nagios_log_t: Invalid argument >>>>> chcon: failed to change context of /var/log/nagios/.bash_history >>>>> to user_u:object_r:nagios_log_t: Invalid argument >>>>> --------------------------------------------- >>>>> how can i fix it? >>>>> dan could you create updated rpms which fix it in >>>>> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/ ?:-) >>>>> yours. >>>>> >>>> nagios policy is not used in RHEL4. It should run unconfined_t. >>>> We are only supporting the subset of network daemons in targeted >>>> policy. >>>> >>>> Using strict or other policies in RHEL4 requires a separate support >>>> contract, professional services engagement. >>> >>> >>> >>> >>> ok. i only think that if nagios_log_t used in the current >>> selinux-policy-targeted than (in nagios.fc) than it should have to >>> be defined also. but it's definition currently missing from >>> selinux-policy-targeted, which is imho a bug. that's what i'd like >>> to report. >> >> >> >> We do not strip out fc files that we do not support. The way the >> make file and hence the RPM works is it looks for *.te files in the >> domains/program directory and uses those names to choose the >> file_context files. We want to use the same policy source pool to >> supoort targeted, strict, mls ... policy. And therefore get the best >> bang for the buck from the open source community. So think of the >> policy-src files like you do kernel sources. Just because there is >> stuff in there does not mean we support them. > > > the question what does the 'support' means? ie. in the kernel source > there are unused part (ie. not compiled in the current kernel), but > you can recompile it so you can use that part to. which means the > source are coherent and there is not any reference to undefine type. > in this case nagios.fc refere to a type nagios_log_t which is not > defined anywhere. since you delete all unused .te files why? if you > don't strip fc files while do you strip te files? why dont you simple > ship with the policy-source and those who would like to use > unsupported programs can simple add it (moved from unused to ..) and > make reload. that owuld be much better, easier and cleaner the the > current case when everyone start to hack their own systems. i'm sure > many system used a few unsupported daemons. Because I don't want people moving arbitrary files into targeted policy. That is why they are removed. If I left them there, people would go into the unused directory move a file into place rebuild and things would blow up. The policy files are setup for the default of strict policy. Targeted policy is built differently. (So is MLS). The bug is that I have not removed the FC files. Support means whether I pay attention to a bug report in bugzilla or not. Same with kernel. Just because their is a configuration capability in the kernel sources, does not mean that if you build it an arbitrary way, your bugzilla is going to get action. Now when we get to RHEL support their it is even more formal. > >>> another thing even if nagios run in unconfined_t is ok since the log >>> files can be generated and the daemon is running, but the web >>> interface of nagios not working since it's try to read it's log >>> files under /var/log/nagios which is currently var_log_t (inherited >>> from it's parent). so currently i've a few options: >>> - add a local.te as: >>> allow httpd_sys_script_t var_log_t:dir search; >>> allow httpd_sys_script_t var_log_t:file { getattr read }; >>> - change /var/log/nagios to httpd_sys_content_t and add only >>> allow httpd_sys_script_t var_log_t:dir search; >>> - change /var/log/nagios to nagios_log_t and add >>> allow httpd_sys_script_t var_log_t:dir search; >>> allow httpd_sys_script_t nagios_log_t:file { getattr read }; >>> and imho the best solution would be to add this last one to the >>> global policy. >>> yours. >>> >> How about adding >> chcon -R -t httpd_sys_script_ro_t /var/log/nagios >> >> Then you don't need to change policy at all > > > still need to add: > allow httpd_sys_script_t var_log_t:dir search; > Probably not a good idea to give this in general. You would need to add this to your local policy or run your script as httpd_unconfinet_script_t. -- From steve at atc-nycorp.com Mon May 2 22:01:14 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Mon, 2 May 2005 18:01:14 -0400 Subject: make relabel > restorecon Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0D1@server20.inside.oracorp.com> I have a file /etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc that contains the following line only: /tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t When I do # make reload and then # make relabel the system correctly labels the file and adds the above line to the master file_contexts file. However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo the file's type reverts to default_t Any ideas on why this is happening? Thanks, - Steve Brueckner, ATC-NY From dwalsh at redhat.com Tue May 3 04:05:29 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 May 2005 00:05:29 -0400 Subject: make relabel > restorecon In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0D1@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0D1@server20.inside.oracorp.com> Message-ID: <4276F889.8040305@redhat.com> Steve Brueckner wrote: >I have a file >/etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc that >contains the following line only: > >/tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t > >When I do # make reload and then # make relabel the system correctly labels >the file and adds the above line to the master file_contexts file. > >However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo the >file's type reverts to default_t > >Any ideas on why this is happening? > > I take it you have a domains/program/tspi_dillo.te file? grep dillo /etc/selinux/targeted/context/files/* >Thanks, > > - Steve Brueckner, ATC-NY > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From steve at atc-nycorp.com Tue May 3 14:03:30 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Tue, 3 May 2005 10:03:30 -0400 Subject: make relabel > restorecon Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0D3@server20.inside.oracorp.com> Daniel J Walsh wrote: > Steve Brueckner wrote: > >> I have a file >> /etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc >> that contains the following line only: >> >> /tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t >> >> When I do # make reload and then # make relabel the system correctly >> labels the file and adds the above line to the master file_contexts >> file. >> >> However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo >> the file's type reverts to default_t >> >> Any ideas on why this is happening? >> >> > I take it you have a domains/program/tspi_dillo.te file? > > grep dillo /etc/selinux/targeted/context/files/* > Yes, I have /etc/selinux/targeted/src/policy/domains/program/tspi_dillo.te which declares the tspi_dillo_exec_t. However, I think your grep showed me where the problem lies. There are two file_contexts files: /etc/selinux/targeted/src/policy/file_contexts/file_contexts /etc/selinux/targeted/context/files/file_contexts And a diff shows that the former has the context for dillo and the latter does not. I was apparently mistaken earlier when I said that the "master" file_contexts file contains the line in question. So my question now becomes how does the former get updated? I've done make reload and make relabel but it seems that neither is updating /etc/selinux/targeted/context/files/file_contexts. Thanks, - Steve Brueckner, ATC-NY From dwalsh at redhat.com Tue May 3 14:07:37 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 May 2005 10:07:37 -0400 Subject: make relabel > restorecon In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0D3@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0D3@server20.inside.oracorp.com> Message-ID: <427785A9.8080403@redhat.com> Steve Brueckner wrote: >Daniel J Walsh wrote: > > >>Steve Brueckner wrote: >> >> >> >>>I have a file >>>/etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc >>>that contains the following line only: >>> >>>/tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t >>> >>>When I do # make reload and then # make relabel the system correctly >>>labels the file and adds the above line to the master file_contexts >>>file. >>> >>>However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo >>>the file's type reverts to default_t >>> >>>Any ideas on why this is happening? >>> >>> >>> >>> >>I take it you have a domains/program/tspi_dillo.te file? >> >>grep dillo /etc/selinux/targeted/context/files/* >> >> >> > >Yes, I have /etc/selinux/targeted/src/policy/domains/program/tspi_dillo.te >which declares the tspi_dillo_exec_t. > >However, I think your grep showed me where the problem lies. There are two >file_contexts files: >/etc/selinux/targeted/src/policy/file_contexts/file_contexts >/etc/selinux/targeted/context/files/file_contexts > >And a diff shows that the former has the context for dillo and the latter >does not. I was apparently mistaken earlier when I said that the "master" >file_contexts file contains the line in question. > >So my question now becomes how does the former get updated? I've done make >reload and make relabel but it seems that neither is updating >/etc/selinux/targeted/context/files/file_contexts. > >Thanks, > > - Steve Brueckner, ATC-NY > > That is strange. Make reload should have copied the your file_context over. Try make -W users load See if the file_context gets replaced. Any chance of clock skew on your machine. -- From selinux at gmail.com Tue May 3 14:17:45 2005 From: selinux at gmail.com (Tom London) Date: Tue, 3 May 2005 07:17:45 -0700 Subject: selinux-policy-strict-1.23.14-2 - glitches... Message-ID: <4c4ba15305050307177a61712a@mail.gmail.com> Running strict/enforcing, latest rawhide. The following crop up with today's updates: 0. Early boot denials: May 3 06:42:12 fedora kernel: security: 3 users, 6 roles, 1333 types, 63 boolsMay 3 06:42:12 fedora kernel: security: 55 classes, 342123 rules May 3 06:42:12 fedora kernel: SELinux: Completing initialization. May 3 06:42:12 fedora kernel: SELinux: Setting up existing superblocks. May 3 06:42:12 fedora kernel: audit(1115102485.415:0): avc: denied { read } for name=proc dev=hda2 ino=3407873 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir May 3 06:42:12 fedora kernel: audit(1115102485.416:0): avc: denied { search } for name=/ dev=hda2 ino=2 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=dir May 3 06:42:12 fedora last message repeated 3 times May 3 06:42:12 fedora kernel: SELinux: initialized (dev hda2, type ext3), uses xattr Also, init seems to be doing a PID scan: May 3 06:42:13 fedora kernel: audit(1115102490.729:0): avc: denied { read } for name=stat dev=proc ino=65550 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:init_t tclass=file May 3 06:42:13 fedora kernel: audit(1115102490.730:0): avc: denied { read } for name=stat dev=proc ino=31916046 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:init_t tclass=file May 3 06:42:13 fedora kernel: audit(1115102490.730:0): avc: denied { read } for name=stat dev=proc ino=32505870 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:initrc_t tclass=file May 3 06:42:13 fedora kernel: audit(1115102490.730:0): avc: denied { read } for name=stat dev=proc ino=36175886 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:hotplug_t tclass=file <<>> 1. privoxy is non functional: May 3 06:42:53 fedora kernel: audit(1115127773.695:0): avc: denied { name_bind } for src=8118 scontext=system_u:system_r:privoxy_t tcontext=system_u:object_r:http_cache_port_t tclass=tcp_socket so suggest adding allow privoxy_t http_cache_port_t:tcp_socket name_bind; to privoxy.te 2. trouble starting ptal. I can't tell if this is a missing transition to ptal_t, or just a missing entry in net_contexts. Help? May 3 06:42:21 fedora kernel: audit(1115127741.848:0): avc: denied { name_bind } for src=5703 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5704 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5705 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5706 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5707 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5708 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5709 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5710 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5711 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5712 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5713 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5714 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora kernel: audit(1115127741.849:0): avc: denied { name_bind } for src=5715 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 3 06:42:21 fedora ptal-photod: ptal-photod(mlc:usb:PSC_900_Series): bind(tcpPort=5729) failed, errno=13! Also: May 3 06:42:22 fedora kernel: audit(1115127741.921:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:25 fedora ptal-mlcd: ERROR at ExMgr.cpp:2525, dev=, pid=2372, e=1, t=1115127745 Couldn't find device! May 3 06:42:25 fedora kernel: audit(1115127745.660:0): avc: denied { write } for name=001 dev=usbfs ino=4489 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 3 06:42:25 fedora kernel: audit(1115127745.660:0): avc: denied { write } for name=001 dev=usbfs ino=4489 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 3 06:42:25 fedora kernel: audit(1115127745.660:0): avc: denied { write } for name=001 dev=usbfs ino=4473 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 3 06:42:25 fedora kernel: audit(1115127745.661:0): avc: denied { write } for name=001 dev=usbfs ino=4473 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 3 06:42:25 fedora kernel: audit(1115127745.661:0): avc: denied { write } for name=001 dev=usbfs ino=4457 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 3 06:42:25 fedora kernel: audit(1115127745.661:0): avc: denied { write } for name=001 dev=usbfs ino=4457 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file 3. issues with fifo files: May 3 06:42:14 fedora kernel: IPv6 over IPv4 tunneling driver May 3 06:42:14 fedora kernel: audit(1115127718.038:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:14 fedora kernel: audit(1115127718.041:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:14 fedora kernel: audit(1115127718.256:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:14 fedora kernel: audit(1115127718.260:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:14 fedora kernel: ACPI: Power Button (FF) [PWRF] <<>> May 3 06:42:50 fedora ntpd[2472]: kernel time sync status 0040 May 3 06:42:50 fedora kernel: audit(1115127770.407:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:50 fedora ntpd[2472]: frequency initialized 67.355 PPM from /var/lib/ntp/drift May 3 06:42:50 fedora ntpd[2472]: configure: keyword "authenticate" unknown, line ignored May 3 06:42:51 fedora kernel: audit(1115127771.070:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file <<>> May 3 06:42:59 fedora kernel: audit(1115127779.773:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file May 3 06:42:59 fedora kernel: audit(1115127779.800:0): avc: denied { write } for name=rhgb-console dev=ramfs ino=5658 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:ramfs_t tclass=fifo_file 4. ddclient (fix to support http_port_t): May 3 06:42:52 fedora kernel: audit(1115127772.664:0): avc: denied { name_connect } for dest=80 scontext=system_u:system_r:ddclient_t tcontext=system_u:object_r:http_port_t tclass=tcp_socket or allow ddclient_t http_port_t:tcp_socket name_connect; 5. su denial: May 3 06:44:04 fedora su(pam_unix)[3241]: session opened for user root by tbl(uid=500) May 3 06:44:17 fedora kernel: audit(1115127857.306:0): avc: denied { unix_read unix_write } for key=1592234044 scontext=user_u:user_r:user_t tcontext=system_u:system_r:xdm_t tclass=sem Does allow user_t xdm_t:sem { unix_read unix_write }; make sense? Thanks! tom -- Tom London From steve at atc-nycorp.com Tue May 3 14:23:54 2005 From: steve at atc-nycorp.com (Steve Brueckner) Date: Tue, 3 May 2005 10:23:54 -0400 Subject: make relabel > restorecon Message-ID: <60D45469A1AAD311A04C009027B6BF6804FCF0D5@server20.inside.oracorp.com> Daniel J Walsh wrote: > Steve Brueckner wrote: >> Daniel J Walsh wrote: >>> Steve Brueckner wrote: >>>> I have a file >>>> /etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc >>>> that contains the following line only: >>>> >>>> /tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t >>>> >>>> When I do # make reload and then # make relabel the system >>>> correctly labels the file and adds the above line to the master >>>> file_contexts file. >>>> >>>> However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo >>>> the file's type reverts to default_t >>>> >>>> Any ideas on why this is happening? >>>> >>> I take it you have a domains/program/tspi_dillo.te file? >>> >>> grep dillo /etc/selinux/targeted/context/files/* >>> >> Yes, I have >> /etc/selinux/targeted/src/policy/domains/program/tspi_dillo.te >> which declares the tspi_dillo_exec_t. >> >> However, I think your grep showed me where the problem lies. There >> are two file_contexts files: >> /etc/selinux/targeted/src/policy/file_contexts/file_contexts >> /etc/selinux/targeted/context/files/file_contexts >> >> And a diff shows that the former has the context for dillo and the >> latter does not. I was apparently mistaken earlier when I said that >> the "master" file_contexts file contains the line in question. >> >> So my question now becomes how does the former get updated? I've >> done make reload and make relabel but it seems that neither is >> updating /etc/selinux/targeted/context/files/file_contexts. >> > That is strange. Make reload should have copied the your > file_context over. > > Try make -W users load > See if the file_context gets replaced. Any chance of clock skew on > your machine. Fooling make into thinking users had been updated did the trick, thanks. My clock, logs, and file times all look fine, so I don't think clock skew is the problem. I am, however, running (last week's) rawhide SELinux and rawhide kernel on an othewise FC3 install, so maybe there's something not meshing in there. Am I correct in thinking that the rawhide SELinux packages are currently being written and tested on FC4? Anyway, I appreciate the assist. - Steve Brueckner, ATC-NY From rhally at mindspring.com Tue May 3 15:58:23 2005 From: rhally at mindspring.com (Richard Hally) Date: Tue, 03 May 2005 11:58:23 -0400 Subject: make relabel > restorecon In-Reply-To: <60D45469A1AAD311A04C009027B6BF6804FCF0D5@server20.inside.oracorp.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0D5@server20.inside.oracorp.com> Message-ID: <42779F9F.70304@mindspring.com> Steve Brueckner wrote: >Daniel J Walsh wrote: > > >>Steve Brueckner wrote: >> >> >>>Daniel J Walsh wrote: >>> >>> >>>>Steve Brueckner wrote: >>>> >>>> >>>>>I have a file >>>>>/etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc >>>>>that contains the following line only: >>>>> >>>>>/tspi/usr/local/bin/dillo -- system_u:object_r:tspi_dillo_exec_t >>>>> >>>>>When I do # make reload and then # make relabel the system >>>>>correctly labels the file and adds the above line to the master >>>>>file_contexts file. >>>>> >>>>>However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo >>>>>the file's type reverts to default_t >>>>> >>>>>Any ideas on why this is happening? >>>>> >>>>> >>>>> >>>>I take it you have a domains/program/tspi_dillo.te file? >>>> >>>>grep dillo /etc/selinux/targeted/context/files/* >>>> >>>> >>>> >>>Yes, I have >>>/etc/selinux/targeted/src/policy/domains/program/tspi_dillo.te >>>which declares the tspi_dillo_exec_t. >>> >>>However, I think your grep showed me where the problem lies. There >>>are two file_contexts files: >>>/etc/selinux/targeted/src/policy/file_contexts/file_contexts >>>/etc/selinux/targeted/context/files/file_contexts >>> >>>And a diff shows that the former has the context for dillo and the >>>latter does not. I was apparently mistaken earlier when I said that >>>the "master" file_contexts file contains the line in question. >>> >>>So my question now becomes how does the former get updated? I've >>>done make reload and make relabel but it seems that neither is >>>updating /etc/selinux/targeted/context/files/file_contexts. >>> >>> >>> >>That is strange. Make reload should have copied the your >>file_context over. >> >>Try make -W users load >>See if the file_context gets replaced. Any chance of clock skew on >>your machine. >> >> > >Fooling make into thinking users had been updated did the trick, thanks. My >clock, logs, and file times all look fine, so I don't think clock skew is >the problem. > >I am, however, running (last week's) rawhide SELinux and rawhide kernel on >an othewise FC3 install, so maybe there's something not meshing in there. >Am I correct in thinking that the rawhide SELinux packages are currently >being written and tested on FC4? > >Anyway, I appreciate the assist. > > - Steve Brueckner, ATC-NY > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > Wasn't there a change a while back(3-4 weeks) to the make file that requires 'make install' to update the file_contexts? I've been using 'make clean install reload' to do a complete update from source policy. Richard Hally From dwalsh at redhat.com Tue May 3 20:28:57 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 03 May 2005 16:28:57 -0400 Subject: make relabel > restorecon In-Reply-To: <42779F9F.70304@mindspring.com> References: <60D45469A1AAD311A04C009027B6BF6804FCF0D5@server20.inside.oracorp.com> <42779F9F.70304@mindspring.com> Message-ID: <4277DF09.10000@redhat.com> Richard Hally wrote: > Steve Brueckner wrote: > >> Daniel J Walsh wrote: >> >> >>> Steve Brueckner wrote: >>> >>> >>>> Daniel J Walsh wrote: >>>> >>>> >>>>> Steve Brueckner wrote: >>>>> >>>>> >>>>>> I have a file >>>>>> /etc/selinux/targeted/src/policy/file_contexts/programs/tspi_dillo.fc >>>>>> >>>>>> that contains the following line only: >>>>>> >>>>>> /tspi/usr/local/bin/dillo -- >>>>>> system_u:object_r:tspi_dillo_exec_t >>>>>> >>>>>> When I do # make reload and then # make relabel the system >>>>>> correctly labels the file and adds the above line to the master >>>>>> file_contexts file. >>>>>> However, if I then run # /sbin/restorecon /tspi/usr/local/bin/dillo >>>>>> the file's type reverts to default_t >>>>>> >>>>>> Any ideas on why this is happening? >>>>>> >>>>>> >>>>> >>>>> I take it you have a domains/program/tspi_dillo.te file? >>>>> >>>>> grep dillo /etc/selinux/targeted/context/files/* >>>>> >>>>> >>>> >>>> Yes, I have >>>> /etc/selinux/targeted/src/policy/domains/program/tspi_dillo.te >>>> which declares the tspi_dillo_exec_t. >>>> >>>> However, I think your grep showed me where the problem lies. There >>>> are two file_contexts files: >>>> /etc/selinux/targeted/src/policy/file_contexts/file_contexts >>>> /etc/selinux/targeted/context/files/file_contexts >>>> And a diff shows that the former has the context for dillo and the >>>> latter does not. I was apparently mistaken earlier when I said that >>>> the "master" file_contexts file contains the line in question. >>>> >>>> So my question now becomes how does the former get updated? I've >>>> done make reload and make relabel but it seems that neither is >>>> updating /etc/selinux/targeted/context/files/file_contexts. >>>> >>>> >>> >>> That is strange. Make reload should have copied the your >>> file_context over. >>> Try make -W users load >>> See if the file_context gets replaced. Any chance of clock skew on >>> your machine. >>> >> >> >> Fooling make into thinking users had been updated did the trick, >> thanks. My >> clock, logs, and file times all look fine, so I don't think clock >> skew is >> the problem. >> >> I am, however, running (last week's) rawhide SELinux and rawhide >> kernel on >> an othewise FC3 install, so maybe there's something not meshing in >> there. >> Am I correct in thinking that the rawhide SELinux packages are currently >> being written and tested on FC4? >> >> Anyway, I appreciate the assist. >> >> - Steve Brueckner, ATC-NY >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> > Wasn't there a change a while back(3-4 weeks) to the make file that > requires 'make install' to update the file_contexts? I've been using > 'make clean install reload' to do a complete update from source policy. > > Richard Hally > Shouldn't have to. The goal was to never do a make install since this will blow away any user customizations. Dan -- From romttrom at ybb.ne.jp Wed May 4 04:59:43 2005 From: romttrom at ybb.ne.jp (Yoshihiro Totaka) Date: Wed, 04 May 2005 13:59:43 +0900 Subject: awstats In-Reply-To: <426D5B23.4060403@bppiac.hu> References: <426D5B23.4060403@bppiac.hu> Message-ID: <427856BF.9010106@ybb.ne.jp> Hi, I wrote the page and I want it to be polished as well. I don't even understand how dangerous it is to allow allow httpd_sys_script_t devpts_t:chr_file { ioctl read write }; Any help to polish it or make RPM work without modification is appreciated!!! Regards, Farkas Levente wrote: > hi, > we use http://awstats.sourceforge.net/ to generate http web statistics. > in order to generate date there is a hourly cron job which collect the > statistics from the webserver's log file. but this scripts use the same > collection of perl scripts which generates the web pages. > how can i solve it? > i found this description: > http://yanbaru.dyndns.org/linux/fedora2awstats.html > although i don't realy like local.te. > is there any 'default' settings for awstats? > i wish we has some kind of default policy which include rules for > awstats too:-0 > yours. > From selinux at gmail.com Wed May 4 14:43:50 2005 From: selinux at gmail.com (Tom London) Date: Wed, 4 May 2005 07:43:50 -0700 Subject: Problems with today's rawhide (.1284, etc.) Message-ID: <4c4ba153050504074369473f14@mail.gmail.com> Running targeted/enforcing, today's rawhide. After installing today's packages, system fails to boot. Hangs just after starting init, after producing a message like MAKEDEV:mkdir: file exists System will boot with 'enforcing=0'. The log shows many avc denials to tmpfs (below). Did I mess up? tom -------------------------------------------------------- May 4 07:33:23 localhost kernel: audit(1115191953.487:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115191970.159:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:hwclock_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217172.838:0): avc: denied { getattr } for path=/dev/mapper/VolGroup00-LogVol00 dev=tmpfs ino=6442 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:tmpfs_t tclass=blk_file May 4 07:33:23 localhost kernel: audit(1115217172.839:0): avc: denied { read write } for name=VolGroup00-LogVol00 dev=tmpfs ino=6442 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:tmpfs_t tclass=blk_file May 4 07:33:23 localhost kernel: audit(1115217172.839:0): avc: denied { ioctl } for path=/dev/mapper/VolGroup00-LogVol00 dev=tmpfs ino=6442 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:tmpfs_t tclass=blk_file May 4 07:33:23 localhost kernel: audit(1115217177.481:0): avc: denied { write } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217177.481:0): avc: denied { add_name } for name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217177.481:0): avc: denied { create } for name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:23 localhost kernel: audit(1115217177.481:0): avc: denied { setattr } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:23 localhost kernel: audit(1115217178.127:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:klogd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217178.127:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:klogd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:23 localhost kernel: audit(1115217198.206:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217198.206:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:cardmgr_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:23 localhost kernel: audit(1115217200.530:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217200.530:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:23 localhost kernel: audit(1115217200.821:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:23 localhost kernel: audit(1115217202.856:0): avc: denied { read } for name=config dev=dm-0 ino=1275872 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file May 4 07:33:23 localhost kernel: audit(1115217202.856:0): avc: denied { getattr } for path=/etc/selinux/config dev=dm-0 ino=1275872 scontext=system_u:system_r:dhcpc_t tcontext=system_u:object_r:selinux_config_t tclass=file May 4 07:33:29 localhost kernel: audit(1115217209.362:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:portmap_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:29 localhost kernel: audit(1115217209.580:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:29 localhost kernel: audit(1115217209.581:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:31 localhost kernel: audit(1115217211.468:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:howl_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:36 localhost kernel: audit(1115217216.843:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:39 localhost kernel: audit(1115217219.784:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:ntpd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:33:39 localhost kernel: audit(1115217219.784:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:ntpd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:33:41 localhost kernel: audit(1115217221.632:0): avc: denied { read } for name=fd dev=tmpfs ino=2839 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:tmpfs_t tclass=lnk_file May 4 07:34:00 localhost kernel: audit(1115217240.363:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:01 localhost kernel: audit(1115217241.339:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:02 localhost kernel: audit(1115217242.433:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:04 localhost kernel: audit(1115217244.727:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:updfstab_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:04 localhost kernel: audit(1115217244.727:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:updfstab_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:34:09 localhost kernel: audit(1115217249.960:0): avc: denied { read } for name=mapper dev=tmpfs ino=3919 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:09 localhost kernel: audit(1115217249.960:0): avc: denied { getattr } for path=/dev/mapper dev=tmpfs ino=3919 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:09 localhost kernel: audit(1115217249.960:0): avc: denied { getattr } for path=/dev/mapper/VolGroup00-LogVol01 dev=tmpfs ino=6444 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:tmpfs_t tclass=blk_file May 4 07:34:10 localhost kernel: audit(1115217250.223:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:getty_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:34:12 localhost kernel: audit(1115217252.745:0): avc: denied { search } for name=rhgb dev=dm-0 ino=1277513 scontext=system_u:system_r:init_t tcontext=system_u:object_r:mnt_t tclass=dir May 4 07:34:39 localhost kernel: audit(1115217279.531:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:35:00 localhost dbus: avc: denied { send_msg } for msgtype=method_call interface=com.redhat.CupsDriverConfig member=MatchDriver dest=com.redhat.CupsDriverConfig spid=3570 tpid=3058 scontext=user_u:system_r:unconfined_t tcontext=system_u:system_r:cupsd_config_t tclass=dbus May 4 07:35:00 localhost kernel: audit(1115217300.770:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:35:00 localhost kernel: audit(1115217300.770:0): avc: denied { write } for name=log dev=tmpfs ino=6865 scontext=system_u:system_r:system_dbusd_t tcontext=system_u:object_r:tmpfs_t tclass=sock_file May 4 07:35:00 localhost kernel: audit(1115217300.771:0): avc: denied { search } for name=/ dev=tmpfs ino=2832 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:tmpfs_t tclass=dir May 4 07:35:34 localhost kernel: audit(1115217334.071:0): avc: denied { write } for name=cache dev=dm-0 ino=2142136 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=dir May 4 07:35:34 localhost kernel: audit(1115217334.071:0): avc: denied { add_name } for name=foomatic scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=dir May 4 07:35:34 localhost kernel: audit(1115217334.071:0): avc: denied { create } for name=foomatic scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=dir May 4 07:35:34 localhost kernel: audit(1115217334.071:0): avc: denied { create } for name=printconf.pickle scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 4 07:35:34 localhost kernel: audit(1115217334.071:0): avc: denied { getattr } for path=/var/cache/foomatic/printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 4 07:35:34 localhost kernel: audit(1115217334.072:0): avc: denied { write } for path=/var/cache/foomatic/printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 4 07:35:34 localhost dbus: avc: denied { send_msg } for msgtype=method_return dest=:1.5 spid=3058 tpid=3570 scontext=system_u:system_r:cupsd_config_t tcontext=user_u:system_r:unconfined_t tclass=dbus -- Tom London From cochranb at speakeasy.net Thu May 5 01:24:42 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 04 May 2005 21:24:42 -0400 Subject: MySQL 5.0.4 Beta AVC Denied Messages Message-ID: <427975DA.3000705@speakeasy.net> I am getting the following messages while attempting to start the MySQL 5.0.4 server mysqld with SELinux running on Fedora Core 3, and with all current patches applied. I've already tried restorecon -R -v /usr/lib/mysql restorecon -R -v /var/lib/mysql restorecon -v /usr/sbin/mysqld I want to allow MySQL to run. Any suggestions? May 4 21:02:53 rclap kernel: audit(1115254973.641:0): avc: denied { setsched } for pid=3729exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:53 rclap kernel: audit(1115254973.641:0): avc: denied { setsched } for pid=3730exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:53 rclap kernel: audit(1115254973.641:0): avc: denied { setsched } for pid=3731exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:53 rclap kernel: audit(1115254973.642:0): avc: denied { setsched } for pid=3732exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:54 rclap kernel: audit(1115254974.758:0): avc: denied { setsched } for pid=3735exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:54 rclap kernel: audit(1115254974.758:0): avc: denied { setsched } for pid=3736exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:54 rclap kernel: audit(1115254974.758:0): avc: denied { setsched } for pid=3737exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:54 rclap kernel: audit(1115254974.759:0): avc: denied { setsched } for pid=3738exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process May 4 21:02:54 rclap kernel: audit(1115254974.801:0): avc: denied { setsched } for pid=3739exe=/usr/sbin/mysqld scontext=user_u:system_r:mysqld_t tcontext=user_u:system_r:mysqld_t tclass=process y From cra at WPI.EDU Thu May 5 21:05:01 2005 From: cra at WPI.EDU (Chuck R. Anderson) Date: Thu, 5 May 2005 17:05:01 -0400 Subject: "service iptables stop" not working -- /proc/net unreadable Message-ID: <20050505210501.GF30524@angus.ind.WPI.EDU> I had a problem disabling my iptables firewall today, and noticed that /proc/net being unreadable was the cause of "service iptables stop" not working. I have an avc: audit(1115326402.826:0): avc: denied { search } for pid=5818 exe=/bin/tcsh name=net dev=proc ino=-268435434 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:proc_net_t tclass=dir What happened to my /proc? #ls -lZ /proc/net ls: /proc/net: Permission denied #ls -lZd /proc/net ls: /proc/net: Permission denied #ls -lZ /proc|grep net ?--------- ? ? net #ls -l /proc|grep net ?--------- ? ? ? ? ? net This is FC3 with kernel-2.6.11-1.14_FC3 and selinux-policy-targeted-1.17.30-3.1. From walters at redhat.com Thu May 5 21:25:00 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 05 May 2005 17:25:00 -0400 Subject: "service iptables stop" not working -- /proc/net unreadable In-Reply-To: <20050505210501.GF30524@angus.ind.WPI.EDU> References: <20050505210501.GF30524@angus.ind.WPI.EDU> Message-ID: <1115328300.3453.1.camel@nexus.verbum.private> On Thu, 2005-05-05 at 17:05 -0400, Chuck R. Anderson wrote: > I had a problem disabling my iptables firewall today, and noticed that > /proc/net being unreadable was the cause of "service iptables stop" > not working. I have an avc: > > audit(1115326402.826:0): avc: denied { search } for pid=5818 > exe=/bin/tcsh name=net dev=proc ino=-268435434 > scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:proc_net_t tclass=dir It's a bug in the policy. It should allow unconfined_t access to proc_net_t. From hein.coulier at infoco.be Fri May 6 09:20:38 2005 From: hein.coulier at infoco.be (Hein Coulier) Date: Fri, 6 May 2005 11:20:38 +0200 Subject: using selinux to control user access to files Message-ID: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> hi, newby speaking here (totally lost in the selinux labyrinth). What i want to accomplish with selinux is the following : i want to allow different end-users (with different roles) to do something with some files. I'll give you an example : fileA : may be read by roleA and roleB fileB : may only be read by roleB ; audited fileC : may be read and changed by roleB ; audited I read several pdf's, read the o'reilly book, but i seem to be unable to achieve my goal. Help would be appreciated. tia, hecou. From dwalsh at redhat.com Fri May 6 12:04:00 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 06 May 2005 08:04:00 -0400 Subject: using selinux to control user access to files In-Reply-To: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> Message-ID: <427B5D30.50401@redhat.com> Hein Coulier wrote: >hi, newby speaking here (totally lost in the selinux labyrinth). > >What i want to accomplish with selinux is the following : i want to allow >different end-users (with different roles) to do something with some files. >I'll give you an example : > >fileA : may be read by roleA and roleB >fileB : may only be read by roleB ; audited >fileC : may be read and changed by roleB ; audited > >I read several pdf's, read the o'reilly book, but i seem to be unable to >achieve my goal. >Help would be appreciated. > > > You may want to look at ACLs and Auditing rather than SELinux. >tia, hecou. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From sds at tycho.nsa.gov Fri May 6 12:03:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 06 May 2005 08:03:16 -0400 Subject: using selinux to control user access to files In-Reply-To: <427B5D30.50401@redhat.com> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> Message-ID: <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-06 at 08:04 -0400, Daniel J Walsh wrote: > Hein Coulier wrote: > > >hi, newby speaking here (totally lost in the selinux labyrinth). > > > >What i want to accomplish with selinux is the following : i want to allow > >different end-users (with different roles) to do something with some files. > >I'll give you an example : > > > >fileA : may be read by roleA and roleB > >fileB : may only be read by roleB ; audited > >fileC : may be read and changed by roleB ; audited > > > >I read several pdf's, read the o'reilly book, but i seem to be unable to > >achieve my goal. > >Help would be appreciated. > > > > > > > You may want to look at ACLs and Auditing rather than SELinux. ACLs are discretionary, so I don't think that will meet his need. Suggestion: 1) Convert your machine to strict policy (so that you have real user roles and domains), 2) Search the mailing list archives for discussions of how to add a new user role to the policy (e.g. see the full_user_role() macro and domains/user.te). Also, look at the recently added support for a separate security administrator role introduced by Dan. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri May 6 13:19:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 06 May 2005 09:19:24 -0400 Subject: using selinux to control user access to files In-Reply-To: <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <427B6EDC.10709@redhat.com> Stephen Smalley wrote: >On Fri, 2005-05-06 at 08:04 -0400, Daniel J Walsh wrote: > > >>Hein Coulier wrote: >> >> >> >>>hi, newby speaking here (totally lost in the selinux labyrinth). >>> >>>What i want to accomplish with selinux is the following : i want to allow >>>different end-users (with different roles) to do something with some files. >>>I'll give you an example : >>> >>>fileA : may be read by roleA and roleB >>>fileB : may only be read by roleB ; audited >>>fileC : may be read and changed by roleB ; audited >>> >>>I read several pdf's, read the o'reilly book, but i seem to be unable to >>>achieve my goal. >>>Help would be appreciated. >>> >>> >>> >>> >>> >>You may want to look at ACLs and Auditing rather than SELinux. >> >> > >ACLs are discretionary, so I don't think that will meet his need. >Suggestion: >1) Convert your machine to strict policy (so that you have real user >roles and domains), >2) Search the mailing list archives for discussions of how to add a new >user role to the policy (e.g. see the full_user_role() macro and >domains/user.te). Also, look at the recently added support for a >separate security administrator role introduced by Dan. > > > Yes I realize that but handling things like this with MAC is not that easy. Writing policy where different user roles have R, RW,RWX, No read is not a strong suit of MAC. Dan -- From sds at tycho.nsa.gov Fri May 6 13:17:15 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 06 May 2005 09:17:15 -0400 Subject: using selinux to control user access to files In-Reply-To: <427B6EDC.10709@redhat.com> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> Message-ID: <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-06 at 09:19 -0400, Daniel J Walsh wrote: > Yes I realize that but handling things like this with MAC is not that > easy. Writing policy > where different user roles have R, RW,RWX, No read is not a strong suit > of MAC. For specific data files, it should be relatively straightforward; he just needs to instantiate the roles via full_user_role(), define a few new file types for the particular data he wants to restrict, and add specific allow rules and auditallow rules between the new user domains and the new file types. I agree that a higher level language or tool would make life simpler, but the mechanism is certainly capable of supporting the need. -- Stephen Smalley National Security Agency From alex at milivojevic.org Fri May 6 17:06:33 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Fri, 06 May 2005 12:06:33 -0500 Subject: using tmpfs for /tmp and selinux Message-ID: <20050506120633.adcevojr5hc8wss0@www.milivojevic.org> Sorry for posting this outside of corresponding thread for those using threading. I'm new to the list, and found thread in the archives, so couldn't simply hit reply in my mail reader. I've applied changes described to the rc.sysinit (restorecon /tmp), created local.te (allow tmpfile tmpfs_t:filesystem associate;) and reloaded policy. It seems to be working for me on both FC3 and RHEL4. The question I have is, will this patches (to both initscripts and selinux-policy-targeted) be present in U1 for RHEL4? Thanks, Aleksandar Milivojevic ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From mike at navi.cx Sat May 7 12:20:48 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 07 May 2005 13:20:48 +0100 Subject: Is there a SELinux tutorial for ISVs ? References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> Message-ID: On Thu, 28 Apr 2005 11:54:30 -0400, Daniel J Walsh wrote: > Anyways I think we need more discussion on handling third party and user > customization of policy outside of the current make tree stuff. Sorry for posting so late ... one thing I'd also like to see is some formal rules for policy compatibility. For instance, if FC4 ships and says "Shared libraries with text relocations are no longer allowed by default" then this breaks things. If FC5 ships and now you need special tagging to connect to the X server, well .... (I don't know if this has actually happened or not yet but it seems to keep coming up) It may be decided that it's an acceptable price to pay for the additional security, or it may not. I don't think that discussion should happen now. But I think ISVs would feel a lot more secure if this sort of decision appeared not to be arbitrary and if there was some way to plan and work with the OS base policy writers. A basic system could be to have widely adopted (cross-distro) and documented security levels, ie: Level 1: Basic targetted - optin, only affects daemons, no restrictions on anything else Level 2: Targetted + additional restrictions, execshield enabled (ie this is not just an SELinux thing), apps which require special privs must have custom policy Level 3: Strict or something similar to that. This means users can adjust their security level to adapt to what programs they run, and ISVs can say "Minimum Requirements: Level 2 or lower security level". thanks -mike From hein.coulier at infoco.be Mon May 9 11:29:43 2005 From: hein.coulier at infoco.be (Hein Coulier) Date: Mon, 9 May 2005 13:29:43 +0200 Subject: using selinux to control user access to files References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> thx for the feedback Stephen, but i'm still unable to succeed, i'm also getting some strange errors, so perhaps my installed policy isn't a good one to start with : # rpm -qa selinux-policy-targeted-sources selinux-policy-targeted-sources-1.17.30-2.52.1 # rpm -qa|grep -i release redhat-release-4AS-2 What i added to the policy : ############################################################################ ########### # /etc/selinux/targeted/src/policy/file_contexts/program/mytest.fc ############################################################################ ########### /var/hecou/fileA user_u:object_r:typeA_t /var/hecou/fileB user_u:object_r:typeB_t /var/hecou/fileC user_u:object_r:typeC_t ############################################################################ ########### # /etc/selinux/targeted/src/policy/domains/program/mytest.te ############################################################################ ########### # define filetypes type typeA_t, file_type; type typeB_t, file_type; type typeC_t, file_type; # define domains type domainA_t, domain, file_type; type domainB_t, domain, file_type; type domainC_t, domain, file_type; allow domainA_t typeA_t:file r_file_perms; auditallow domainB_t typeB_t:file r_file_perms; auditallow domainC_t typeC_t:file rw_file_perms; # junk to tackle make-errors bool read_default_t true; bool user_rw_usb false; bool user_rw_noexattrfile false; bool user_direct_mouse false; bool user_tcp_server false; bool user_dmesg false; type roleA_crond_t, domain, file_type, sysadmfile; type roleB_crond_t, domain, file_type, sysadmfile; # create roles full_user_role(roleA); full_user_role(roleB); role roleA_r types {domainA_t unconfined_t}; role roleB_r types {domainA_t domainB_t domainC_t unconfined_t}; ############################################################################ ########### # /etc/selinux/targeted/src/policy/users ############################################################################ ########### user userA roles roleA_r; user userB roles roleB_r; remember, my goal was : fileA : may be read by roleA and roleB fileB : may only be read by roleB ; audited fileC : may be read and changed by roleB ; audited and i executed the following actions : DIR="/var/hecou" mkdir ${DIR} ; chmod 777 ${DIR} >${DIR}/fileA ; >${DIR}/fileB ; >${DIR}/fileC ; chmod 666 ${DIR}/* useradd userA -m useradd userB -m the results : - i had to add the 'junk' part to make it 'compile'. It seems to me that the tests on the booleans would be better 'ifdef (user_rw_usb)' instead of 'if (user_rw_usb)', but maybe totaly not getting the picture. I also had to define the roleA_crond_t and roleB_crond_t. - if i test the policy with sepcut, i get a bunch of errors of the form : assertion on line 28135 violated by allow unconfined_t domainA_t:process { fork sigchld sigkill sigstop signull signal ptrace getsched setsched getsession getpgid setpgid getcap setcap share getattr setexec setfscreate noatsecure siginh setrlimit rlimitinh }; - setfiles /etc/selinux/targeted/src/policy/file_contexts/program/mytest.fc /var/hecou returns : setfiles: read 3 specifications setfiles: invalid context user_u:object_r:typeA_t on line number 4 setfiles: invalid context user_u:object_r:typeB_t on line number 5 setfiles: invalid context user_u:object_r:typeC_t on line number 6 i also have a silly question, in a security context (eg user_u:object_r:typeA_t), what is the mening of user_u ? hein ----- Original Message ----- From: "Stephen Smalley" To: "Daniel J Walsh" Cc: "Hein Coulier" ; Sent: Friday, May 06, 2005 3:17 PM Subject: Re: using selinux to control user access to files > > For specific data files, it should be relatively straightforward; he > just needs to instantiate the roles via full_user_role(), define a few > new file types for the particular data he wants to restrict, and add > specific allow rules and auditallow rules between the new user domains > and the new file types. I agree that a higher level language or tool > would make life simpler, but the mechanism is certainly capable of > supporting the need. > > -- > Stephen Smalley > National Security Agency > > From sds at tycho.nsa.gov Mon May 9 12:38:55 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 09 May 2005 08:38:55 -0400 Subject: using selinux to control user access to files In-Reply-To: <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> Message-ID: <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-09 at 13:29 +0200, Hein Coulier wrote: > thx for the feedback Stephen, but i'm still unable to succeed, > i'm also getting some strange errors, so perhaps my installed policy isn't a > good one to start with : > # rpm -qa selinux-policy-targeted-sources > > selinux-policy-targeted-sources-1.17.30-2.52.1 Yes, if you want to have user roles and domains, you need strict policy. targeted policy lacks the infrastructure for user roles and domains; it only knows about daemons. > # rpm -qa|grep -i release > > redhat-release-4AS-2 Ah, unfortunately RHEL4 didn't ship with a strict policy included. You can take it up with your Red Hat support person, or grab the selinux-policy-strict* packages from Fedora Core (in the latter case, you will likely want to also upgrade your other SELinux-related packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, checkpolicy, policycoreutils, setools, setools-gui). > # define domains > > type domainA_t, domain, file_type; > > type domainB_t, domain, file_type; > > type domainC_t, domain, file_type; full_user_role() defines both a role and an initial domain for the role using the same prefix, so you don't need to separately define the domains here. Also, 'file_type' doesn't belong on domains. Domains are for processes, file types are for files. > allow domainA_t typeA_t:file r_file_perms; > > auditallow domainB_t typeB_t:file r_file_perms; > > auditallow domainC_t typeC_t:file rw_file_perms; You would need allow rules as well for the latter domains; auditallow just says "audit when allowed", so you need both an allow rule and an auditallow rule in order to both allow the action and enable auditing of it when allowed. > # junk to tackle make-errors This is because targeted policy lacks the infrastructure for user domains. > # create roles > > full_user_role(roleA); > > full_user_role(roleB); > > role roleA_r types {domainA_t unconfined_t}; > > role roleB_r types {domainA_t domainB_t domainC_t unconfined_t}; full_user_role(X) should define a X_r role as well as a X_t domain as the initial domain for the role, and authorize the role for the domain. So you don't need to separately define domains and authorize the role for it. E.g. full_user_role(A) would create role A_r and type A_t, and authorize role A_r for A_t. > i also have a silly question, in a security context (eg > user_u:object_r:typeA_t), what is the mening of user_u ? It is a generic user identity used when the SELinux policy does not define a separate user identity for the Linux username. This is useful if you have a large number of users who do not need separation via SELinux, e.g. so you can map all unprivileged users to user_u and not need to maintain them in the policy individually. -- Stephen Smalley National Security Agency From hein.coulier at infoco.be Mon May 9 14:30:43 2005 From: hein.coulier at infoco.be (Hein Coulier) Date: Mon, 9 May 2005 16:30:43 +0200 Subject: using selinux to control user access to files References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> > > Yes, if you want to have user roles and domains, you need strict policy. > targeted policy lacks the infrastructure for user roles and domains; it > only knows about daemons. > > > Ah, unfortunately RHEL4 didn't ship with a strict policy included. > You can take it up with your Red Hat support person, or grab the > selinux-policy-strict* packages from Fedora Core (in the latter case, > you will likely want to also upgrade your other SELinux-related > packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, > checkpolicy, policycoreutils, setools, setools-gui). > That is a bummer ! I read that redhat (even in rhel5) is not supporting the strict policy. Since we're running a lot of 3rd party products (oracle, websphere, openview, controlm, ...) , i doubt that managment will be willing to take the risk of running unsupported. I'll have to address my supperiors, but i fear it might be over-and-out for selinux. Neverrtheless, thanks for the support and your time ! From Valdis.Kletnieks at vt.edu Mon May 9 15:25:09 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 May 2005 11:25:09 -0400 Subject: using selinux to control user access to files In-Reply-To: Your message of "Mon, 09 May 2005 16:30:43 +0200." <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> Message-ID: <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> On Mon, 09 May 2005 16:30:43 +0200, Hein Coulier said: > That is a bummer ! I read that redhat (even in rhel5) is not supporting the > strict policy. Since we're running a lot of 3rd party products (oracle, > websphere, openview, controlm, ...) , i doubt that managment will be willing > to take the risk of running unsupported. > > I'll have to address my supperiors, but i fear it might be over-and-out for > selinux. I remember seeing a statement on a RedHat page that their "lack of support" would basically mean "replicate your issue with enforcing=0 and then we'll talk", so things may not be as bad as all that... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon May 9 15:31:20 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 May 2005 11:31:20 -0400 Subject: using selinux to control user access to files In-Reply-To: Your message of "Mon, 09 May 2005 08:38:55 EDT." <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200505091531.j49FVK8i015368@turing-police.cc.vt.edu> On Mon, 09 May 2005 08:38:55 EDT, Stephen Smalley said: > On Mon, 2005-05-09 at 13:29 +0200, Hein Coulier wrote: > Ah, unfortunately RHEL4 didn't ship with a strict policy included. > You can take it up with your Red Hat support person, or grab the > selinux-policy-strict* packages from Fedora Core (in the latter case, > you will likely want to also upgrade your other SELinux-related > packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, > checkpolicy, policycoreutils, setools, setools-gui). Modulo the support issues, there any known gotchas of running a basically RHEL4 box with the userspace pieces from FC4 (missing kernel support, etc), or is it something that will pretty much work? (And yes, I know that getting things working like Apache serving up PHP scripts that call mysql are *my* problem - I'm more worried about things sneaking up and biting me on the tookus while I'm busy trying to get that stuff working...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Mon May 9 15:32:26 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 May 2005 11:32:26 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> Message-ID: <427F828A.1020007@redhat.com> Mike Hearn wrote: >On Thu, 28 Apr 2005 11:54:30 -0400, Daniel J Walsh wrote: > > >>Anyways I think we need more discussion on handling third party and user >>customization of policy outside of the current make tree stuff. >> >> > >Sorry for posting so late ... one thing I'd also like to see is some >formal rules for policy compatibility. For instance, if FC4 ships and says >"Shared libraries with text relocations are no longer allowed by default" >then this breaks things. If FC5 ships and now you need special tagging to >connect to the X server, well .... > > > The goal is to not change the fundamental securitylevel on policy/kernel updates. If it does there is a bug in policy. Now we will be adding additional booleans in order to allow users to increase the securitylevel. So if a kernel gets added to a shipping OS (FC3/RHEL4) that supports an additional access check, we need to allow this by default. Same goes with adding additional policy rules. For example, I am trying to update the FC3/RHEL4 targeted policy with the improvements made in rawhide. Any new booleans need to default to true. >(I don't know if this has actually happened or not yet but it seems to >keep coming up) > >It may be decided that it's an acceptable price to pay for the additional >security, or it may not. I don't think that discussion should happen >now. But I think ISVs would feel a lot more secure if this sort of >decision appeared not to be arbitrary and if there was some way to plan >and work with the OS base policy writers. > >A basic system could be to have widely adopted (cross-distro) and >documented security levels, ie: > >Level 1: Basic targetted - optin, only affects daemons, no restrictions > on anything else > >Level 2: Targetted + additional restrictions, execshield enabled (ie > this is not just an SELinux thing), apps which require special > privs must have custom policy > > > This is what booleans are for. >Level 3: Strict > >or something similar to that. This means users can adjust their security >level to adapt to what programs they run, and ISVs can say "Minimum >Requirements: Level 2 or lower security level". > >thanks -mike > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From emf at obfuscation.org Mon May 9 15:36:08 2005 From: emf at obfuscation.org (Erik Fichtner) Date: Mon, 9 May 2005 08:36:08 -0700 Subject: using selinux to control user access to files In-Reply-To: <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> Message-ID: <20050509153607.GM17111@obfuscation.org> On Mon, May 09, 2005 at 11:25:09AM -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 09 May 2005 16:30:43 +0200, Hein Coulier said: > > > That is a bummer ! I read that redhat (even in rhel5) is not supporting the > > strict policy. Since we're running a lot of 3rd party products (oracle, > > websphere, openview, controlm, ...) , i doubt that managment will be willing > > to take the risk of running unsupported. > > > > I'll have to address my supperiors, but i fear it might be over-and-out for > > selinux. > > I remember seeing a statement on a RedHat page that their "lack of support" would > basically mean "replicate your issue with enforcing=0 and then we'll talk", > so things may not be as bad as all that... And how, exactly, is that not equivilant to a complete lack of support for SElinux policy? If RH ships a .te/.fc pair for a particular application, and it causes an application to break, they should be on the hook for at least explaining why the application isn't functional. Of course, having actually been using strict SE for a while, I completely understand why RH isn't going to do this quickly. Perhaps over time they'll begin to support stock policy, but I fear it will be quite a while. Until they do, though, SElinux is going to remain a toolkit for advanced users who are already the least likely to be compromised, and will do nothing for raising the low-hanging fruit. And if they're not going to support it, they might as well not ship it in RHEL. Once you're running an unsupported configuration, one might as well do it for free. ;) -- Erik Fichtner; Unix Ronin "Mathematics is something best shared between consenting adults in the privacy of their own office" - Adam O'Donnell -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Mon May 9 15:37:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 May 2005 11:37:33 -0400 Subject: using selinux to control user access to files In-Reply-To: <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> Message-ID: <427F83BD.1070909@redhat.com> Hein Coulier wrote: >>Yes, if you want to have user roles and domains, you need strict policy. >>targeted policy lacks the infrastructure for user roles and domains; it >>only knows about daemons. >> >> >>Ah, unfortunately RHEL4 didn't ship with a strict policy included. >>You can take it up with your Red Hat support person, or grab the >>selinux-policy-strict* packages from Fedora Core (in the latter case, >>you will likely want to also upgrade your other SELinux-related >>packages, e.g. libsepol, libsepol-devel, libselinux, libselinux-devel, >>checkpolicy, policycoreutils, setools, setools-gui). >> >> >> > >That is a bummer ! I read that redhat (even in rhel5) is not supporting the >strict policy. Since we're running a lot of 3rd party products (oracle, >websphere, openview, controlm, ...) , i doubt that managment will be willing >to take the risk of running unsupported. > >I'll have to address my supperiors, but i fear it might be over-and-out for >selinux. > >Neverrtheless, thanks for the support and your time ! > > > We are moving targeted policy to cover all non-userspace processes in the future, (RHEL5). I am not sure what you mean unsported. If you have layered products providing their own policy, that will be supported. The thing that is not supported, except through Professional Services, and picking an choosing which policy you will be running and modifying the existing targeted policy. If you modify existing policy so that it breaks the machine, Red Hat Support is going to have a difficult time diagnosing the problem. We just want to avoid that. -- From dwalsh at redhat.com Mon May 9 15:45:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 May 2005 11:45:16 -0400 Subject: using tmpfs for /tmp and selinux In-Reply-To: <20050506120633.adcevojr5hc8wss0@www.milivojevic.org> References: <20050506120633.adcevojr5hc8wss0@www.milivojevic.org> Message-ID: <427F858C.7030101@redhat.com> alex at milivojevic.org wrote: >Sorry for posting this outside of corresponding thread for those using >threading. I'm new to the list, and found thread in the archives, so couldn't >simply hit reply in my mail reader. > >I've applied changes described to the rc.sysinit (restorecon /tmp), created >local.te (allow tmpfile tmpfs_t:filesystem associate;) and reloaded policy. It >seems to be working for me on both FC3 and RHEL4. The question I have is, will >this patches (to both initscripts and selinux-policy-targeted) be present in U1 >for RHEL4? > > Yes >Thanks, >Aleksandar Milivojevic > >---------------------------------------------------------------- >This message was sent using IMP, the Internet Messaging Program. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From himainu-ynakam at miomio.jp Mon May 9 16:11:59 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 09 May 2005 12:11:59 -0400 Subject: CGI on user directory Message-ID: <200505091612.j49GCA6T023592@mms-r00.iijmio.jp> On FC4 test2 with targeted policy(selinux-policy-targeted-1.23.14-2), I tried to run CGI on user home directory. After checked it run on permissive mode, chcon like following. chcon -R system_u:object_r:httpd_sys_script_exec_t ~/public_html/cgi-bin/ I found it does not work on enforcing mode. After I add "allow httpd_suexec_t user_home_t:dir { read };" it worked. Please add it to apache.te --- Yuichi Nakamura From Valdis.Kletnieks at vt.edu Mon May 9 16:53:29 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 May 2005 12:53:29 -0400 Subject: using selinux to control user access to files In-Reply-To: Your message of "Mon, 09 May 2005 08:36:08 PDT." <20050509153607.GM17111@obfuscation.org> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <200505091525.j49FP9Mg014935@turing-police.cc.vt.edu> <20050509153607.GM17111@obfuscation.org> Message-ID: <200505091653.j49GrTlj019240@turing-police.cc.vt.edu> On Mon, 09 May 2005 08:36:08 PDT, Erik Fichtner said: > And if they're not going to support it, they might as well not ship it > in RHEL. Once you're running an unsupported configuration, one might > as well do it for free. ;) Umm.. *every* vendor does this. You post to linux-kernel with an oops that's tainted by the NVidia module, they'll ask you to replicate without that module loaded. I place a hardware support call to Dell, and they want to rule out any add-in PCI cards I've stuck in there myself. The IBM service manuals for an RS/6000 start with (basically) "gut the machine down to a minimum bootable config (ascii display, 4M memory, CD/ROM) and add stuff back till it breaks again". The *important* part is that if I have a *NON*-Selinux problem, I can still get support. The only service call I had to make against RHEL3 was a botch in the aacraid drivers causing a panic on SMP when insmod'ed at system boot. Would have *royally* sucked if they had said "Won't support that config". I don't see what the issue with RedHat saying "We won't answer questions if it looks like an SELinux policy that *you* installed is part of the problem". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Mon May 9 17:19:58 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 May 2005 13:19:58 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <1115655953.4947.6.camel@littlegreen> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> <427F828A.1020007@redhat.com> <1115655953.4947.6.camel@littlegreen> Message-ID: <427F9BBE.6070401@redhat.com> Mike Hearn wrote: >On Mon, 2005-05-09 at 11:32 -0400, Daniel J Walsh wrote: > > >>The goal is to not change the fundamental securitylevel on >>policy/kernel updates [ ... ] Any new booleans need to default to >>true. >> >> > >Hmm, so if I understand correctly then it's actually very possible that >updates/new distro versions will be shipped that deny things that were >previously allowed by default, as long as there is a boolean to switch >them off? > >That sounds like by default every time you upgrade, programs might >break. There must be a better way to deal with this. > > > >>This is what booleans are for. >> >> > >Booleans are just an implementation mechanism, what is needed is some >simple (end-user understandable) means for ISVs to communicate what >permissions their software needs - possibly for old versions of their >software that don't work with new policy. > > No. If you update policy or kernel or any other componant of SELinux, things should work as they did before. Anything that breaks is a bug. >Usability-wise it's not OK to put: > >"This software requires that the SELinux 'foo', 'bar', 'xyz' booleans be >set to false". > > We attempt to set a reasonable relaxness around the policy. So most booleans are set to allow users full access. Advanced users may want to turn up the security. So if a user wants to be able to turn off apache's ability to run cgi scripts. They can set httpd_enable_cgi=0. The default will be allow cgi scripts. >This is asking too much of the user, especially as there should ideally >be some easy way to apply more relaxed policy to an individual program >if it can't cope with the system defaults. Booleans for individual >programs is just too complicated. > > > Agreed, that is why we ship with a relaxed policy where reasonable. >I suggested a level system because (I think) it's reasonable to expect >end users to deal with statements like "This program cannot run with >security level 3 or higher". Whereas it's not reasonable to expect >people to be able to adjust things at a finer level of detail than that. > >thanks -mike > > > -- From dwalsh at redhat.com Mon May 9 17:24:52 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 09 May 2005 13:24:52 -0400 Subject: CGI on user directory In-Reply-To: <200505091612.j49GCA6T023592@mms-r00.iijmio.jp> References: <200505091612.j49GCA6T023592@mms-r00.iijmio.jp> Message-ID: <427F9CE4.5000403@redhat.com> Yuichi Nakamura wrote: >On FC4 test2 with targeted policy(selinux-policy-targeted-1.23.14-2), >I tried to run CGI on user home directory. > >After checked it run on permissive mode, >chcon like following. >chcon -R system_u:object_r:httpd_sys_script_exec_t ~/public_html/cgi-bin/ > >I found it does not work on enforcing mode. >After I add "allow httpd_suexec_t user_home_t:dir { read };" >it worked. >Please add it to apache.te > > What is the context of ~/public_html ? >--- >Yuichi Nakamura > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From mike at navi.cx Mon May 9 16:25:53 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 09 May 2005 17:25:53 +0100 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <427F828A.1020007@redhat.com> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> <427F828A.1020007@redhat.com> Message-ID: <1115655953.4947.6.camel@littlegreen> On Mon, 2005-05-09 at 11:32 -0400, Daniel J Walsh wrote: > The goal is to not change the fundamental securitylevel on > policy/kernel updates [ ... ] Any new booleans need to default to > true. Hmm, so if I understand correctly then it's actually very possible that updates/new distro versions will be shipped that deny things that were previously allowed by default, as long as there is a boolean to switch them off? That sounds like by default every time you upgrade, programs might break. There must be a better way to deal with this. > This is what booleans are for. Booleans are just an implementation mechanism, what is needed is some simple (end-user understandable) means for ISVs to communicate what permissions their software needs - possibly for old versions of their software that don't work with new policy. Usability-wise it's not OK to put: "This software requires that the SELinux 'foo', 'bar', 'xyz' booleans be set to false". This is asking too much of the user, especially as there should ideally be some easy way to apply more relaxed policy to an individual program if it can't cope with the system defaults. Booleans for individual programs is just too complicated. I suggested a level system because (I think) it's reasonable to expect end users to deal with statements like "This program cannot run with security level 3 or higher". Whereas it's not reasonable to expect people to be able to adjust things at a finer level of detail than that. thanks -mike From mike at navi.cx Mon May 9 18:17:02 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 09 May 2005 19:17:02 +0100 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: <427F9BBE.6070401@redhat.com> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> <427F828A.1020007@redhat.com> <1115655953.4947.6.camel@littlegreen> <427F9BBE.6070401@redhat.com> Message-ID: <1115662623.4947.12.camel@littlegreen> On Mon, 2005-05-09 at 13:19 -0400, Daniel J Walsh wrote: > No. If you update policy or kernel or any other componant of SELinux, > things should work as they did before. Anything that breaks is a bug. OK, I misunderstood. That's good to hear, thanks. From Valdis.Kletnieks at vt.edu Mon May 9 19:38:43 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 09 May 2005 15:38:43 -0400 Subject: Is there a SELinux tutorial for ISVs ? In-Reply-To: Your message of "Mon, 09 May 2005 17:25:53 BST." <1115655953.4947.6.camel@littlegreen> References: <426F8B45.8070509@3di.it> <42709B74.4000508@3di.it> <42710736.2020001@redhat.com> <427F828A.1020007@redhat.com> <1115655953.4947.6.camel@littlegreen> Message-ID: <200505091938.j49JchYA025272@turing-police.cc.vt.edu> On Mon, 09 May 2005 17:25:53 BST, Mike Hearn said: > Hmm, so if I understand correctly then it's actually very possible that > updates/new distro versions will be shipped that deny things that were > previously allowed by default, as long as there is a boolean to switch > them off? > > That sounds like by default every time you upgrade, programs might > break. There must be a better way to deal with this. Hey. At least we're giving them a boolean. There's lots of stuff that gets ripped out and breaks stuff (see Documentation/feature-removal-schedule.txt for what's currently on the chopping block. Try installing a recent RedHat system without udev - that requires more work than just a boolean to work around. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From ivg2 at cornell.edu Mon May 9 20:57:06 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 09 May 2005 16:57:06 -0400 Subject: Untrusted content domain In-Reply-To: <1115643881.4319.5.camel@littlegreen> References: <1115643881.4319.5.camel@littlegreen> Message-ID: <1115672226.10218.76.camel@localhost.localdomain> On Mon, 2005-05-09 at 14:04 +0100, Mike Hearn wrote: > Hi Ivan, > > I saw your work on the restricted $HOME SELinux policy and this > interests me a great deal (both with my Codeweavers hat and my > autopackage hat on). > > I'd like to discuss this in a more public forum. Is the Fedora SELinux > list a good place to talk about this sort of lockdown? Ok. Basically my plan is to see how SELinux can be used to confine all applications, including various "desktop" programs - content handlers and such. I dislike how so many things that are completely unrelated are marked ROLE_home_t under /home, and a lot of things are marked ROLE_tmp_t under /tmp. I think there should be better labeling of /home, and /tmp. As part of this, I have suggested various changes, including: - per domain labeling of ORBit sockets in /tmp, so apps don't have to access ROLE_tmp_t - confining various GNOME daemons to make use of this - starting with GConf, and gnome-vfs-daemon - labeling of the various GNOME hidden folders in /home with a more specific context than ROLE_home_t - restricting mozilla and other programs that interact with the web to writing ROLE_untrusted_content_t, as opposed to ROLE_home_t (or something stranger, like ROLE_mozilla_home_t, which is the current behavior) - labeling per/user fonts, and .desktop files, and writing macros to make those work - in the future, content-specific types such as ROLE_media_content_t, that content handlers can access. I have a bug tracking this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155800 although right now this is just one large patch, not nearly where it should be, and unsuitable for merging. I have sent Daniel Walsh several smaller patches to begin implementing this - I need to update the bug to reflect that, since the large patch is a bit out of date. =========================== The untrusted_content part of this is a proposal for a type to be used to mark things downloaded from the Internet that cannot be trusted (hence..untrusted). The idea is that various web browsers, p2p clients, etc. will use this type to store content. Then the user would have to perform some sort of action to interact with this type, to make it accessible by other programs. This would be simply to relabel the file to a different type to begin with, but in the future an automated mechanism could be used to do this, or selinux integration with nautilus could be used to relabel the files. There were also suggestions of a virus scan before such content type would be made accessible. Basically, for starters I just want better labeling of content downloaded by mozilla, because ROLE_mozilla_home_t is just wrong - it's the same type as is used for internal mozilla settings (.mozilla). Then after the type exists, we can figure out what to do with it. To make this work I wanted there to be a folder in /home called downloads or something like that created by default. Then things stored there would automatically get the right type. I suggested that the GNOME team create such a folder, and integrate it with the Places menu, but I don't think there was a lot of interest on the Usability list - in any case people disagree about what it should be called, or whether it's important to have such a folder. I haven't decided what to do about this - currently my patch simply labels downloads and ".*Downloads" as ROLE_untrusted_content_t, if they are present. It also changes the type of files saved by mozilla in tmp to ROLE_untrusted_content_t. From himainu-ynakam at miomio.jp Mon May 9 21:43:09 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 09 May 2005 17:43:09 -0400 Subject: CGI on user directory In-Reply-To: <427F9CE4.5000403@redhat.com> References: <427F9CE4.5000403@redhat.com> Message-ID: <200505092143.j49LhJN9005592@mms-r00.iijmio.jp> Daniel J Walsh wrote: > Yuichi Nakamura wrote: > > >On FC4 test2 with targeted policy(selinux-policy-targeted-1.23.14-2), > >I tried to run CGI on user home directory. > > > >After checked it run on permissive mode, > >chcon like following. > >chcon -R system_u:object_r:httpd_sys_script_exec_t ~/public_html/cgi-bin/ > > > >I found it does not work on enforcing mode. > >After I add "allow httpd_suexec_t user_home_t:dir { read };" > >it worked. > >Please add it to apache.te > What is the context of ~/public_html ? context of public_html is $ ls -Z /home/ynakam/ drwxrwxr-x ynakam ynakam user_u:object_r:httpd_user_content_t public_html Entry in audit.log is type=KERNEL msg=audit(1115674284.731:1699441): avc: denied { search } for name=ynakam dev=hda5 ino=32719 scontext=system_u:system_r:httpd_suexec_t tcontext=user_u:object_r:user_home_dir_t tclass=dir --- Yuichi Nakamura From kwade at redhat.com Tue May 10 03:09:49 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 09 May 2005 20:09:49 -0700 Subject: gpg through apache and php? In-Reply-To: References: Message-ID: <1115694589.6897.48.camel@erato.phig.org> On Sat, 2005-04-30 at 20:30 -0400, brett wrote: > So selinux-policy-targeted-sources is something that lets me change > policy? Yes. > And audit2allow is something that monitors what processes are open and > "allows" them to pass through SELinux? This should explain: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-section-0120.html - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hein.coulier at infoco.be Tue May 10 09:01:29 2005 From: hein.coulier at infoco.be (Hein Coulier) Date: Tue, 10 May 2005 11:01:29 +0200 Subject: using selinux to control user access to files References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <427F83BD.1070909@redhat.com> Message-ID: <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> I based my concern on http://www.redhat.com/magazine/006apr05/features/selinux/ and on the fact that targeted was still the default in redhat 5. Don't get me wrong : i understand why redhat shouldn't be eager to support strict policies. I also don't expect the problems to be generated by redhat, but by my 3rd party products : what if websphere (and our internet shop) stops running, or all our oracle databases in our 250 retail shops ? Even with support, damage in $ would be to big. I hope that in a few years, linux will become like a mainframe with default security, and that it will be an evidence for all vendors that it's their duty to provide the neccessary rules to protect and keep their systems and data available. Best solution for me would be that rbac on userbase could be made available in targeted policy. I think you're all doing a great job, and i still believe selinux is the future. Keep up the good work. hein > > > > > We are moving targeted policy to cover all non-userspace processes in > the future, (RHEL5). I am not > sure what you mean unsported. If you have layered products providing > their own policy, that will be > supported. The thing that is not supported, except through > Professional Services, and picking an choosing > which policy you will be running and modifying the existing targeted > policy. If you modify existing policy so > that it breaks the machine, Red Hat Support is going to have a difficult > time diagnosing the problem. We > just want to avoid that. > > > > -- > > > From dwalsh at redhat.com Tue May 10 10:47:34 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 10 May 2005 06:47:34 -0400 Subject: CGI on user directory In-Reply-To: <200505092143.j49LhJN9005592@mms-r00.iijmio.jp> References: <427F9CE4.5000403@redhat.com> <200505092143.j49LhJN9005592@mms-r00.iijmio.jp> Message-ID: <42809146.8040609@redhat.com> Yuichi Nakamura wrote: >Daniel J Walsh wrote: > > >>Yuichi Nakamura wrote: >> >> >> >>>On FC4 test2 with targeted policy(selinux-policy-targeted-1.23.14-2), >>>I tried to run CGI on user home directory. >>> >>>After checked it run on permissive mode, >>>chcon like following. >>>chcon -R system_u:object_r:httpd_sys_script_exec_t ~/public_html/cgi-bin/ >>> >>>I found it does not work on enforcing mode. >>>After I add "allow httpd_suexec_t user_home_t:dir { read };" >>>it worked. >>>Please add it to apache.te >>> >>> >>What is the context of ~/public_html ? >> >> > >context of public_html is >$ ls -Z /home/ynakam/ >drwxrwxr-x ynakam ynakam user_u:object_r:httpd_user_content_t public_html > >Entry in audit.log is >type=KERNEL msg=audit(1115674284.731:1699441): avc: denied { search } for name=ynakam dev=hda5 ino=32719 scontext=system_u:system_r:httpd_suexec_t tcontext=user_u:object_r:user_home_dir_t tclass=dir > >--- >Yuichi Nakamura > > > Do you have the httpd_enable_homedirs boolean set? I see policy that says: if (httpd_enable_homedirs) { allow { httpd_t httpd_suexec_t httpd_$1_script_t } $1_home_dir_t:dir { getattr search }; } Also your first message said "allow httpd_suexec_t user_home_t:dir { read };" was necessary This error requires "allow httpd_suexec_t user_home_dir_t:dir { search };" -- From himainu-ynakam at miomio.jp Tue May 10 13:13:46 2005 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Tue, 10 May 2005 09:13:46 -0400 Subject: CGI on user directory In-Reply-To: <42809146.8040609@redhat.com> References: <42809146.8040609@redhat.com> Message-ID: <200505101313.j4ADDwJ8025504@mms-r00.iijmio.jp> Daniel J Walsh wrote: > Do you have the httpd_enable_homedirs boolean set? > I see policy that says: > if (httpd_enable_homedirs) { > allow { httpd_t httpd_suexec_t httpd_$1_script_t } $1_home_dir_t:dir { > getattr search }; > } # getsebool httpd_enable_homedirs httpd_enable_homedirs --> active > Also your first message said > "allow httpd_suexec_t user_home_t:dir { read };" > was necessary I'm sorry, it was my mistake. I pasted allow statement in another test;) > This error requires > "allow httpd_suexec_t user_home_dir_t:dir { search };" Yes, "allow httpd_suexec_t user_home_dir_t:dir search;" is correct. > I see policy that says: > if (httpd_enable_homedirs) { > allow { httpd_t httpd_suexec_t httpd_$1_script_t } $1_home_dir_t:dir { > getattr search }; > } This appears in apache_user_domain macro, but it seems that apache_user_domain is not used in targeted policy. --- Yuichi Nakamura From lfarkas at bppiac.hu Tue May 10 13:30:32 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 10 May 2005 15:30:32 +0200 Subject: nss_ldap's tls_key file permission Message-ID: <4280B778.6060006@bppiac.hu> hi, if we'd like to use nss_ldap with tls certificzte files than we have to use a least 644 permission even on the key file. it's not a good security concern. it's better than without tls, but local user still too powerful in this case:-( is there any way to prevent this? i mean to be able to change the file permission to root:root 640 and use nss_ldap too? usualy in this case a small portion of the progam run as setuid root, but of course in this case it can't help since it's a library and the whole nss philosophy are different from this. what can i do? or currently there is no solution for this? thanks in advance. yours. -- Levente "Si vis pacem para bellum!" From dwalsh at redhat.com Tue May 10 14:25:48 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 10 May 2005 10:25:48 -0400 Subject: CGI on user directory In-Reply-To: <200505101313.j4ADDwJ8025504@mms-r00.iijmio.jp> References: <42809146.8040609@redhat.com> <200505101313.j4ADDwJ8025504@mms-r00.iijmio.jp> Message-ID: <4280C46C.2080409@redhat.com> Yuichi Nakamura wrote: >Daniel J Walsh wrote: > > >>Do you have the httpd_enable_homedirs boolean set? >>I see policy that says: >>if (httpd_enable_homedirs) { >>allow { httpd_t httpd_suexec_t httpd_$1_script_t } $1_home_dir_t:dir { >>getattr search }; >>} >> >> ># getsebool httpd_enable_homedirs >httpd_enable_homedirs --> active > > > >>Also your first message said >>"allow httpd_suexec_t user_home_t:dir { read };" >>was necessary >> >> >I'm sorry, it was my mistake. >I pasted allow statement in another test;) > > > >>This error requires >>"allow httpd_suexec_t user_home_dir_t:dir { search };" >> >> >Yes, >"allow httpd_suexec_t user_home_dir_t:dir search;" >is correct. > > > >>I see policy that says: >>if (httpd_enable_homedirs) { >>allow { httpd_t httpd_suexec_t httpd_$1_script_t } $1_home_dir_t:dir { >>getattr search }; >>} >> >> >This appears in apache_user_domain macro, >but it seems that apache_user_domain is not used in targeted policy. > > > Yes nice catch. I will fix. >--- >Yuichi Nakamura > > -- From alex at milivojevic.org Tue May 10 14:55:32 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Tue, 10 May 2005 09:55:32 -0500 Subject: using selinux to control user access to files In-Reply-To: <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <427F83BD.1070909@redhat.com> <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> Message-ID: <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> Quoting Hein Coulier : > Don't get me wrong : i understand why redhat shouldn't be eager to support > strict policies. I also don't expect the problems to be generated by > redhat, but by my 3rd party products : what if websphere (and our internet > shop) stops running, or all our oracle databases in our 250 retail shops ? > Even with support, damage in $ would be to big. > > I hope that in a few years, linux will become like a mainframe with default > security, and that it will be an evidence for all vendors that it's their > duty to provide the neccessary rules to protect and keep their systems and > data available. I'm looking at this from a bit different angle. User can do lots of damage even if only "standard" Unix access controls are used (file permissions and ownerships). SELinux only brings this at more complex level. If it is too complex for Red Hat (or any other vendor) to support it at standard pricing levels, they could have "advanced security release" of product that includes strict policy with higher price tag (that would reflect higher support costs). Users of cheaper products should be allowed to install strict policy too, but if they need support, they'd need to switch back to targeted policy or upgrade to "advanced security" version of product. I see nothing wrong with such an approach. > Best solution for me would be that rbac on userbase could be made available > in targeted policy. I'm an total SELinux newbie (intend to improve on that), but yes, this would be nice to have feature if possible. In my work environmnt, we work with some sensitive data, and we must have audit trail whenever some types of files are touched (or we would fail external audits, which translates to lost jobs, simple as that). Problem with using Linux so far was lack of good auditing tools. SELinux looked promising on the surface, but if I can have auditing only with strict policy, and RHEL doesn't support it, than Red Hat has put itself out of game. If it was possible to create "targeted" per-user/group rules in targeted policy, with audit logging (when access is granted), that would be good enough. > I think you're all doing a great job, and i still believe selinux is the > future. Keep up the good work. I completely agree with this. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From Valdis.Kletnieks at vt.edu Tue May 10 15:31:53 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 10 May 2005 11:31:53 -0400 Subject: using selinux to control user access to files In-Reply-To: Your message of "Tue, 10 May 2005 09:55:32 CDT." <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <427F83BD.1070909@redhat.com> <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> Message-ID: <200505101531.j4AFVreO011856@turing-police.cc.vt.edu> On Tue, 10 May 2005 09:55:32 CDT, alex at milivojevic.org said: > > Best solution for me would be that rbac on userbase could be made available > > in targeted policy. > > I'm an total SELinux newbie (intend to improve on that), but yes, this > would be > nice to have feature if possible. In my work environmnt, we work with some > sensitive data, and we must have audit trail whenever some types of files are > touched (or we would fail external audits, which translates to lost jobs, > simple as that). Well, unfortunately, this is a "fish or cut bait" scenario. Targeted looks the way it does because all "normal userspace" gets dumped into one unconfined_t. If you want per-(user/role/etc) separation, you really have to go to some variant on "strict" - a *huge* part of the size of "strict" is dealing with all those annoying interactions between domains. If you want a user1_t and a user2_t, you almost have to support splitting tmp_t into a user1_tmp_t and a user2_tmp_t so user2 can't get into user1 via a tmp_t file. I suspect what you really want here is not "targeted" but "strict with a lot of the booleans set to loosen the policy somewhat"..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Tue May 10 15:50:19 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 10 May 2005 11:50:19 -0400 Subject: using selinux to control user access to files In-Reply-To: <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <427F83BD.1070909@redhat.com> <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> Message-ID: <4280D83B.80403@redhat.com> alex at milivojevic.org wrote: > Quoting Hein Coulier : > >> Don't get me wrong : i understand why redhat shouldn't be eager to >> support >> strict policies. I also don't expect the problems to be generated by >> redhat, but by my 3rd party products : what if websphere (and our >> internet >> shop) stops running, or all our oracle databases in our 250 retail >> shops ? >> Even with support, damage in $ would be to big. >> >> I hope that in a few years, linux will become like a mainframe with >> default >> security, and that it will be an evidence for all vendors that it's >> their >> duty to provide the neccessary rules to protect and keep their >> systems and >> data available. > > > I'm looking at this from a bit different angle. User can do lots of > damage even > if only "standard" Unix access controls are used (file permissions and > ownerships). SELinux only brings this at more complex level. If it > is too > complex for Red Hat (or any other vendor) to support it at standard > pricing > levels, they could have "advanced security release" of product that > includes > strict policy with higher price tag (that would reflect higher support > costs). Users of cheaper products should be allowed to install strict > policy too, but if > they need support, they'd need to switch back to targeted policy or > upgrade to > "advanced security" version of product. I see nothing wrong with such an > approach. > >> Best solution for me would be that rbac on userbase could be made >> available >> in targeted policy. > > > I'm an total SELinux newbie (intend to improve on that), but yes, this > would be > nice to have feature if possible. In my work environmnt, we work with > some > sensitive data, and we must have audit trail whenever some types of > files are > touched (or we would fail external audits, which translates to lost jobs, > simple as that). Problem with using Linux so far was lack of good > auditing > tools. SELinux looked promising on the surface, but if I can have > auditing > only with strict policy, and RHEL doesn't support it, than Red Hat has > put > itself out of game. If it was possible to create "targeted" > per-user/group > rules in targeted policy, with audit logging (when access is granted), > that > would be good enough. > You can use the Audit Framework for watching certain files with or without SELinux. Have you looked at auditd and auditctl. >> I think you're all doing a great job, and i still believe selinux is the >> future. Keep up the good work. > > > I completely agree with this. > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From linux_4ever at yahoo.com Tue May 10 17:57:20 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 10 May 2005 10:57:20 -0700 (PDT) Subject: using selinux to control user access to files In-Reply-To: 6667 Message-ID: <20050510175721.5887.qmail@web51507.mail.yahoo.com> >In my work environmnt, we work with some sensitive data, and we must have audit >trail whenever some types of files are touched (or we would fail external audits, >which translates to lost jobs, simple as that). Problem with using Linux so far >was lack of good auditing tools. This is all in work. The 0.7.4 audit package has some information about setting file watches (auditctl -w -p ). However, you need to have a kernel that's patched for it. We are still peer reviewing this capability. I think we have just a few more locking issues to solve and then it will be sent to lkml. I have put the tools into FC4 so that when the file system auditing patch does go upstream & you do a kernel update, everything starts working. -Steve Grubb __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From mike at navi.cx Tue May 10 19:30:47 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 10 May 2005 20:30:47 +0100 Subject: Untrusted content domain References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> Message-ID: On Mon, 09 May 2005 16:57:06 -0400, Ivan Gyurdiev wrote: > The untrusted_content part of this is a proposal for a type to be used > to mark things downloaded from the Internet that cannot be trusted > (hence..untrusted). The idea is that various web browsers, p2p clients, > etc. will use this type to store content. OK. What problem are we trying to solve here, exactly: that users want to run programs they download in some kind of quarantine zone? Or is the idea that actual data files may be problematic and need to be kept from other programs? I can't see any system that requires freeing data files being successful, people download way too many, but programs maybe ... It seems that the most common type of program to download and run is an installer or package. Right now they [usually] need root to work, but figuring out exactly what privs an installer or package really needs would probably be a good idea. Can you give some use cases where this sort of untrusted content type prevents Bob from damaging or accidentally subverting his system? thanks -mike From morgan at orst.edu Tue May 10 16:08:35 2005 From: morgan at orst.edu (Andrew Morgan) Date: Tue, 10 May 2005 09:08:35 -0700 (PDT) Subject: [nssldap] nss_ldap's tls_key file permission In-Reply-To: <4280B778.6060006@bppiac.hu> References: <4280B778.6060006@bppiac.hu> Message-ID: On Tue, 10 May 2005, Farkas Levente wrote: > hi, > if we'd like to use nss_ldap with tls certificzte files than we have to use a > least 644 permission even on the key file. it's not a good security concern. > it's better than without tls, but local user still too powerful in this > case:-( is there any way to prevent this? i mean to be able to change the > file permission to root:root 640 and use nss_ldap too? usualy in this case a > small portion of the progam run as setuid root, but of course in this case it > can't help since it's a library and the whole nss philosophy are different > from this. what can i do? or currently there is no solution for this? > thanks in advance. > yours. If you run 'nscd', then all nss requests will be routed through nscd (running as root) and you may be able to use stricter permissions on the config file and certificate files. Andy From ivg2 at cornell.edu Tue May 10 23:12:01 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 May 2005 19:12:01 -0400 Subject: Untrusted content domain In-Reply-To: References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> Message-ID: <1115766721.4904.37.camel@localhost.localdomain> > Or is the idea > that actual data files may be problematic and need to be kept from other > programs? Yes... malformed content to make a program crash. > I can't see any system that requires freeing data files being > successful, people download way too many, but programs maybe ... Why is that? Currently working with SELinux is kind of a pain, because there's command line tools, and that's it. I know Daniel Walsh has a nautilus integration patch. I've been planning to work on improving that, and allow its use for relabeling content to various "customizable" types, but I haven't gotten to it yet. Also, there have been proposals for more automated approaches to this. I thought maybe various content handlers could register the security label they can handle, and when the user attempts to open a file of that type, it can be relabeled automatically (after warning the user, or scanning the file). Some of this was discussed on NSA-list, and on GNOME-Usability-list. In any case, I have a very concrete, and small proposal here, not something in the distant future: 1) Replace the mozilla downloaded content type from ROLE_mozilla_home_t, which seems completely wrong, to ROLE_untrusted_content_t 2) Replace the giFT downloaded content type from ROLE_gift_home_t, which seems completely wrong, to ROLE_untrusted_content_t 3) Replace the /tmp mozilla type from ROLE_mozilla_tmp_t to ROLE_untrusted_content_t This has the following immediate benefits: - Downloaded content can be distinguished from internal program settings, and such... - There is a common type, instead of multiple types depending on the program. Then we have to figure out what to do with this type. In the immediate future we could: - permit full access to it from ROLE_t - deny access to it, and require that people relabel this stuff - a combination of both, toggled by a boolean - something different, smarter, subject to discussion It's important to realize that the lack of common type is a problem. Also, ROLE_home_t is an unsuitable common type - because everything's labeled ROLE_home_t, including all kinds of important files that we don't want random programs to access and overwrite. > Can you give some use cases where this sort of untrusted content type > prevents Bob from damaging or accidentally subverting his system? 1) A common type is needed for downloads. 2) That common type can't be ROLE_home_t, for security purposes. It shouldn't be ROLE_mozilla_home_t, or something like that either, that's used for other stuff - it should be a new type, dedicated to downloads. 3) Once a common type is created, it can be used for various fun things, such as virus protection. Programs can be prevented from accessing content of this type in certain ways by the sysadmin....for example to prevent people from executing hostile content from the net. -- Ivan Gyurdiev Cornell University From mike at navi.cx Tue May 10 23:52:09 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 11 May 2005 00:52:09 +0100 Subject: Untrusted content domain References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> Message-ID: On Tue, 10 May 2005 19:12:01 -0400, Ivan Gyurdiev wrote: > In any case, I have a very concrete, and small proposal here, not > something in the distant future: OK, it all seems sensible. > 1) A common type is needed for downloads. > > 2) That common type can't be ROLE_home_t, for security purposes. > It shouldn't be ROLE_mozilla_home_t, or something like that either, > that's used for other stuff - it should be a new type, dedicated > to downloads. > > 3) Once a common type is created, it can be used for various fun things, > such as virus protection. Programs can be prevented from accessing > content of this type in certain ways by the sysadmin....for example > to prevent people from executing hostile content from the net. Would it be OK to figure out a certain set of permissions that is OK for random untrusted software to use. For instance Flash developers get a lot of milage out of the ability to write fun games that operate entirely inside the Flash sandbox which is pretty restrictive, it seems like there should be some level of control we can give programs so that humanities innate urge to distribute electronic greetings cards can be satisifed securely :) The thing I'm not really sure about is why preventing programs from accessing downloaded data files is useful. If you know you can overflow a program with malicious data the only sure protection is to fix the app, right? It seems a bit different to viruses which are actually programs. thanks -mike From ivg2 at cornell.edu Wed May 11 01:34:36 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Tue, 10 May 2005 21:34:36 -0400 Subject: Untrusted content domain In-Reply-To: References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> Message-ID: <1115775276.5652.24.camel@localhost.localdomain> > Would it be OK to figure out a certain set of permissions that is OK for > random untrusted software to use. For instance Flash developers get a lot > of milage out of the ability to write fun games that operate entirely > inside the Flash sandbox which is pretty restrictive, it seems like there > should be some level of control we can give programs so that humanities > innate urge to distribute electronic greetings cards can be satisifed > securely :) Mozilla is allowed to execute downloaded content right now... I think for Java it transitions to a special javaplugin domain. I suppose the same thing can be setup for flash, if necessary. > The thing I'm not really sure about is why preventing programs from > accessing downloaded data files is useful. If you know you can overflow a > program with malicious data the only sure protection is to fix the app, > right? It seems a bit different to viruses which are actually programs. Fixing the app is one aspect of security, and probably the most important one. However, it might not always be possible - what about third-party closed software? Besides, maybe you just don't trust the app, and you don't want to allow it to handle potentially hostile content. SELinux is mostly about containment, and allowing the sysadmin to control interactions between various domains and objects. If we can give the sysadmin a say in how potentially hostile content is handled, I think we should. Basically, the content you download from the Internet has to be labeled somehow, and the current labeling scheme is not appropriate IMHO. I want to setup a better labeling scheme. I don't know at this point exactly how it might be taken advantage of, but I'm sure there's all kinds of things that can be done to improve security, with a common hostile content type, as opposed to multiple hostile content types, or worse, no differentiation from ROLE_home_t. ================= By the way, since you're involved with Codeweavers - does all of wine require text relocations? If so, it needs to be marked textrel_shlib_t. I should probably file a policy bug, because it doesn't work at all under SELinux strict - I use wine quite a lot (games on Linux!), and it's annoying that I have to turn SELinux off all the time to make use of it. for FILE in /usr/local/lib/wine/*.so; do if [ ! -z "`readelf -d $FILE| grep TEXTREL`" ]; then echo $FILE; fi; done; (result: everything) wine: failed to initialize: /usr/local/lib/wine/ntdll.dll.so: cannot restore segment prot after reloc: Permission denied -- Ivan Gyurdiev Cornell University From mike at navi.cx Wed May 11 12:47:17 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 11 May 2005 13:47:17 +0100 Subject: Untrusted content domain References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> Message-ID: On Tue, 10 May 2005 21:34:36 -0400, Ivan Gyurdiev wrote: > By the way, since you're involved with Codeweavers - does all of wine > require text relocations? If so, it needs to be marked textrel_shlib_t. I'm not sure, I haven't examined the reasons we have text relocs in depth. Wines build system is complex, and I've not seen any documentation on what kind of things can trigger this. A hunch is maybe it's related to the embedded NT headers. > I should probably file a policy bug, because it doesn't work at all > under SELinux strict - I use wine quite a lot (games on Linux!), > and it's annoying that I have to turn SELinux off all the > time to make use of it. I was wondering about that :) I couldn't quite figure out whether the textrel thing was both targetted and strict or just strict: seems like it's just strict :) Marking libs as textrel_shlib_t should be done automatically by the patched install IMHO. We don't have any bugs filed on this in WineHQ/Codeweavers bugzilla so right now I guess not many people are trying to use strict on a desktop. But obviously if we can fix this easily then that'd be great. Actually I was talking to Jeremy (White) about this the other day. We'd be happy to kick in a free copy of Crossover for SELinux developers if they were interested in testing things with it. I saw that Steven Smalley is testing new restrictions like execstack with programs like Java, Mozilla, OpenOffice etc: getting Wine/Crossover (they're virtually the same) into that list would be great. It's a little tricky because I guess most SELinux developers are running strict, but most of our customers/users are running targetted (or not running SELinux at all), so there's not much commercial pressure to fix problems that only affect strict. Whereas for instance in execshield we had to put a lot of work into supporting it :( Still it'd be nice to know in advance about these things, especially if bits of strict are going to migrate to targetted at some point. thanks -mike From alex at milivojevic.org Wed May 11 13:12:22 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Wed, 11 May 2005 08:12:22 -0500 Subject: using selinux to control user access to files In-Reply-To: <4280D83B.80403@redhat.com> References: <000901c5521c$de3e3d70$34106f0a@admin.colruyt.int> <427B5D30.50401@redhat.com> <1115380996.5654.19.camel@moss-spartans.epoch.ncsc.mil> <427B6EDC.10709@redhat.com> <1115385436.5654.44.camel@moss-spartans.epoch.ncsc.mil> <003901c5548a$65e36ab0$a9106f0a@admin.colruyt.int> <1115642335.26152.11.camel@moss-spartans.epoch.ncsc.mil> <006201c554a3$af032af0$a9106f0a@admin.colruyt.int> <427F83BD.1070909@redhat.com> <007401c5553e$db05a240$a9106f0a@admin.colruyt.int> <20050510095532.lqjxryo7y8wk8ckw@www.milivojevic.org> <4280D83B.80403@redhat.com> Message-ID: <20050511081222.e4ulas9owsokkw0k@www.milivojevic.org> Quoting Daniel J Walsh : > You can use the Audit Framework for watching certain files with or > without SELinux. > > Have you looked at auditd and auditctl. Hm, looks interesting. A bit missing in documentation on RHEL4, however I fetched sources from rawhide (that have some documentation). Is Audit Framework part of SELinux, used by SELinux, or something totally unrelated? ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From linux_4ever at yahoo.com Wed May 11 13:31:39 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 May 2005 06:31:39 -0700 (PDT) Subject: using selinux to control user access to files In-Reply-To: 6667 Message-ID: <20050511133140.4772.qmail@web51510.mail.yahoo.com> >A bit missing in documentation on RHEL4, however I fetched sources from rawhide >(that have some documentation). At the time tha RHEL4 shipped, the audit framework had a lot of work to go. It couldn't really be documented since the utilities didn't really exist. It is slated for inclusion in U2. Also, FC4 has a respectable piece of the audit subsystem in it. >Is Audit Framework part of SELinux, used by SELinux, or something totally >unrelated? Its a separate entity with a different control interface. SE Linux uses it to send AVC messages. The audit system determines whether an audit daemon is in use. If so the messages go to the audit daemon. If not, they go to syslog. If you want to experiment with the audit system, try out FC4. I'll probably start writing tutorials and howto's once the audit system gets closer to completion. -Steve Grubb __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From dwalsh at redhat.com Wed May 11 14:21:07 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 May 2005 10:21:07 -0400 Subject: Untrusted content domain In-Reply-To: References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> Message-ID: <428214D3.4060909@redhat.com> Mike Hearn wrote: >On Tue, 10 May 2005 21:34:36 -0400, Ivan Gyurdiev wrote: > > >>By the way, since you're involved with Codeweavers - does all of wine >>require text relocations? If so, it needs to be marked textrel_shlib_t. >> >> > >I'm not sure, I haven't examined the reasons we have text relocs in depth. >Wines build system is complex, and I've not seen any documentation on what >kind of things can trigger this. A hunch is maybe it's related to the >embedded NT headers. > > > >>I should probably file a policy bug, because it doesn't work at all >>under SELinux strict - I use wine quite a lot (games on Linux!), >>and it's annoying that I have to turn SELinux off all the >>time to make use of it. >> >> > >I was wondering about that :) I couldn't quite figure out whether >the textrel thing was both targetted and strict or just strict: >seems like it's just strict :) > >Marking libs as textrel_shlib_t should be done automatically by the >patched install IMHO. We don't have any bugs filed on this in >WineHQ/Codeweavers bugzilla so right now I guess not many people are >trying to use strict on a desktop. But obviously if we can fix this >easily then that'd be great. > > > Currently textrel_shlib_t == shlib_t == lib_t in targeted policy. That can and should probably change in the future as we tighten up security of the userspace with SELinux. >Actually I was talking to Jeremy (White) about this the other day. We'd be >happy to kick in a free copy of Crossover for SELinux developers if they >were interested in testing things with it. I saw that Steven Smalley is >testing new restrictions like execstack with programs like Java, Mozilla, >OpenOffice etc: getting Wine/Crossover (they're virtually the same) into >that list would be great. > > > I would take a look at it. Mainly need a list of shared libraries and whether then need textrel support. But other issues will probably arise. >It's a little tricky because I guess most SELinux developers are running >strict, but most of our customers/users are running targetted (or not >running SELinux at all), so there's not much commercial pressure to fix >problems that only affect strict. Whereas for instance in execshield we >had to put a lot of work into supporting it :( Still it'd be nice to know >in advance about these things, especially if bits of strict are going to >migrate to targetted at some point. > > > They will, and they are. >thanks -mike > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From selinux at gmail.com Wed May 11 14:40:05 2005 From: selinux at gmail.com (Tom London) Date: Wed, 11 May 2005 07:40:05 -0700 Subject: targeted/cups.te - unconfined_t send_msg.... Message-ID: <4c4ba153050511074039f71f5f@mail.gmail.com> Running targeted/enforcing, latest rawhide. I get the following avc during login: May 11 06:18:09 localhost dbus: avc: denied { send_msg } for msgtype=method_call interface=com.redhat.CupsDriverConfig member=MatchDriver dest=com.redhat.CupsDriverConfig spid=3675 tpid=3019 scontext=user_u:system_r:unconfined_t tcontext=system_u:system_r:cupsd_config_t tclass=dbus Does this make sense? --- cups.te 2005-05-02 13:18:00.000000000 -0700 +++ /tmp/cups.te 2005-05-11 07:38:05.000000000 -0700 @@ -258,5 +258,5 @@ can_unix_connect(cupsd_t, initrc_t) allow cupsd_t initrc_t:dbus send_msg; allow initrc_t cupsd_t:dbus send_msg; -allow cupsd_t unconfined_t:dbus send_msg; +allow { cupsd_t cupsd_config_t } unconfined_t:dbus send_msg; ') tom -- Tom London From alex at milivojevic.org Wed May 11 14:44:50 2005 From: alex at milivojevic.org (alex at milivojevic.org) Date: Wed, 11 May 2005 09:44:50 -0500 Subject: using selinux to control user access to files In-Reply-To: <20050510175721.5887.qmail@web51507.mail.yahoo.com> References: <20050510175721.5887.qmail@web51507.mail.yahoo.com> Message-ID: <20050511094450.q6mkl4dz40gwgogg@www.milivojevic.org> Quoting Steve G : > This is all in work. The 0.7.4 audit package has some information > about setting > file watches (auditctl -w -p ). However, you need to have a kernel > that's patched > for it. We are still peer reviewing this capability. I think we have > just a few > more locking issues to solve and then it will be sent to lkml. I have put the > tools into FC4 so that when the file system auditing patch does go > upstream & you > do a kernel update, everything starts working. Sounds like great news. I take it that even if I fire up auditd on RHEL4 today, and attempt to play with auditctl, it isn't going to work until there is updated kernel (or I patch/recompile existing kernel)? ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From dwalsh at redhat.com Wed May 11 15:03:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 May 2005 11:03:43 -0400 Subject: targeted/cups.te - unconfined_t send_msg.... In-Reply-To: <4c4ba153050511074039f71f5f@mail.gmail.com> References: <4c4ba153050511074039f71f5f@mail.gmail.com> Message-ID: <42821ECF.4030800@redhat.com> Tom London wrote: >Running targeted/enforcing, latest rawhide. > >I get the following avc during login: >May 11 06:18:09 localhost dbus: avc: denied { send_msg } for >msgtype=method_call interface=com.redhat.CupsDriverConfig >member=MatchDriver dest=com.redhat.CupsDriverConfig spid=3675 >tpid=3019 scontext=user_u:system_r:unconfined_t >tcontext=system_u:system_r:cupsd_config_t tclass=dbus > >Does this make sense? >--- cups.te 2005-05-02 13:18:00.000000000 -0700 >+++ /tmp/cups.te 2005-05-11 07:38:05.000000000 -0700 >@@ -258,5 +258,5 @@ > can_unix_connect(cupsd_t, initrc_t) > allow cupsd_t initrc_t:dbus send_msg; > allow initrc_t cupsd_t:dbus send_msg; >-allow cupsd_t unconfined_t:dbus send_msg; >+allow { cupsd_t cupsd_config_t } unconfined_t:dbus send_msg; > ') > >tom > > This rule is in 1.23.15-4 and later. I am not sure rawhide policy is being updated at this point with the pending release of FC4/Test3. You can grab later policy off of ftp://people.redhat.com/dwalsh/Fedora -- From dwalsh at redhat.com Wed May 11 15:05:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 11 May 2005 11:05:14 -0400 Subject: targeted/cups.te - unconfined_t send_msg.... In-Reply-To: <4c4ba153050511074039f71f5f@mail.gmail.com> References: <4c4ba153050511074039f71f5f@mail.gmail.com> Message-ID: <42821F2A.7070303@redhat.com> Tom London wrote: >Running targeted/enforcing, latest rawhide. > >I get the following avc during login: >May 11 06:18:09 localhost dbus: avc: denied { send_msg } for >msgtype=method_call interface=com.redhat.CupsDriverConfig >member=MatchDriver dest=com.redhat.CupsDriverConfig spid=3675 >tpid=3019 scontext=user_u:system_r:unconfined_t >tcontext=system_u:system_r:cupsd_config_t tclass=dbus > >Does this make sense? >--- cups.te 2005-05-02 13:18:00.000000000 -0700 >+++ /tmp/cups.te 2005-05-11 07:38:05.000000000 -0700 >@@ -258,5 +258,5 @@ > can_unix_connect(cupsd_t, initrc_t) > allow cupsd_t initrc_t:dbus send_msg; > allow initrc_t cupsd_t:dbus send_msg; >-allow cupsd_t unconfined_t:dbus send_msg; >+allow { cupsd_t cupsd_config_t } unconfined_t:dbus send_msg; > ') > >tom > > I think so. This is cups sending a dbus message to the desktop. -- From linux_4ever at yahoo.com Wed May 11 15:22:30 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 11 May 2005 08:22:30 -0700 (PDT) Subject: using selinux to control user access to files In-Reply-To: 6667 Message-ID: <20050511152231.19297.qmail@web51506.mail.yahoo.com> >I take it that even if I fire up auditd on RHEL4 today, and attempt to >play with auditctl, it isn't going to work until there is updated kernel >(or I patch/recompile existing kernel)? Right. There's roughly 20-30 patches against the RHEL4 kernel at this point. Some of which are experimental and not accepted upstream and therefore likely to change. FC4 has everything in it that is currently accepted upstream. It would be easier to experiment with FC4 at this point. -Steve __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From selinux at gmail.com Wed May 11 15:58:11 2005 From: selinux at gmail.com (Tom London) Date: Wed, 11 May 2005 08:58:11 -0700 Subject: targeted/cups.te - unconfined_t send_msg.... In-Reply-To: <42821F2A.7070303@redhat.com> References: <4c4ba153050511074039f71f5f@mail.gmail.com> <42821F2A.7070303@redhat.com> Message-ID: <4c4ba15305051108584fd8cd4a@mail.gmail.com> Believe the link is: ftp://people.redhat.com/dwalsh/SELinux/Fedora/ Thanks! tom From ivg2 at cornell.edu Wed May 11 16:56:33 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 11 May 2005 12:56:33 -0400 Subject: Untrusted content domain In-Reply-To: References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> Message-ID: <1115830594.28219.6.camel@localhost.localdomain> > Marking libs as textrel_shlib_t should be done automatically by the > patched install IMHO. We don't have any bugs filed on this in > WineHQ/Codeweavers bugzilla so right now I guess not many people are > trying to use strict on a desktop. But obviously if we can fix this > easily then that'd be great. If libs are marked textrel_shlib_t in the policy, they will be automatically relabeled as such by the rpm installer, as well as the install command on Fedora. However, they are not marked as such - Daniel, perhaps /usr(/local)?/lib/wine/.*\.so -- textrel_shlib_t should be added? On the other hand, if wine doesn't need text relocations, it would be better if it was compiled without them. -- Ivan Gyurdiev Cornell University From mike at navi.cx Wed May 11 17:44:04 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 11 May 2005 18:44:04 +0100 Subject: Untrusted content domain References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> <1115830594.28219.6.camel@localhost.localdomain> Message-ID: On Wed, 11 May 2005 12:56:33 -0400, Ivan Gyurdiev wrote: > On the other hand, if wine doesn't need text relocations, it > would be better if it was compiled without them. I investigated this, they're basically unavoidable without lots of pain. They're being generated by the assembly we use for IAT thunks. We need them because Wine does its own linking even for ELF DLLs. thanks -mike From ivg2 at cornell.edu Wed May 11 17:47:52 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 11 May 2005 13:47:52 -0400 Subject: Untrusted content domain In-Reply-To: <1115832332.5205.6.camel@littlegreen> References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> <1115830594.28219.6.camel@localhost.localdomain> <1115832332.5205.6.camel@littlegreen> Message-ID: <1115833672.28691.4.camel@localhost.localdomain> On Wed, 2005-05-11 at 18:25 +0100, Mike Hearn wrote: > On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote: > > However, they are not marked as such - Daniel, perhaps > > /usr(/local)?/lib/wine/.*\.so -- textrel_shlib_t > > should be added? > > That is a bit hacky. I personally install Wine to /opt/wine and > Crossover can go anywhere. I think it'd be better to adjust the Wine > build system to label them correctly. That's not how SELinux works right now - labeling decisions are centralized in the policy. I'm not sure why it's done that way - perhaps it's because the policy sources are also centralized. (cc-ed Stephen Smalley - maybe he can explain) If you label wine in the build system, and later I run restorecon, which brings the system permissions in sync with what the file_contexts file says, it will restore the permissions back to what the policy thinks they should be. > > On the other hand, if wine doesn't need text relocations, it > > would be better if it was compiled without them. > > I have no idea why they're there, like I said, there's no documentation > I could find on what causes the toolchain to produce them. How do you go > about getting rid of them? They're compiled with -fPIC already. Not sure about that - my guesses run out with fPIC... -- Ivan Gyurdiev Cornell University From ivg2 at cornell.edu Wed May 11 17:49:24 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 11 May 2005 13:49:24 -0400 Subject: Untrusted content domain In-Reply-To: <1115832332.5205.6.camel@littlegreen> References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> <1115830594.28219.6.camel@localhost.localdomain> <1115832332.5205.6.camel@littlegreen> Message-ID: <1115833764.28691.5.camel@localhost.localdomain> (sorry for resend - incorrect recipient) On Wed, 2005-05-11 at 18:25 +0100, Mike Hearn wrote: > On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote: > > However, they are not marked as such - Daniel, perhaps > > /usr(/local)?/lib/wine/.*\.so -- textrel_shlib_t > > should be added? > > That is a bit hacky. I personally install Wine to /opt/wine and > Crossover can go anywhere. I think it'd be better to adjust the Wine > build system to label them correctly. That's not how SELinux works right now - labeling decisions are centralized in the policy. I'm not sure why it's done that way - perhaps it's because the policy sources are also centralized. (cc-ed Stephen Smalley - maybe he can explain) If you label wine in the build system, and later I run restorecon, which brings the system permissions in sync with what the file_contexts file says, it will restore the permissions back to what the policy thinks they should be. > > On the other hand, if wine doesn't need text relocations, it > > would be better if it was compiled without them. > > I have no idea why they're there, like I said, there's no documentation > I could find on what causes the toolchain to produce them. How do you go > about getting rid of them? They're compiled with -fPIC already. Not sure about that - my guesses run out with fPIC... -- Ivan Gyurdiev Cornell University From mike at navi.cx Wed May 11 17:25:32 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 11 May 2005 18:25:32 +0100 Subject: Untrusted content domain In-Reply-To: <1115830594.28219.6.camel@localhost.localdomain> References: <1115643881.4319.5.camel@littlegreen> <1115672226.10218.76.camel@localhost.localdomain> <1115766721.4904.37.camel@localhost.localdomain> <1115775276.5652.24.camel@localhost.localdomain> <1115830594.28219.6.camel@localhost.localdomain> Message-ID: <1115832332.5205.6.camel@littlegreen> On Wed, 2005-05-11 at 12:56 -0400, Ivan Gyurdiev wrote: > However, they are not marked as such - Daniel, perhaps > /usr(/local)?/lib/wine/.*\.so -- textrel_shlib_t > should be added? That is a bit hacky. I personally install Wine to /opt/wine and Crossover can go anywhere. I think it'd be better to adjust the Wine build system to label them correctly. > On the other hand, if wine doesn't need text relocations, it > would be better if it was compiled without them. I have no idea why they're there, like I said, there's no documentation I could find on what causes the toolchain to produce them. How do you go about getting rid of them? They're compiled with -fPIC already. thanks -mike From gauret at free.fr Fri May 13 07:25:50 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 13 May 2005 09:25:50 +0200 Subject: OpenOffice.org 1.9.100 Message-ID: Hi, Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org won't run on FC3 because of SELinux: audit(1115968252.998:0): avc: denied { execmod } for pid=9833 comm=soffice.bin path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2 ino=308509 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:usr_t tclass=file What should we tell the upstream rpm maintainters so that their packages work on FC3 ? The packages used to work in an earlier version (1.9.73 I think). It's also possible that a policy update caused it, I'm not sure, I didn't use them very often. Is there something we can do to fix it, or is it only in the hands of the upstream maintainers ? Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. From Valdis.Kletnieks at vt.edu Fri May 13 08:46:03 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 13 May 2005 04:46:03 -0400 Subject: OpenOffice.org 1.9.100 In-Reply-To: Your message of "Fri, 13 May 2005 09:25:50 +0200." References: Message-ID: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> On Fri, 13 May 2005 09:25:50 +0200, Aurelien Bompard said: > Hi, > > Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org > won't run on FC3 because of SELinux: > audit(1115968252.998:0): avc: denied { execmod } for pid=9833 > comm=soffice.bin > path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2 > ino=308509 scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:usr_t tclass=file This of course fails in the same basic manner under 'strict', except it's no longer an unconfined_t.... > What should we tell the upstream rpm maintainters so that their packages > work on FC3 ? The packages used to work in an earlier version (1.9.73 I > think). It's also possible that a policy update caused it, I'm not sure, I > didn't use them very often. > > Is there something we can do to fix it, or is it only in the hands of the > upstream maintainers ? What you can do short-term: If you have selinux-policy--sources installed, you can try this: cat << EOF >> /etc/selinux/strict/src/policy/file_contexts/misc/local.fc # Places the OpenOffice stuff puts stuff /usr/local/OpenOffice.org1.1.4/program/.*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /opt/openoffice.org[^/]*/program/.*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /opt/openoffice.org[^/]*/program/soffice.bin -- system_u:object_r:bin_t EOF That seemed to shut the vast majority of the whinging when I tried it with strict/permissive. You might have to tag something with texrel_shlib_t as well. I don't think there's any new policy needed, just file contexts to get the *.so's as shlib_t and the binaries as bin_t (it's 4:37AM and one of my cats just finished dropping a litter of kittens under my bed about a half hour, so you'll have to flush out the rest of the answer for yourself :) Long-term answer: when Fedora ships their official openofficeorg-*-2.0 RPMs, we'll make sure The Right Thing happens. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From gauret at free.fr Fri May 13 10:05:02 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 13 May 2005 12:05:02 +0200 Subject: OpenOffice.org 1.9.100 References: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> Message-ID: OK, so there is nothing the upstream maintainers can/have to do. How should third party vendors package their RPMs to make sure they work with SELinux, then ? Can we exclude /opt from the audits ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr Recursion: (n.) See "Recursion". From laroche at redhat.com Fri May 13 10:14:27 2005 From: laroche at redhat.com (Florian La Roche) Date: Fri, 13 May 2005 12:14:27 +0200 Subject: OpenOffice.org 1.9.100 In-Reply-To: References: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> Message-ID: <20050513101427.GA5970@dudweiler.stuttgart.redhat.com> On Fri, May 13, 2005 at 12:05:02PM +0200, Aurelien Bompard wrote: > OK, so there is nothing the upstream maintainers can/have to do. > How should third party vendors package their RPMs to make sure they work > with SELinux, then ? Can we exclude /opt from the audits ? Filing bug-reports against the current policy is for sure good, if that has real problems in it. You can also check "pam_mount" from the newest Fedora Extras development tree to see a package that contains a selinux policy file. Not sure that is actually fully working, but at least that's the one rpm I know about doing this. greetings, Florian La Roche From sds at tycho.nsa.gov Fri May 13 11:24:17 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 13 May 2005 07:24:17 -0400 Subject: OpenOffice.org 1.9.100 In-Reply-To: References: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> Message-ID: <1115983457.3576.6.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-13 at 12:05 +0200, Aurelien Bompard wrote: > OK, so there is nothing the upstream maintainers can/have to do. Not entirely. They can eliminate the need for text relocations on their shared objects, thereby avoiding the need to mark their shared objects with texrel_shlib_t in the policy and reducing the resulting security risk. > How should third party vendors package their RPMs to make sure they work > with SELinux, then ? Can we exclude /opt from the audits ? Ultimately, they will be able to ship a "binary policy module" for their package that includes an explicit set of dependency requirements on what the base policy must provide. Binary policy module support was developed by Tresys Technology (www.tresys.com/selinux) and is planned to be upstreamed in June, for eventual inclusion in FC5/devel. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 13 11:35:04 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 13 May 2005 07:35:04 -0400 Subject: OpenOffice.org 1.9.100 In-Reply-To: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> References: <200505130846.j4D8k49n021920@turing-police.cc.vt.edu> Message-ID: <1115984104.3576.19.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-13 at 04:46 -0400, Valdis.Kletnieks at vt.edu wrote: > That seemed to shut the vast majority of the whinging when I tried it > with strict/permissive. You might have to tag something with texrel_shlib_t > as well. I don't think there's any new policy needed, just file contexts > to get the *.so's as shlib_t and the binaries as bin_t texrel_shlib_t is needed for execmod permission (text relocation). But it would be better to eliminate the need for the text relocation in the first place, as it creates a security risk. -- Stephen Smalley National Security Agency From walters at redhat.com Fri May 13 15:16:55 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 13 May 2005 11:16:55 -0400 Subject: OpenOffice.org 1.9.100 In-Reply-To: References: Message-ID: <1115997415.3432.0.camel@nexus.verbum.private> On Fri, 2005-05-13 at 09:25 +0200, Aurelien Bompard wrote: > Hi, > > Just so that you know, the OpenOffice 1.9.100 rpms from www.openoffice.org > won't run on FC3 because of SELinux: > audit(1115968252.998:0): avc: denied { execmod } for pid=9833 > comm=soffice.bin > path=/opt/openoffice.org1.9.100/program/libicudata.so.26.0.1 dev=sda2 > ino=308509 scontext=user_u:system_r:unconfined_t > tcontext=system_u:object_r:usr_t tclass=file Did you update your kernel without updating the selinux-policy-targeted package? From gauret at free.fr Fri May 13 16:29:40 2005 From: gauret at free.fr (Aurelien Bompard) Date: Fri, 13 May 2005 18:29:40 +0200 Subject: OpenOffice.org 1.9.100 References: <1115997415.3432.0.camel@nexus.verbum.private> Message-ID: Colin Walters wrote: > Did you update your kernel without updating the selinux-policy-targeted > package? I don't think so: # rpm -q selinux-policy-targeted; uname -r selinux-policy-targeted-1.17.30-3.2 2.6.11-1.20_FC3 Aur?lien -- http://gauret.free.fr ~~~~ Jabber : abompard at jabber.fr One OS to hook them all One browser to find them One word processor to bring them all And in monopoly, bind them... From russell at coker.com.au Fri May 13 16:46:32 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 14 May 2005 02:46:32 +1000 Subject: /etc/ld.so.cache and FC4T3 Message-ID: <200505140246.36294.russell@coker.com.au> I am seeing /etc/ld.so.cache getting type etc_t for an initial install of FC4T3. Is anyone else seeing this? At this stage I'm not sure whether I messed up my install process or whether it's a more general thing. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dontcrosscharlie at hotmail.com Fri May 13 19:35:03 2005 From: dontcrosscharlie at hotmail.com (charlie cross) Date: Fri, 13 May 2005 12:35:03 -0700 Subject: (no subject) Message-ID: An HTML attachment was scrubbed... URL: From dontcrosscharlie at hotmail.com Fri May 13 19:35:53 2005 From: dontcrosscharlie at hotmail.com (charlie cross) Date: Fri, 13 May 2005 12:35:53 -0700 Subject: (no subject) Message-ID: An HTML attachment was scrubbed... URL: From r.godzilla at comcast.net Fri May 13 20:52:11 2005 From: r.godzilla at comcast.net (Richard E Miles) Date: Fri, 13 May 2005 13:52:11 -0700 Subject: Problems running postgresql Message-ID: <20050513135211.192ab328.r.godzilla@comcast.net> I have been trying to start up the postgresql postmaster server to a database which have all failed. The following are a list of avc: denied messages from /var/log/messages: May 13 13:20:32 localhost kernel: audit(1116015632.155:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 13 13:20:32 localhost last message repeated 7 times May 13 13:20:32 localhost kernel: audit(1116015632.156:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 13 13:20:32 localhost last message repeated 3 times May 13 13:20:32 localhost kernel: audit(1116015632.157:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 13 13:20:32 localhost last message repeated 32 times May 13 13:20:32 localhost kernel: audit(1116015632.158:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 13 13:20:32 localhost last message repeated 34 times May 13 13:20:32 localhost kernel: audit(1116015632.159:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir Why am I getting write denials? I am running FC3 with targetted policy. -- Richard E Miles Federal Way WA. USA registered linux user 46097 From james.zheng.li at gmail.com Sun May 15 03:55:45 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Sat, 14 May 2005 23:55:45 -0400 Subject: vsftpd with selinux on FC3 Message-ID: <8a239a560505142055ce251ac@mail.gmail.com> Hi there, I am configuring Selinux to protect vsftpd on my FC3 box. I follow the procedure of Chapter 8 Cutermizing and Writing Policy in Red Hat Enterprise Linux SELinux Guide. Step1: i created a file called /etc/selinux/targeted/src/policy/domains/program/vsftpd.te the cotents are ################################# # # Rules for the vsftpd_t domain. # daemon_domain(vsftpd) the security context of this file was root:object_r:policy_src_t I changed it by using chcon -u system_u vsftpd.te Step2: create /etc/selinux/targeted/src/policy/file_contexts/program/vsftpd.fc contents are /usr/sbin/vsftpd -- system_u:object_r:vsftpd_exec_t /var/run/vsftpd.pid -- system_u:object_r:vsftpd_var_run_t /etc/vsftpd/vsftpd.conf -- system_u:object_r:vsftpd_conf_t chcon -u system_u vsftpd.fc At this moment, the security context of /etc/vsftpd and vsftpd.conf are: # ls -dZ /etc/vsftpd drwxr-xr-x root root system_u:object_r:etc_t /etc/vsftpd ls -Z /etc/vsftpd/vsftpd.conf -rw------- root root system_u:object_r:etc_t /etc/vsftpd/vsftpd.conf Step3: #make load Error message: ... Validating file_contexts ... /usr/sbin/setfiles -q -c /etc/selinux/targeted/policy/policy.18 /etc/selinux/tar geted/contexts/files/file_contexts /usr/sbin/setfiles: invalid context system_u:object_r:vsftpd_conf_t on line num ber 785 make: *** [install] Error 1 Could anyone help me on this? Thanks a lot! Btw, should I set the security context of /etc/vsftpd/vsftpd.conf to vsftpd_conf_t or vsftpd_etc_t? I am confused about some existing context, such as #ls -dZ /etc/httpd/ drwxr-xr-x root root system_u:object_r:httpd_config_t /etc/httpd/ #ls -Z /etc/httpd/conf/httpd.conf -rw-r--r-- root root system_u:object_r:httpd_config_t /etc/httpd/conf/httpd.conf BUT, # ls -dZ /etc/snmp/ drwxr-xr-x root root system_u:object_r:etc_t /etc/snmp/ # ls -Z /etc/snmp/snmpd.conf -rw-r--r-- root root system_u:object_r:snmpd_etc_t /etc/snmp/snmpd.conf Thanks, James From ivg2 at cornell.edu Sun May 15 04:05:18 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 15 May 2005 00:05:18 -0400 Subject: vsftpd with selinux on FC3 In-Reply-To: <8a239a560505142055ce251ac@mail.gmail.com> References: <8a239a560505142055ce251ac@mail.gmail.com> Message-ID: <1116129919.10479.5.camel@localhost.localdomain> > Step1: i created a file called > /etc/selinux/targeted/src/policy/domains/program/vsftpd.te > the cotents are > ################################# > # > # Rules for the vsftpd_t domain. > # > daemon_domain(vsftpd) What's wrong with the ftpd.te policy, currently available in the FC4 packages? > the security context of this file was root:object_r:policy_src_t > I changed it by using > chcon -u system_u vsftpd.te > > Step2: create /etc/selinux/targeted/src/policy/file_contexts/program/vsftpd.fc > contents are > /usr/sbin/vsftpd -- system_u:object_r:vsftpd_exec_t > /var/run/vsftpd.pid -- system_u:object_r:vsftpd_var_run_t > /etc/vsftpd/vsftpd.conf -- system_u:object_r:vsftpd_conf_t > > chcon -u system_u vsftpd.fc I don't think this matters... > At this moment, the security context of /etc/vsftpd and vsftpd.conf are: > # ls -dZ /etc/vsftpd > drwxr-xr-x root root system_u:object_r:etc_t /etc/vsftpd > > ls -Z /etc/vsftpd/vsftpd.conf > -rw------- root root system_u:object_r:etc_t > /etc/vsftpd/vsftpd.conf > > Step3: #make load > Error message: > ... > Validating file_contexts ... > /usr/sbin/setfiles -q -c /etc/selinux/targeted/policy/policy.18 > /etc/selinux/tar geted/contexts/files/file_contexts > /usr/sbin/setfiles: invalid context system_u:object_r:vsftpd_conf_t > on line num ber 785 > make: *** [install] Error 1 > > Could anyone help me on this? Thanks a lot! You need to define the type vsftpd_conf_t in the vsftpd.te file, before you can use it in your file_contexts file. Look at how the FC4 ftp policy is done, or better just use that instead... > Btw, should I set the security context of /etc/vsftpd/vsftpd.conf to > vsftpd_conf_t > or vsftpd_etc_t? I am confused about some existing context, such as You're creating the type, so the decision is up to you - both appear in different places in the policy. The etc_t one can be created simply by calling the etc_domain macro. -- Ivan Gyurdiev Cornell University From justin.conover at gmail.com Sun May 15 05:02:41 2005 From: justin.conover at gmail.com (Justin Conover) Date: Sun, 15 May 2005 00:02:41 -0500 Subject: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505140246.36294.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> Message-ID: On 5/13/05, Russell Coker wrote: > I am seeing /etc/ld.so.cache getting type etc_t for an initial install of > FC4T3. Is anyone else seeing this? > > At this stage I'm not sure whether I messed up my install process or whether > it's a more general thing. > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > $ ls -Z /etc/ld.so.cache -rw-r--r-- root root root:object_r:etc_t /etc/ld.so.cache I'm not sure if this matters, but this box has been running rawhide since sometime after fc3 was released, I think :D From russell at coker.com.au Sun May 15 12:44:32 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 15 May 2005 22:44:32 +1000 Subject: AVC messages and auditctl Message-ID: <200505152244.36292.russell@coker.com.au> Recently the AVC messages have been changed to not include the name of the executable as this is stored in the audit system. However a consequence of this is that in the early stages of boot we can't find out which program caused a message. This probably isn't a problem for the typical Fedora user (who uses targeted policy and has most of the boot scripts running in unconfined_t), but will cause problems for people who use the strict policy in it's most strict configuration and for people who want to develop an entirely new policy. What's the recommended solution to this? Can we get the audit functionality enabled through printk early in the boot process (IE in the first few lines of rc.sysinit)? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun May 15 15:06:27 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 May 2005 01:06:27 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505140246.36294.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> Message-ID: <200505160106.32177.russell@coker.com.au> On Saturday 14 May 2005 02:46, Russell Coker wrote: > I am seeing /etc/ld.so.cache getting type etc_t for an initial install of > FC4T3. Is anyone else seeing this? > > At this stage I'm not sure whether I messed up my install process or > whether it's a more general thing. I've found the problem. The domain anaconda_t seems to be unused (we should probably just delete anaconda.te). The installation process runs all initial programs from an initrd (gzip compressed cpio file). cpio has no support for SE Linux labels so no domain transitions occur and everything runs in kernel_t. Everything that's not in an initrd is in a cramfs file system (which also has no support for SE Linux labelling). This means that created files get the type of the directory - etc_t in the case of /etc/ld.so.cache. One possible method of dealing with this would be the following: domain_auto_trans(kernel_t, ldconfig_exec_t, ldconfig_t) The other option is to run restorecon at the end of the install. Both options are ugly hacks. Given that we aren't doing anything with SE Linux at the install the best option is probably to create a policy that defines all file types with a single domain that can have read/write access to them, this will save space in the stage2 files and also precious RAM (currently installing to a machine with 64M of RAM is almost impossible, and 4176K of that problem is the SE Linux policy). I've attached a little Perl script that will munge a targeted policy. It replaces most type and domain definitions with typealias rules and reduces the policy binary size from 4176K to 60K. That saves 4116K of kernel memory and almost 700K on the cramfs. The saving of 4M of kernel memory will make a huge difference to the install on small machines. Currently it's almost impossible to install a FC4 test version on a machine with 64M of RAM, this change will give the same result as adding another 4M of RAM to machines for the installer (particularly important for machines that run out of RAM before completing the partitioning process). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: tiny.pl Type: application/x-perl Size: 1170 bytes Desc: not available URL: From russell at coker.com.au Sun May 15 17:09:06 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 May 2005 03:09:06 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505160106.32177.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> Message-ID: <200505160309.09114.russell@coker.com.au> On Monday 16 May 2005 01:06, Russell Coker wrote: > I've attached a little Perl script that will munge a targeted policy. It > replaces most type and domain definitions with typealias rules and reduces > the policy binary size from 4176K to 60K. That saves 4116K of kernel > memory and almost 700K on the cramfs. The saving of 4M of kernel memory > will make a huge difference to the install on small machines. Currently > it's almost impossible to install a FC4 test version on a machine with 64M > of RAM, this change will give the same result as adding another 4M of RAM > to machines for the installer (particularly important for machines that run > out of RAM before completing the partitioning process). I've attached a new version, my first version had a bug that caused files created in the post install scripts of packages and the post install for kickstart get the wrong type. For reference, if the type on a directory is an alias it seems that new objects created under the directory get the base type in the security.selinux xattr not the alias name. Anyway with this change the result is correct (verified by running setfiles -v on a fresh install - I found evidence of other bugs but no bugs caused by my code). The policy.19 file will now be 444K in size, this saves 3732K of kernel memory which is still worth doing. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: tiny.pl Type: application/x-perl Size: 1177 bytes Desc: not available URL: From selinux at gmail.com Sun May 15 18:49:31 2005 From: selinux at gmail.com (Tom London) Date: Sun, 15 May 2005 11:49:31 -0700 Subject: /tmp/gconfd-* : wrong type after 'augmenting' user Message-ID: <4c4ba15305051511497b285c8e@mail.gmail.com> Running strict/enforcing, latest rawhide. I changed an existing user to a 'sysadm' user by adding to local.users, rebuilt/installed new policy, and did a 'restorecon -v -R' of home directory, /etc, /tmp, .... On reboot, logging shows that the preexisting /tmp/gconfd-XXX remained labeled as 'user_u:....'. Removing it (and several 'aumix*' files that were similarly labeled), and rebooting 'fixed' this. Is this the best, or does it make sense to considering adding 'per user' rules for such files? tom -- Tom London From ivg2 at cornell.edu Sun May 15 19:47:46 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 15 May 2005 15:47:46 -0400 Subject: /tmp/gconfd-* : wrong type after 'augmenting' user In-Reply-To: <4c4ba15305051511497b285c8e@mail.gmail.com> References: <4c4ba15305051511497b285c8e@mail.gmail.com> Message-ID: <1116186466.8851.8.camel@localhost.localdomain> On Sun, 2005-05-15 at 11:49 -0700, Tom London wrote: > Running strict/enforcing, latest rawhide. > > I changed an existing user to a 'sysadm' user by adding to > local.users, rebuilt/installed new policy, and did a 'restorecon -v > -R' of home directory, /etc, /tmp, .... > > On reboot, logging shows that the preexisting /tmp/gconfd-XXX > remained labeled as 'user_u:....'. > > Removing it (and several 'aumix*' files that were similarly labeled), > and rebooting 'fixed' this. > > Is this the best, or does it make sense to considering adding 'per > user' rules for such files? I have patches that addresses exactly this, and they are pending being merged post FC4. The patches create a new USER expansion, and begin using it to label the orbit and gconf folder. -- Ivan Gyurdiev Cornell University From maverickandrea at gmail.com Mon May 16 10:20:08 2005 From: maverickandrea at gmail.com (Cigliano Andrea) Date: Mon, 16 May 2005 12:20:08 +0200 Subject: A problem with telnet connection In-Reply-To: <200505160309.09114.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <200505160309.09114.russell@coker.com.au> Message-ID: <524c9b2a050516032014473217@mail.gmail.com> I have a problem with my telnetd configuration. When any telnet client connect to my telnet server after one/two minutes (or less) the connection going down (there isnt firewall started). Anyone have an idea? Thanks a lot, Maverick -------------- next part -------------- A non-text attachment was scrubbed... Name: tiny.pl Type: application/x-perl Size: 1178 bytes Desc: not available URL: From sds at tycho.nsa.gov Mon May 16 11:35:01 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 16 May 2005 07:35:01 -0400 Subject: AVC messages and auditctl In-Reply-To: <200505152244.36292.russell@coker.com.au> References: <200505152244.36292.russell@coker.com.au> Message-ID: <1116243301.28782.15.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-05-15 at 22:44 +1000, Russell Coker wrote: > Recently the AVC messages have been changed to not include the name of the > executable as this is stored in the audit system. > > However a consequence of this is that in the early stages of boot we can't > find out which program caused a message. This probably isn't a problem for > the typical Fedora user (who uses targeted policy and has most of the boot > scripts running in unconfined_t), but will cause problems for people who use > the strict policy in it's most strict configuration and for people who want > to develop an entirely new policy. > > What's the recommended solution to this? Can we get the audit functionality > enabled through printk early in the boot process (IE in the first few lines > of rc.sysinit)? The kernel defaults to using printk if no audit daemon is registered. But you need to boot with audit=1 to enable syscall auditing or run auditctl -e 1 or auditd very early to enable it. Dave Woodhouse has a patch to restore logging of the pid and comm to avc_audit(), which can be safely done (unlike the exe). We could upstream that patch possibly, as it reduces the impact of the change on users. -- Stephen Smalley National Security Agency From linux at mikropro.com Mon May 16 11:47:13 2005 From: linux at mikropro.com (Emek TUZUN) Date: Mon, 16 May 2005 14:47:13 +0300 Subject: Mysql setsched Message-ID: <01ac01c55a0d$0076af60$f4e6fea9@Mehmet> What is SETSCHED fuction of MySql? I am getting these logs but mysql works normal... What are these setsched denials? May 16 01:39:04 xstream kernel: audit(1116243944.356:0): avc: denied { setsched } for pid=18216 exe=/usr/sbin/mysqld scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t tclass=process May 16 01:39:18 xstream kernel: audit(1116243958.654:0): avc: denied { setsched } for pid=18228 exe=/usr/sbin/mysqld scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t tclass=process May 16 01:39:30 xstream kernel: audit(1116243970.083:0): avc: denied { setsched } for pid=18229 exe=/usr/sbin/mysqld scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t tclass=process Thanks in advance, Emek -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Mon May 16 12:11:27 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 16 May 2005 08:11:27 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505160106.32177.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> Message-ID: <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote: > I've found the problem. > > The domain anaconda_t seems to be unused (we should probably just delete > anaconda.te). The installation process runs all initial programs from an > initrd (gzip compressed cpio file). cpio has no support for SE Linux labels > so no domain transitions occur and everything runs in kernel_t. Everything > that's not in an initrd is in a cramfs file system (which also has no support > for SE Linux labelling). This means that created files get the type of the > directory - etc_t in the case of /etc/ld.so.cache. initrd or initramfs? Sounds like the latter from your description. An initrd should be able to support a labeled filesystem like ext2, unlike initramfs. By created files, you just mean runtime-generated files, right? Any files set down by rpm should be labeled explicitly and correctly by it. > One possible method of dealing with this would be the following: > domain_auto_trans(kernel_t, ldconfig_exec_t, ldconfig_t) Is ldconfig labeled correctly at this point? Is this an ldconfig that is installed by rpm on the disk (vs. one from the initramfs)? > The other option is to run restorecon at the end of the install. Both options > are ugly hacks. Applying restorecon selectively to runtime-generated files wouldn't be too bad. > Given that we aren't doing anything with SE Linux at the install the best > option is probably to create a policy that defines all file types with a > single domain that can have read/write access to them, this will save space > in the stage2 files and also precious RAM (currently installing to a machine > with 64M of RAM is almost impossible, and 4176K of that problem is the SE > Linux policy). In that case, do you need to enable SELinux in the kernel at all for installation? As long as the kernel provides the xattr API and the filesystem supports the security xattrs, rpm should be able to label all files it installs even with a SELinux-disabled kernel (although you might have to remove an is_selinux_enabled() test from rpm to make it do that). With SELinux disabled, you don't need to load a policy at all to set the file contexts. But how does simplifying the install policy (or disabling SELinux altogether during install) address the problem of runtime-created files like /etc/ld.so.cache? > I've attached a little Perl script that will munge a targeted policy. It > replaces most type and domain definitions with typealias rules and reduces > the policy binary size from 4176K to 60K. That saves 4116K of kernel memory > and almost 700K on the cramfs. The saving of 4M of kernel memory will make a > huge difference to the install on small machines. Currently it's almost > impossible to install a FC4 test version on a machine with 64M of RAM, this > change will give the same result as adding another 4M of RAM to machines for > the installer (particularly important for machines that run out of RAM before > completing the partitioning process). As you discovered, SELinux only uses type aliases to allow applications and users to specify alternative names; internally, it always canonicalizes to the primary type name. It is true that you can presently set the context to a type alias on disk (but only because the xattr API goes straight to the filesystem code and doesn't give SELinux an opportunity to canonicalize the attribute value, unlike the old SELinux API), but newly created files will always get the primary name. Aside from that, I'm not adverse to compressing the policy (although I would think that collapsing all domains and reducing to a minimal set of allow rules would achieve that) for installation, although it would be even simpler if you could just install with SELinux disabled in the kernel and thus avoid requiring loading a policy at all. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon May 16 12:20:10 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 16 May 2005 08:20:10 -0400 Subject: Mysql setsched In-Reply-To: <01ac01c55a0d$0076af60$f4e6fea9@Mehmet> References: <01ac01c55a0d$0076af60$f4e6fea9@Mehmet> Message-ID: <1116246010.28782.48.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-16 at 14:47 +0300, Emek TUZUN wrote: > What is SETSCHED fuction of MySql? > > I am getting these logs but mysql works normal... What are these > setsched denials? > > May 16 01:39:04 xstream kernel: audit(1116243944.356:0): avc: denied > { setsched } for pid=18216 exe=/usr/sbin/mysqld > scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t > tclass=process > May 16 01:39:18 xstream kernel: audit(1116243958.654:0): avc: denied > { setsched } for pid=18228 exe=/usr/sbin/mysqld > scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t > tclass=process > May 16 01:39:30 xstream kernel: audit(1116243970.083:0): avc: denied > { setsched } for pid=18229 exe=/usr/sbin/mysqld > scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t > tclass=process Attempts to change priority via nice(2) or scheduling information via sched_setscheduler(2). You can get more information about the denial by enabling syscall auditing (auditctl -e 1) and running mysqld again. If mysqld is just lowering its priority, then this should be allowed in the policy. -- Stephen Smalley National Security Agency From russell at coker.com.au Mon May 16 12:45:08 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 16 May 2005 22:45:08 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200505162245.13035.russell@coker.com.au> On Monday 16 May 2005 22:11, Stephen Smalley wrote: > On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote: > > I've found the problem. > > > > The domain anaconda_t seems to be unused (we should probably just delete > > anaconda.te). The installation process runs all initial programs from an > > initrd (gzip compressed cpio file). cpio has no support for SE Linux > > labels so no domain transitions occur and everything runs in kernel_t. > > Everything that's not in an initrd is in a cramfs file system (which also > > has no support for SE Linux labelling). This means that created files > > get the type of the directory - etc_t in the case of /etc/ld.so.cache. > > initrd or initramfs? Sounds like the latter from your description. An > initrd should be able to support a labeled filesystem like ext2, unlike > initramfs. initrd. Sure an initrd can support ext2 with labels, but that's not being done at the moment and such a significant change is unlikely to be made to the installer in a hurry. > By created files, you just mean runtime-generated files, right? Any > files set down by rpm should be labeled explicitly and correctly by it. Yes. > > One possible method of dealing with this would be the following: > > domain_auto_trans(kernel_t, ldconfig_exec_t, ldconfig_t) > > Is ldconfig labeled correctly at this point? Is this an ldconfig that > is installed by rpm on the disk (vs. one from the initramfs)? Yes, it SHOULD be labeled correctly. I haven't verified it (verifying exactly what happens at each stage of the install is painful), but it's supposed to be labeled and I have no reason to expect it not to be. > > The other option is to run restorecon at the end of the install. Both > > options are ugly hacks. > > Applying restorecon selectively to runtime-generated files wouldn't be > too bad. True. It seems likely that we will have to do that regardless (see my next message). > > Given that we aren't doing anything with SE Linux at the install the best > > option is probably to create a policy that defines all file types with a > > single domain that can have read/write access to them, this will save > > space in the stage2 files and also precious RAM (currently installing to > > a machine with 64M of RAM is almost impossible, and 4176K of that problem > > is the SE Linux policy). > > In that case, do you need to enable SELinux in the kernel at all for > installation? As long as the kernel provides the xattr API and the > filesystem supports the security xattrs, rpm should be able to label all > files it installs even with a SELinux-disabled kernel (although you > might have to remove an is_selinux_enabled() test from rpm to make it do > that). With SELinux disabled, you don't need to load a policy at all to > set the file contexts. True. But with SE Linux disabled I believe that files which are created by programs that are not SE Linux aware (IE the %post scripts run from RPM packages) will not have any labels. Thus we would create another problem of how to get those files labeled. Currently we have about a dozen files that have issues and an "everything" install might turn up another few dozen. If we have SE Linux disabled then we can expect hundreds or maybe thousands. It will be significantly more painful. We can manage a list of a dozen problem files that occasionally changes. We can't manage a list of a few thousand files that change more frequently in proportion to their number. > But how does simplifying the install policy (or disabling SELinux > altogether during install) address the problem of runtime-created files > like /etc/ld.so.cache? It doesn't. I investigated the issue and went off on a tangent. But these things are linked and need to be solved at the same time. > Aside from that, I'm not adverse to compressing the policy (although I > would think that collapsing all domains and reducing to a minimal set of > allow rules would achieve that) for installation, although it would be > even simpler if you could just install with SELinux disabled in the > kernel and thus avoid requiring loading a policy at all. My script does collapse all domains. As for a minimal set of allow rules, I guess if we turn off auditing of AVC messages we could just remove all allow and dontaudit rules. It's a hack, but that's the way the install process goes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at tycho.nsa.gov Mon May 16 12:41:15 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 16 May 2005 08:41:15 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505162245.13035.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> <200505162245.13035.russell@coker.com.au> Message-ID: <1116247275.28782.64.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-16 at 22:45 +1000, Russell Coker wrote: > My script does collapse all domains. As for a minimal set of allow rules, I > guess if we turn off auditing of AVC messages we could just remove all allow > and dontaudit rules. It's a hack, but that's the way the install process > goes. I don't think that there is a way to turn off auditing of AVC messages globally (you need dontaudit rules, and they have to specify the relevant types, classes, and permissions). -- Stephen Smalley National Security Agency From russell at coker.com.au Mon May 16 14:11:39 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 May 2005 00:11:39 +1000 Subject: files without SE Linux labels on a default install - no Anaconda labeling Message-ID: <200505170011.41762.russell@coker.com.au> On an SE Linux system barring file system corruption and quota issues every file on a regular file system (Ext3 etc) should have a SE Linux label. As a test I did a default install of FC4T3 in the "Personal Workstation" configuration and checked this. Below is the relevant output from setfiles -v when relabelling the root file system. It seems to me that /usr/share/apps/ksplash, /usr/share/apps/ksplash/Themes, /usr/share/anaconda, /usr/share/anaconda/pixmaps, /usr/lib/anaconda-runtime, /usr/lib/anaconda-runtime/boot, and the install logs are created by Anaconda which doesn't apply SE Linux labels. Would it be possible to get Anaconda changed to apply labels to files and directories that it creates? I have no idea why the Portuguese Brazilian language file didn't get a label when all the other language files did. I have attached a list of all the files which aren't correctly labeled after a default targeted install which I haven't dealt with in other messages. NB this includes /etc/shadow... setfiles: relabeling /usr/share/apps/ksplash from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/apps/ksplash/Themes from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/anaconda from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/anaconda/pixmaps from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/lib/anaconda-runtime from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /usr/lib/anaconda-runtime/boot from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /usr/X11R6/lib/X11/locale/pt_BR.UTF-8 from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /root/install.log from system_u:object_r:file_t to root:object_r:user_home_t setfiles: relabeling /root/install.log.syslog from system_u:object_r:file_t to root:object_r:user_home_t -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- setfiles: relabeling /usr/share/apps/ksplash from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/apps/ksplash/Themes from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/anaconda from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/share/anaconda/pixmaps from system_u:object_r:file_t to system_u:object_r:usr_t setfiles: relabeling /usr/lib/anaconda-runtime from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /usr/lib/anaconda-runtime/boot from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /usr/X11R6/lib/X11/locale/pt_BR.UTF-8 from system_u:object_r:file_t to system_u:object_r:lib_t setfiles: relabeling /root/install.log from system_u:object_r:file_t to root:object_r:user_home_t setfiles: relabeling /root/install.log.syslog from system_u:object_r:file_t to root:object_r:user_home_t setfiles: relabeling /etc/ssh/ssh_host_key from system_u:object_r:etc_runtime_t to system_u:object_r:sshd_key_t setfiles: relabeling /etc/ssh/ssh_host_rsa_key from system_u:object_r:etc_runtime_t to system_u:object_r:sshd_key_t setfiles: relabeling /etc/ssh/ssh_host_dsa_key from system_u:object_r:etc_runtime_t to system_u:object_r:sshd_key_t setfiles: relabeling /etc/asound.conf from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t setfiles: relabeling /etc/shadow from system_u:object_r:etc_t to system_u:object_r:shadow_t setfiles: relabeling /etc/gshadow- from system_u:object_r:etc_t to system_u:object_r:shadow_t setfiles: relabeling /etc/cups/cupsd.conf from system_u:object_r:cupsd_etc_t to system_u:object_r:cupsd_rw_etc_t setfiles: relabeling /etc/cups/printers.conf from system_u:object_r:cupsd_etc_t to system_u:object_r:cupsd_rw_etc_t setfiles: relabeling /etc/cups/cupsd.conf.save from system_u:object_r:cupsd_etc_t to system_u:object_r:cupsd_rw_etc_t setfiles: relabeling /etc/aliases.db from system_u:object_r:etc_t to system_u:object_r:etc_aliases_t setfiles: relabeling /etc/shadow- from system_u:object_r:etc_t to system_u:object_r:shadow_t setfiles: relabeling /etc/gshadow from system_u:object_r:etc_t to system_u:object_r:shadow_t setfiles: relabeling /etc/.pwd.lock from system_u:object_r:etc_t to system_u:object_r:shadow_t setfiles: relabeling /etc/dhclient-eth0.conf from system_u:object_r:etc_runtime_t to system_u:object_r:dhcp_etc_t setfiles: relabeling /etc/sysconfig/mouse from system_u:object_r:etc_runtime_t to system_u:object_r:etc_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.dep from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.ieee1394map from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.usbmap from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.inputmap from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.isapnpmap from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.symbols from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.ccwmap from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.alias from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /lib/modules/2.6.11-1.1286_FC4/modules.pcimap from system_u:object_r:modules_object_t to system_u:object_r:modules_dep_t setfiles: relabeling /home/rjc from system_u:object_r:home_root_t to user_u:object_r:user_home_dir_t setfiles: relabeling /var/run/sm-client.pid from system_u:object_r:initrc_var_run_t to system_u:object_r:sendmail_var_run_t setfiles: relabeling /var/log/lastlog from system_u:object_r:var_log_t to system_u:object_r:lastlog_t setfiles: relabeling /var/log/btmp from system_u:object_r:var_log_t to system_u:object_r:faillog_t setfiles: relabeling /var/log/mail from system_u:object_r:var_log_t to system_u:object_r:sendmail_log_t From Valdis.Kletnieks at vt.edu Mon May 16 14:36:44 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 16 May 2005 10:36:44 -0400 Subject: A problem with telnet connection In-Reply-To: Your message of "Mon, 16 May 2005 12:20:08 +0200." <524c9b2a050516032014473217@mail.gmail.com> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <200505160309.09114.russell@coker.com.au> <524c9b2a050516032014473217@mail.gmail.com> Message-ID: <200505161436.j4GEajcB020934@turing-police.cc.vt.edu> On Mon, 16 May 2005 12:20:08 +0200, Cigliano Andrea said: > I have a problem with my telnetd configuration. When any telnet client > connect to my telnet server after one/two minutes (or less) the > connection going down (there isnt firewall started). If it lives a whole minute, it's probably not directly an SELinux problem (particularly true if you're not seeing any 'avc' messages in the system log). If you have an avc message, post it so we can figure out what the problem is. If you don't, I'd suggest getting a tcpdump of the traffic and re-asking in a network support list. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From russell at coker.com.au Mon May 16 14:53:53 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 May 2005 00:53:53 +1000 Subject: A problem with telnet connection In-Reply-To: <524c9b2a050516032014473217@mail.gmail.com> References: <200505140246.36294.russell@coker.com.au> <200505160309.09114.russell@coker.com.au> <524c9b2a050516032014473217@mail.gmail.com> Message-ID: <200505170053.57528.russell@coker.com.au> On Monday 16 May 2005 20:20, Cigliano Andrea wrote: > I have a problem with my telnetd configuration. When any telnet client When you want to start a new topic of discussion on a mailing list please make sure you enter a new message. Do not reply to a message on the list as that messes up threads. Also do not attach files (such as my tiny.pl) to messages without good cause. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at tycho.nsa.gov Mon May 16 15:27:49 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 16 May 2005 11:27:49 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116256384.9888.12.camel@localhost.localdomain> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> Message-ID: <1116257269.28782.79.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-16 at 11:13 -0400, Peter Jones wrote: > Anaconda has been using initramfs for boot media since November. Are > you sure you mean initrd? > > Regardless of that, why isn't ld.so.cache's context getting set > correctly from the data in the glibc package? It is a runtime-created file, and ldconfig is not specifically modified to set the security context on it, so it just follows the default behavior, i.e. if there is a file type transition rule for the creating domain and the parent directory type, then apply the resulting type (which is what normally happens when ldconfig is run in the ldconfig_t domain); otherwise, inherit the type from the parent directory. In this case, it seems that ldconfig is not running in its domain because the caller isn't in the expected domain because the calling sequence never transitioned out of kernel_t due to the lack of labeling on the initramfs. At least that is what I gleaned from Russell's posting. -- Stephen Smalley National Security Agency From russell at coker.com.au Mon May 16 15:44:41 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 May 2005 01:44:41 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116256384.9888.12.camel@localhost.localdomain> References: <200505140246.36294.russell@coker.com.au> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> Message-ID: <200505170144.46594.russell@coker.com.au> On Tuesday 17 May 2005 01:13, Peter Jones wrote: > > initrd. Sure an initrd can support ext2 with labels, but that's not > > being done at the moment and such a significant change is unlikely to be > > made to the installer in a hurry. > > Anaconda has been using initramfs for boot media since November. Are > you sure you mean initrd? That was my understanding of it, I thought that initrd=whatever for the boot loaded made it use initrd. Could you please give me a URL for the correct information. > Regardless of that, why isn't ld.so.cache's context getting set > correctly from the data in the glibc package? The cache file is created by ldconfig. So it's not an issue of the glibc package or RPM. We could patch ldconfig to specifically request the context we desire (using the same mechanism that rpm uses to determine the correct file type), but that seems like a waste as such code would only be needed for the install. file_type_auto_trans(ldconfig_t, etc_t, ld_so_cache_t, file) In normal operation the ldconfig program runs in domain ldconfig_t. The above SE Linux policy specifies that when domain ldconfig_t creates a file in a directory of type etc_t the file type should be ld_so_cache_t. Currently during the install everything runs in kernel_t (including ldconfig) so the policy in question does not apply. The options to solve this are to hack the policy or to run restorecon at the end of the install. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Mon May 16 15:46:37 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 May 2005 01:46:37 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116257269.28782.79.camel@moss-spartans.epoch.ncsc.mil> References: <200505140246.36294.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> <1116257269.28782.79.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200505170146.42815.russell@coker.com.au> On Tuesday 17 May 2005 01:27, Stephen Smalley wrote: > It is a runtime-created file, and ldconfig is not specifically modified > to set the security context on it, so it just follows the default > behavior, i.e. if there is a file type transition rule for the creating > domain and the parent directory type, then apply the resulting type > (which is what normally happens when ldconfig is run in the ldconfig_t > domain); otherwise, inherit the type from the parent directory. In this > case, it seems that ldconfig is not running in its domain because the > caller isn't in the expected domain because the calling sequence never > transitioned out of kernel_t due to the lack of labeling on the > initramfs. At least that is what I gleaned from Russell's posting. Yes. However although the kernel_t domain is used for everything the programs being run will all be from the chroot environment and thus have the correct types. Therefore ldconfig_exec_t will be used for the ldconfig program and we can do a domain transition on it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From pjones at redhat.com Mon May 16 15:13:04 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 16 May 2005 11:13:04 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505162245.13035.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116245487.28782.42.camel@moss-spartans.epoch.ncsc.mil> <200505162245.13035.russell@coker.com.au> Message-ID: <1116256384.9888.12.camel@localhost.localdomain> On Mon, 2005-05-16 at 22:45 +1000, Russell Coker wrote: > On Monday 16 May 2005 22:11, Stephen Smalley wrote: > > On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote: > > > I've found the problem. > > > > > > The domain anaconda_t seems to be unused (we should probably just delete > > > anaconda.te). The installation process runs all initial programs from an > > > initrd (gzip compressed cpio file). cpio has no support for SE Linux > > > labels so no domain transitions occur and everything runs in kernel_t. > > > Everything that's not in an initrd is in a cramfs file system (which also > > > has no support for SE Linux labelling). This means that created files > > > get the type of the directory - etc_t in the case of /etc/ld.so.cache. > > > > initrd or initramfs? Sounds like the latter from your description. An > > initrd should be able to support a labeled filesystem like ext2, unlike > > initramfs. > > initrd. Sure an initrd can support ext2 with labels, but that's not being > done at the moment and such a significant change is unlikely to be made to > the installer in a hurry. Anaconda has been using initramfs for boot media since November. Are you sure you mean initrd? Regardless of that, why isn't ld.so.cache's context getting set correctly from the data in the glibc package? -- Peter From katzj at redhat.com Mon May 16 19:35:26 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 May 2005 15:35:26 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505160106.32177.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> Message-ID: <1116272126.3360.18.camel@bree.local.net> On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote: > The domain anaconda_t seems to be unused (we should probably just delete > anaconda.te). The installation process runs all initial programs from an > initrd (gzip compressed cpio file). cpio has no support for SE Linux labels > so no domain transitions occur and everything runs in kernel_t. Everything > that's not in an initrd is in a cramfs file system (which also has no support > for SE Linux labelling). This means that created files get the type of the > directory - etc_t in the case of /etc/ld.so.cache. We never used label'ing of things in the initrd when it was an ext2 image. The loader explicitly sets the exec context before running anaconda to be system_u:object_r:anaconda_t if policy doesn't fail to load. Look in /tmp/anaconda.log (or tty3) for errors about loading the policy or setting the context. Jeremy From katzj at redhat.com Mon May 16 19:36:29 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 May 2005 15:36:29 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505170144.46594.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> <200505170144.46594.russell@coker.com.au> Message-ID: <1116272189.3360.20.camel@bree.local.net> On Tue, 2005-05-17 at 01:44 +1000, Russell Coker wrote: > On Tuesday 17 May 2005 01:13, Peter Jones wrote: > > > initrd. Sure an initrd can support ext2 with labels, but that's not > > > being done at the moment and such a significant change is unlikely to be > > > made to the installer in a hurry. > > > > Anaconda has been using initramfs for boot media since November. Are > > you sure you mean initrd? > > That was my understanding of it, I thought that initrd=whatever for the boot > loaded made it use initrd. Could you please give me a URL for the correct > information. The initramfs is loaded using the protocol for loading initrds (ie, placing a blob at a certain location in memory by the bootloader instead of munging the kernel binary to have the initrd stuck at the end of it). Jeremy From r.godzilla at comcast.net Mon May 16 21:14:19 2005 From: r.godzilla at comcast.net (Richard E Miles) Date: Mon, 16 May 2005 14:14:19 -0700 Subject: postgresql postmaster denied write access Message-ID: <20050516141419.7d612bef.r.godzilla@comcast.net> I am running FC3 with targetted policy. When I try to start the postgresql server I get avc: denied { write } messages in the system log. ie: May 16 14:07:23 localhost kernel: audit(1116277643.114:0): avc: denied { write } for pid=13355 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 16 14:07:23 localhost kernel: audit(1116277643.115:0): avc: denied { write } for pid=13355 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 16 14:07:23 localhost last message repeated 34 times May 16 14:07:23 localhost kernel: audit(1116277643.116:0): avc: denied { write } for pid=13355 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 16 14:07:23 localhost last message repeated 37 times May 16 14:07:23 localhost kernel: audit(1116277643.117:0): avc: denied { write } for pid=13355 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir May 16 14:07:23 localhost last message repeated 27 times May 16 14:07:24 localhost pam_timestamp_check: pam_timestamp: `/' owner UID != 0 Is there a problem with the tagetted policy that prevents me from using postgresql? Thank you -- Richard E Miles Federal Way WA. USA registered linux user 46097 From katzj at redhat.com Tue May 17 00:43:31 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 May 2005 20:43:31 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116265016.15526.3.camel@localhost.localdomain> References: <200505140246.36294.russell@coker.com.au> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> <200505170144.46594.russell@coker.com.au> <1116265016.15526.3.camel@localhost.localdomain> Message-ID: <1116290611.3360.33.camel@bree.local.net> On Mon, 2005-05-16 at 13:36 -0400, Peter Jones wrote: > On Tue, 2005-05-17 at 01:44 +1000, Russell Coker wrote: > > On Tuesday 17 May 2005 01:13, Peter Jones wrote: > > > > initrd. Sure an initrd can support ext2 with labels, but that's not > > > > being done at the moment and such a significant change is unlikely to be > > > > made to the installer in a hurry. > > > > > > Anaconda has been using initramfs for boot media since November. Are > > > you sure you mean initrd? > > > > That was my understanding of it, I thought that initrd=whatever for the boot > > loaded made it use initrd. Could you please give me a URL for the correct > > information. > > I don't have a url, but if you look at linux/init/initramfs.c, it > appears to just check the magic bytes for the filesystem in whatever you > pass it; if it's a cramfs image, it uses initramfs. Correction: cramfs has nothing to do with an initramfs. An initramfs is just a gzipped cpio archive that gets exploded out onto the default kernel rootfs. Jeremy From russell at coker.com.au Tue May 17 04:05:29 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 17 May 2005 14:05:29 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116272126.3360.18.camel@bree.local.net> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116272126.3360.18.camel@bree.local.net> Message-ID: <200505171405.34672.russell@coker.com.au> On Tuesday 17 May 2005 05:35, Jeremy Katz wrote: > On Mon, 2005-05-16 at 01:06 +1000, Russell Coker wrote: > > The domain anaconda_t seems to be unused (we should probably just delete > > anaconda.te). The installation process runs all initial programs from an > > initrd (gzip compressed cpio file). cpio has no support for SE Linux > > labels so no domain transitions occur and everything runs in kernel_t. > > Everything that's not in an initrd is in a cramfs file system (which also > > has no support for SE Linux labelling). This means that created files > > get the type of the directory - etc_t in the case of /etc/ld.so.cache. > > We never used label'ing of things in the initrd when it was an ext2 > image. The loader explicitly sets the exec context before running > anaconda to be system_u:object_r:anaconda_t if policy doesn't fail to > load. Look in /tmp/anaconda.log (or tty3) for errors about loading the > policy or setting the context. That's an invalid context. The correct value should be system_u:system_r:anaconda_t. The role object_r is only suitable for files on disk. The kernel does allow setting it though. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at tycho.nsa.gov Tue May 17 12:17:39 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 17 May 2005 08:17:39 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116265016.15526.3.camel@localhost.localdomain> References: <200505140246.36294.russell@coker.com.au> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> <200505170144.46594.russell@coker.com.au> <1116265016.15526.3.camel@localhost.localdomain> Message-ID: <1116332259.917.33.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-05-16 at 13:36 -0400, Peter Jones wrote: > Why can't the glibc package provide a ld.so.cache which simply indicates > no libraries? This seems more correct to me, especially as it claims > ownership of the file. That won't help if ldconfig re-creates the file each time (vs. just rewriting the existing file in place), as the new file would still be labeled in accordance with the default behavior unless ldconfig were modified. But in any event, it sounds like we need to determine why ldconfig isn't running the proper domain, as that would suffice to ensuring that ld.so.cache is labeled properly. -- Stephen Smalley National Security Agency From pjones at redhat.com Mon May 16 17:36:55 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 16 May 2005 13:36:55 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505170144.46594.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505162245.13035.russell@coker.com.au> <1116256384.9888.12.camel@localhost.localdomain> <200505170144.46594.russell@coker.com.au> Message-ID: <1116265016.15526.3.camel@localhost.localdomain> On Tue, 2005-05-17 at 01:44 +1000, Russell Coker wrote: > On Tuesday 17 May 2005 01:13, Peter Jones wrote: > > > initrd. Sure an initrd can support ext2 with labels, but that's not > > > being done at the moment and such a significant change is unlikely to be > > > made to the installer in a hurry. > > > > Anaconda has been using initramfs for boot media since November. Are > > you sure you mean initrd? > > That was my understanding of it, I thought that initrd=whatever for the boot > loaded made it use initrd. Could you please give me a URL for the correct > information. I don't have a url, but if you look at linux/init/initramfs.c, it appears to just check the magic bytes for the filesystem in whatever you pass it; if it's a cramfs image, it uses initramfs. > > Regardless of that, why isn't ld.so.cache's context getting set > > correctly from the data in the glibc package? > > The cache file is created by ldconfig. So it's not an issue of the glibc > package or RPM. We could patch ldconfig to specifically request the context > we desire (using the same mechanism that rpm uses to determine the correct > file type), but that seems like a waste as such code would only be needed for > the install. Why can't the glibc package provide a ld.so.cache which simply indicates no libraries? This seems more correct to me, especially as it claims ownership of the file. -- Peter From pjones at redhat.com Tue May 17 17:45:40 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 17 May 2005 13:45:40 -0400 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505171405.34672.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> <200505160106.32177.russell@coker.com.au> <1116272126.3360.18.camel@bree.local.net> <200505171405.34672.russell@coker.com.au> Message-ID: <1116351940.8907.6.camel@localhost.localdomain> On Tue, 2005-05-17 at 14:05 +1000, Russell Coker wrote: > On Tuesday 17 May 2005 05:35, Jeremy Katz wrote: > > We never used label'ing of things in the initrd when it was an ext2 > > image. The loader explicitly sets the exec context before running > > anaconda to be system_u:object_r:anaconda_t if policy doesn't fail to > > load. Look in /tmp/anaconda.log (or tty3) for errors about loading the > > policy or setting the context. > > That's an invalid context. The correct value should be > system_u:system_r:anaconda_t. The role object_r is only suitable for files > on disk. The kernel does allow setting it though. Fixed in cvs. -- Peter From rhallyx at mindspring.com Tue May 17 19:54:34 2005 From: rhallyx at mindspring.com (Richard Hally) Date: Tue, 17 May 2005 15:54:34 -0400 Subject: mozilla mail not starting under strict policy Message-ID: <428A4BFA.3090704@mindspring.com> when running strict policy on a fully updated rawhide, mozilla mail will not start when in enforcing mode of the strict policy. Doing a setenforce 0 allows it to start. (Note that the avc denied messages are only produce when in premissive mode) Below are the AVC denied messages: May 17 12:46:45 new2 kernel: audit(1116348405.108:0): avc: granted { setenforce } for scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security May 17 12:46:45 new2 dbus: avc: received setenforce notice (enforcing=0) May 17 12:46:45 new2 dbus: avc: received setenforce notice (enforcing=0) May 17 12:46:56 new2 kernel: audit(1116348416.169:0): avc: denied { name_connect } for dest=110 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:pop_port_t tclass=tcp_socket May 17 12:46:56 new2 kernel: audit(1116348416.902:0): avc: denied { getattr } for name=/ dev=dm-0 ino=2 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:fs_t tclass=filesystem May 17 12:47:45 new2 kernel: audit(1116348465.718:0): avc: granted { setenforce } for scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security May 17 12:47:45 new2 dbus: avc: received setenforce notice (enforcing=1) May 17 12:47:45 new2 dbus: avc: received setenforce notice (enforcing=1) HTH Richard Hally From russell at coker.com.au Wed May 18 06:32:02 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 18 May 2005 16:32:02 +1000 Subject: SE Linux installer changes needed - was Re: /etc/ld.so.cache and FC4T3 In-Reply-To: <1116351940.8907.6.camel@localhost.localdomain> References: <200505140246.36294.russell@coker.com.au> <200505171405.34672.russell@coker.com.au> <1116351940.8907.6.camel@localhost.localdomain> Message-ID: <200505181632.07374.russell@coker.com.au> On Wednesday 18 May 2005 03:45, Peter Jones wrote: > On Tue, 2005-05-17 at 14:05 +1000, Russell Coker wrote: > > On Tuesday 17 May 2005 05:35, Jeremy Katz wrote: > > > We never used label'ing of things in the initrd when it was an ext2 > > > image. The loader explicitly sets the exec context before running > > > anaconda to be system_u:object_r:anaconda_t if policy doesn't fail to > > > load. Look in /tmp/anaconda.log (or tty3) for errors about loading the > > > policy or setting the context. > > > > That's an invalid context. The correct value should be > > system_u:system_r:anaconda_t. The role object_r is only suitable for > > files on disk. The kernel does allow setting it though. > > Fixed in cvs. I've discovered the root cause of the problem. anaconda.te seems to have been removed from the targeted policy so there is no anaconda_t domain in the policy used for installation. Ideally we want anaconda.te included in the policy for installation but excluded from the policy used for running the system. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From lfarkas at bppiac.hu Wed May 18 08:21:03 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Wed, 18 May 2005 10:21:03 +0200 Subject: dhcpd and nscd bug Message-ID: <428AFAEF.4030501@bppiac.hu> hi, it seems that during startup dhcpd server try to read nscd's pid files (i don't know why?): ----------------------------------------------- May 15 00:20:32 atom kernel: audit(1116109232.315:0): avc: denied { search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 scontext=system_u:system_r:dhcpd_t tcontext=system_u:object_r:nscd_var_run_t tclass=dir May 15 00:20:32 atom kernel: audit(1116109232.316:0): avc: denied { search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 scontext=system_u:system_r:dhcpd_t tcontext=system_u:object_r:nscd_var_run_t tclass=dir ----------------------------------------------- and inode 3777358 is /var/run/nscd directory. so it'd be useful to add this rule to the dhcpd policy: allow dhcpd_t nscd_var_run_t:dir search; yours. -- Levente "Si vis pacem para bellum!" From ivg2 at cornell.edu Wed May 18 08:29:45 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 18 May 2005 04:29:45 -0400 Subject: dhcpd and nscd bug In-Reply-To: <428AFAEF.4030501@bppiac.hu> References: <428AFAEF.4030501@bppiac.hu> Message-ID: <1116404985.20544.1.camel@localhost.localdomain> On Wed, 2005-05-18 at 10:21 +0200, Farkas Levente wrote: > hi, > it seems that during startup dhcpd server try to read nscd's pid files > (i don't know why?): > ----------------------------------------------- > May 15 00:20:32 atom kernel: audit(1116109232.315:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 > scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > May 15 00:20:32 atom kernel: audit(1116109232.316:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 > scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > ----------------------------------------------- > and inode 3777358 is /var/run/nscd directory. so it'd be useful to add > this rule to the dhcpd policy: > allow dhcpd_t nscd_var_run_t:dir search; > yours. needs nscd_client_domain attribute. -- Ivan Gyurdiev Cornell University From dwalsh at redhat.com Wed May 18 12:20:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 08:20:53 -0400 Subject: /tmp/gconfd-* : wrong type after 'augmenting' user In-Reply-To: <4c4ba15305051511497b285c8e@mail.gmail.com> References: <4c4ba15305051511497b285c8e@mail.gmail.com> Message-ID: <428B3325.7000504@redhat.com> Tom London wrote: >Running strict/enforcing, latest rawhide. > >I changed an existing user to a 'sysadm' user by adding to >local.users, rebuilt/installed new policy, and did a 'restorecon -v >-R' of home directory, /etc, /tmp, .... > >On reboot, logging shows that the preexisting /tmp/gconfd-XXX >remained labeled as 'user_u:....'. > >Removing it (and several 'aumix*' files that were similarly labeled), >and rebooting 'fixed' this. > >Is this the best, or does it make sense to considering adding 'per >user' rules for such files? > >tom > > Currently autorelabel removes all files from /tmp/ for this reason. Ivan is working on some fixes for this, and per user /tmp might help also. Dan -- From dwalsh at redhat.com Wed May 18 12:28:41 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 08:28:41 -0400 Subject: vsftpd with selinux on FC3 In-Reply-To: <8a239a560505142055ce251ac@mail.gmail.com> References: <8a239a560505142055ce251ac@mail.gmail.com> Message-ID: <428B34F9.5000707@redhat.com> James Z. Li wrote: >Hi there, > >I am configuring Selinux to protect vsftpd on my FC3 box. I follow the >procedure of >Chapter 8 Cutermizing and Writing Policy in Red Hat Enterprise Linux >SELinux Guide. > >Step1: i created a file called >/etc/selinux/targeted/src/policy/domains/program/vsftpd.te >the cotents are >################################# ># ># Rules for the vsftpd_t domain. ># >daemon_domain(vsftpd) > >the security context of this file was root:object_r:policy_src_t > > It should stay this. >I changed it by using >chcon -u system_u vsftpd.te > >Step2: create /etc/selinux/targeted/src/policy/file_contexts/program/vsftpd.fc >contents are >/usr/sbin/vsftpd -- system_u:object_r:vsftpd_exec_t >/var/run/vsftpd.pid -- system_u:object_r:vsftpd_var_run_t >/etc/vsftpd/vsftpd.conf -- system_u:object_r:vsftpd_conf_t > >chcon -u system_u vsftpd.fc > > > User context will not matter. >At this moment, the security context of /etc/vsftpd and vsftpd.conf are: ># ls -dZ /etc/vsftpd >drwxr-xr-x root root system_u:object_r:etc_t /etc/vsftpd > >ls -Z /etc/vsftpd/vsftpd.conf >-rw------- root root system_u:object_r:etc_t >/etc/vsftpd/vsftpd.conf > >Step3: #make load >Error message: >... >Validating file_contexts ... >/usr/sbin/setfiles -q -c /etc/selinux/targeted/policy/policy.18 >/etc/selinux/tar geted/contexts/files/file_contexts >/usr/sbin/setfiles: invalid context system_u:object_r:vsftpd_conf_t >on line num ber 785 >make: *** [install] Error 1 > > > First do you want to protect vsftpd_conf_t from other domains reading it? If you don't set this context it will default to etc_t and almost no other domains will be able to write it. If you want to add a file context you would need to create it in the te file. type vsftpd_conf_t, file_type, sysadmfile; I would not advise this, and would just leave it etc_t. >Could anyone help me on this? Thanks a lot! > >Btw, should I set the security context of /etc/vsftpd/vsftpd.conf to >vsftpd_conf_t >or vsftpd_etc_t? I am confused about some existing context, such as > >#ls -dZ /etc/httpd/ >drwxr-xr-x root root system_u:object_r:httpd_config_t /etc/httpd/ >#ls -Z /etc/httpd/conf/httpd.conf >-rw-r--r-- root root system_u:object_r:httpd_config_t >/etc/httpd/conf/httpd.conf > >BUT, ># ls -dZ /etc/snmp/ >drwxr-xr-x root root system_u:object_r:etc_t /etc/snmp/ ># ls -Z /etc/snmp/snmpd.conf >-rw-r--r-- root root system_u:object_r:snmpd_etc_t >/etc/snmp/snmpd.conf > > > Usually I would only setup an conf file or etc file if a certain domain needs the ability to write to it. BTW if you look at strict policy, there is a ftpd context that works on vsftpd. I would recommend you look at the one in rawhide. >Thanks, > >James > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From sds at tycho.nsa.gov Wed May 18 12:24:50 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 18 May 2005 08:24:50 -0400 Subject: nVidia drivers and xorg In-Reply-To: <1116397969.4857.11.camel@localhost> References: <1116373655.4857.1.camel@localhost> <1116386396.7094.1.camel@fluffbox.fluffnet> <1116397969.4857.11.camel@localhost> Message-ID: <1116419090.3998.23.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-05-18 at 07:32 +0100, Paul wrote: > One interesting thing on the logs... > > audit(1116372981.492:0): avc: denied {execmod} for > path=/usr/lib/tls/libnvidia-tls.so.1.0.7174 dev=hda5 ino=263999 > scotext=system_u:system_r:initrc_t tcontext=root:object_r:lib_t > tclass=file > > Is SELinux objecting to it and if it is, how do I fix it? I have SELinux > set to Permissive - Targetted. chcon -t texrel_shlib_t /usr/lib/tls/libnvidia-tls.so.1.0.7174 This marks the shared object as requiring text relocation, and thus allows it to happen in the policy (if allow_execmod boolean is active; /usr/sbin/getsebool allow_execmod). Looks like the policy needs to be updated as the existing regex for nvidia in types.fc doesn't cover this case (it seems to assume that they live in a nvidia subdirectory). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed May 18 12:36:16 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 08:36:16 -0400 Subject: dhcpd and nscd bug In-Reply-To: <428AFAEF.4030501@bppiac.hu> References: <428AFAEF.4030501@bppiac.hu> Message-ID: <428B36C0.50100@redhat.com> Farkas Levente wrote: > hi, > it seems that during startup dhcpd server try to read nscd's pid files > (i don't know why?): > ----------------------------------------------- > May 15 00:20:32 atom kernel: audit(1116109232.315:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 > ino=3777358 scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > May 15 00:20:32 atom kernel: audit(1116109232.316:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 > ino=3777358 scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > ----------------------------------------------- > and inode 3777358 is /var/run/nscd directory. so it'd be useful to add > this rule to the dhcpd policy: > allow dhcpd_t nscd_var_run_t:dir search; > yours. > Change policy to fix this in selinux-policy-targeted-1.23.16-2 -- From sds at tycho.nsa.gov Wed May 18 12:27:06 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 18 May 2005 08:27:06 -0400 Subject: dhcpd and nscd bug In-Reply-To: <428AFAEF.4030501@bppiac.hu> References: <428AFAEF.4030501@bppiac.hu> Message-ID: <1116419226.3998.26.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-05-18 at 10:21 +0200, Farkas Levente wrote: > hi, > it seems that during startup dhcpd server try to read nscd's pid files > (i don't know why?): > ----------------------------------------------- > May 15 00:20:32 atom kernel: audit(1116109232.315:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 > scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > May 15 00:20:32 atom kernel: audit(1116109232.316:0): avc: denied { > search } for pid=7400 exe=/usr/sbin/dhcpd name=nscd dev=md0 ino=3777358 > scontext=system_u:system_r:dhcpd_t > tcontext=system_u:object_r:nscd_var_run_t tclass=dir > ----------------------------------------------- > and inode 3777358 is /var/run/nscd directory. so it'd be useful to add > this rule to the dhcpd policy: > allow dhcpd_t nscd_var_run_t:dir search; > yours. Just FYI, it isn't the pid file; it is to access the socket to communicate with nscd for performing name service lookups. As Ivan said, this can be handled by adding a nscd_client_domain attribute to the dhcpd_t domain, and all domains with that attribute are then allowed to communicate with nscd via the socket. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed May 18 12:38:06 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 08:38:06 -0400 Subject: /etc/ld.so.cache and FC4T3 In-Reply-To: <200505140246.36294.russell@coker.com.au> References: <200505140246.36294.russell@coker.com.au> Message-ID: <428B372E.90107@redhat.com> Russell Coker wrote: >I am seeing /etc/ld.so.cache getting type etc_t for an initial install of >FC4T3. Is anyone else seeing this? > >At this stage I'm not sure whether I messed up my install process or whether >it's a more general thing. > > > rc.sysinit has code to restorecon this also. So you are seeing this after a boot? Dan -- From dwalsh at redhat.com Wed May 18 13:30:34 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 09:30:34 -0400 Subject: mozilla mail not starting under strict policy In-Reply-To: <428A4BFA.3090704@mindspring.com> References: <428A4BFA.3090704@mindspring.com> Message-ID: <428B437A.30508@redhat.com> Richard Hally wrote: > when running strict policy on a fully updated rawhide, mozilla mail > will not start when in enforcing mode of the strict policy. > Doing a setenforce 0 allows it to start. > (Note that the avc denied messages are only produce when in premissive > mode) > Below are the AVC denied messages: > > May 17 12:46:45 new2 kernel: audit(1116348405.108:0): avc: granted { > setenforce } for scontext=root:sysadm_r:sysadm_t > tcontext=system_u:object_r:security_t tclass=security > May 17 12:46:45 new2 dbus: avc: received setenforce notice (enforcing=0) > May 17 12:46:45 new2 dbus: avc: received setenforce notice (enforcing=0) > May 17 12:46:56 new2 kernel: audit(1116348416.169:0): avc: denied { > name_connect } for dest=110 scontext=richard:staff_r:staff_mozilla_t > tcontext=system_u:object_r:pop_port_t tclass=tcp_socket > May 17 12:46:56 new2 kernel: audit(1116348416.902:0): avc: denied { > getattr } > for name=/ dev=dm-0 ino=2 scontext=richard:staff_r:staff_mozilla_t > tcontext=system_u:object_r:fs_t tclass=filesystem > May 17 12:47:45 new2 kernel: audit(1116348465.718:0): avc: granted { > setenforce } for scontext=root:sysadm_r:sysadm_t > tcontext=system_u:object_r:security_t tclass=security > May 17 12:47:45 new2 dbus: avc: received setenforce notice (enforcing=1) > May 17 12:47:45 new2 dbus: avc: received setenforce notice (enforcing=1) > Yes use thunderbird . :^) Problem is we are trying to lock down Firefox with Mozilla policy, and mozilla mail is going away. Can you just add a name_connect rule. Dan > HTH > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Wed May 18 13:31:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 09:31:53 -0400 Subject: Mysql setsched In-Reply-To: <1116246010.28782.48.camel@moss-spartans.epoch.ncsc.mil> References: <01ac01c55a0d$0076af60$f4e6fea9@Mehmet> <1116246010.28782.48.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <428B43C9.3010207@redhat.com> Stephen Smalley wrote: >On Mon, 2005-05-16 at 14:47 +0300, Emek TUZUN wrote: > > >>What is SETSCHED fuction of MySql? >> >>I am getting these logs but mysql works normal... What are these >>setsched denials? >> >>May 16 01:39:04 xstream kernel: audit(1116243944.356:0): avc: denied >>{ setsched } for pid=18216 exe=/usr/sbin/mysqld >>scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t >>tclass=process >>May 16 01:39:18 xstream kernel: audit(1116243958.654:0): avc: denied >>{ setsched } for pid=18228 exe=/usr/sbin/mysqld >>scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t >>tclass=process >>May 16 01:39:30 xstream kernel: audit(1116243970.083:0): avc: denied >>{ setsched } for pid=18229 exe=/usr/sbin/mysqld >>scontext=root:system_r:mysqld_t tcontext=root:system_r:mysqld_t >>tclass=process >> >> > >Attempts to change priority via nice(2) or scheduling information via >sched_setscheduler(2). You can get more information about the denial by >enabling syscall auditing (auditctl -e 1) and running mysqld again. If >mysqld is just lowering its priority, then this should be allowed in the >policy. > > > Latest policy allows this. -- From dwalsh at redhat.com Wed May 18 13:44:28 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 18 May 2005 09:44:28 -0400 Subject: Problems running postgresql In-Reply-To: <20050513135211.192ab328.r.godzilla@comcast.net> References: <20050513135211.192ab328.r.godzilla@comcast.net> Message-ID: <428B46BC.40106@redhat.com> Richard E Miles wrote: >I have been trying to start up the postgresql postmaster server to a database >which have all failed. The following are a list of avc: denied messages from >/var/log/messages: > >May 13 13:20:32 localhost kernel: audit(1116015632.155:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir >May 13 13:20:32 localhost last message repeated 7 times >May 13 13:20:32 localhost kernel: audit(1116015632.156:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir >May 13 13:20:32 localhost last message repeated 3 times >May 13 13:20:32 localhost kernel: audit(1116015632.157:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir >May 13 13:20:32 localhost last message repeated 32 times >May 13 13:20:32 localhost kernel: audit(1116015632.158:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir >May 13 13:20:32 localhost last message repeated 34 times >May 13 13:20:32 localhost kernel: audit(1116015632.159:0): avc: denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t tcontext=system_u:object_r:usr_t tclass=dir > >Why am I getting write denials? I am running FC3 with targetted policy. > > What file is pgdb? Dan -- From russell at coker.com.au Wed May 18 13:48:40 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 18 May 2005 23:48:40 +1000 Subject: /etc/ld.so.cache and FC4T3 In-Reply-To: <428B372E.90107@redhat.com> References: <200505140246.36294.russell@coker.com.au> <428B372E.90107@redhat.com> Message-ID: <200505182348.44935.russell@coker.com.au> On Wednesday 18 May 2005 22:38, Daniel J Walsh wrote: > Russell Coker wrote: > >I am seeing /etc/ld.so.cache getting type etc_t for an initial install of > >FC4T3. Is anyone else seeing this? > > > >At this stage I'm not sure whether I messed up my install process or > > whether it's a more general thing. > > rc.sysinit has code to restorecon this also. So you are seeing this > after a boot? I'm seeing programs failing before the stage of running restorecon on that file. Anyway if we include anaconda.te into the targeted policy then we shouldn't have that labeling problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From cochranb at speakeasy.net Wed May 18 22:12:08 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Wed, 18 May 2005 18:12:08 -0400 Subject: Problems running postgresql In-Reply-To: <428B46BC.40106@redhat.com> References: <20050513135211.192ab328.r.godzilla@comcast.net> <428B46BC.40106@redhat.com> Message-ID: <428BBDB8.4030700@speakeasy.net> Daniel J Walsh wrote: > Richard E Miles wrote: > >> I have been trying to start up the postgresql postmaster server to a >> database >> which have all failed. The following are a list of avc: denied >> messages from >> /var/log/messages: >> >> May 13 13:20:32 localhost kernel: audit(1116015632.155:0): avc: >> denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb >> dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t >> tcontext=system_u:object_r:usr_t tclass=dir >> May 13 13:20:32 localhost last message repeated 7 times >> May 13 13:20:32 localhost kernel: audit(1116015632.156:0): avc: >> denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb >> dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t >> tcontext=system_u:object_r:usr_t tclass=dir >> May 13 13:20:32 localhost last message repeated 3 times >> May 13 13:20:32 localhost kernel: audit(1116015632.157:0): avc: >> denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb >> dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t >> tcontext=system_u:object_r:usr_t tclass=dir >> May 13 13:20:32 localhost last message repeated 32 times >> May 13 13:20:32 localhost kernel: audit(1116015632.158:0): avc: >> denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb >> dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t >> tcontext=system_u:object_r:usr_t tclass=dir >> May 13 13:20:32 localhost last message repeated 34 times >> May 13 13:20:32 localhost kernel: audit(1116015632.159:0): avc: >> denied { write } for pid=16659 exe=/usr/bin/postgres name=pgdb >> dev=hda2 ino=6471728 scontext=user_u:system_r:postgresql_t >> tcontext=system_u:object_r:usr_t tclass=dir >> >> Why am I getting write denials? I am running FC3 with targetted policy. >> >> > What file is pgdb? > > Dan > I have postgresql 8.0.2 myself and don't have a file named 'pgdb'. Interesting. Bob Cochran From zico at algohotellet.se Thu May 19 06:37:07 2005 From: zico at algohotellet.se (pi) Date: Thu, 19 May 2005 08:37:07 +0200 Subject: need advice Message-ID: I have a few users on /home/ on hda and a few on /home2/ wich resides on hdb. i have httpd serving webpages without problem from (hda) /home/~/public_html but when adding users to home2/~/public_html on hdb, webpages doesnt work. Can this be caused by selnux? I ran the selinux-commands without succes, and i have done what?s expected from http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825658 When i first installed FC3, hdb was already formatted and made no changes on it. the install went right down on hda. Is it possible to make it work by merging the 2 partition together perhaps? /pi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 689 bytes Desc: not available URL: From james.zheng.li at gmail.com Thu May 19 06:46:38 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Thu, 19 May 2005 02:46:38 -0400 Subject: vsftpd with selinux on FC3 In-Reply-To: <428B34F9.5000707@redhat.com> References: <8a239a560505142055ce251ac@mail.gmail.com> <428B34F9.5000707@redhat.com> Message-ID: <8a239a56050518234632c78519@mail.gmail.com> Thanks a lot for your help. I installed FC4T3 to learn from its ftpd policy. However its policy seems not working well. After 'service vsftpd start', I cannot make ftp connection to it. Error messages are: ... 331 Please specify the password. Password: Error sending status request (Operation not permitted) Login failed. ftp> ls 230 Login successful. Passive mode address scan failure. Shouldn't happen! ftp> bye 215 UNIX Type: L8 I go through the targeted policy for ftpd and write my own policy for vsftpd on FC3. vsftpd.te ################################# # # Rules for the vsftpd_t domain. # daemon_domain(vsftpd, `, auth_chkpwd') etc_domain(vsftpd) can_network(vsftpd_t) vsftpd.fc ################################# /usr/sbin/vsftpd -- system_u:object_r:vsftpd_exec_t /var/run/vsftpd.pid -- system_u:object_r:vsftpd_var_run_t /etc/vsftpd/vsftpd.conf -- system_u:object_r:vsftpd_etc_t I know they are lots of scenarios missing here, like actions related to nfs and samba. I plan to keep adding more rules into these two files based on parsing avc error messages. Currently, the above policy works well on my home pc for both anonymous and non-anonymous ftp services without generating even one AVC error message. Interesting ?! James From gpmidi at gmail.com Thu May 19 10:53:22 2005 From: gpmidi at gmail.com (Paul M.) Date: Thu, 19 May 2005 06:53:22 -0400 Subject: need advice In-Reply-To: References: Message-ID: If your kernel supports LVM or LVM2 then you can use it to create a virtual drive (called a logical device) that consists of the two drives/partitions. The two things you need to be aware of: 1)You'll have to take your box down to single user mode. 2) You'll have to copy the data in /home and /home2 to another computer/device while you are formatting the two drives to LVM. ~Paul On 5/19/05, pi wrote: > I have a few users on /home/ on hda and a few on /home2/ wich resides > on hdb. > i have httpd serving webpages without problem from (hda) > /home/~/public_html but when adding users to home2/~/public_html on > hdb, webpages doesnt work. Can this be caused by selnux? I ran the > selinux-commands without succes, and i have done what?s expected from > http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825658 > > When i first installed FC3, hdb was already formatted and made no > changes on it. the install went right down on hda. > Is it possible to make it work by merging the 2 partition together > perhaps? > > /pi > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From walters at redhat.com Thu May 19 14:21:08 2005 From: walters at redhat.com (Colin Walters) Date: Thu, 19 May 2005 10:21:08 -0400 Subject: need advice In-Reply-To: References: Message-ID: <1116512468.3585.3.camel@nexus.verbum.private> On Thu, 2005-05-19 at 08:37 +0200, pi wrote: > > > ______________________________________________________________________ > > I have a few users on /home/ on hda and a few on /home2/ wich resides > on hdb. > i have httpd serving webpages without problem from > (hda) /home/~/public_html but when adding users to home2/~/public_html > on hdb, webpages doesnt work. Can this be caused by selnux? I ran the > selinux-commands without succes, and i have done what?s expected from > http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2825658 What avc messages do you see? Look in /var/log/messages. Things to check: 1) That /home2 is labeled with the home_root_t type: chcon -h -t home_root_t /home2/ 2) User home directories in /home2 are labeled with user_home_dir_t: chcon -h -t user_home_dir_t /home2/USER 3) User web content is labeled with httpd_user_content_t: chcon -R -h -t httpd_user_content_t /home2/USER/public_html 4) The SELinux "httpd_enable_homedirs" boolean is active: setsebool -P httpd_enable_homedirs=true From dwalsh at redhat.com Thu May 19 14:37:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 19 May 2005 10:37:25 -0400 Subject: vsftpd with selinux on FC3 In-Reply-To: <8a239a56050518234632c78519@mail.gmail.com> References: <8a239a560505142055ce251ac@mail.gmail.com> <428B34F9.5000707@redhat.com> <8a239a56050518234632c78519@mail.gmail.com> Message-ID: <428CA4A5.1060104@redhat.com> James Z. Li wrote: >Thanks a lot for your help. > >I installed FC4T3 to learn from its ftpd policy. However its policy seems >not working well. After 'service vsftpd start', I cannot make ftp connection >to it. Error messages are: >... >331 Please specify the password. >Password: >Error sending status request (Operation not permitted) >Login failed. >ftp> ls >230 Login successful. >Passive mode address scan failure. Shouldn't happen! >ftp> bye >215 UNIX Type: L8 > >I go through the targeted policy for ftpd and write my own policy for vsftpd >on FC3. > > vsftpd.te >################################# ># ># Rules for the vsftpd_t domain. ># >daemon_domain(vsftpd, `, auth_chkpwd') >etc_domain(vsftpd) >can_network(vsftpd_t) > >vsftpd.fc >################################# >/usr/sbin/vsftpd -- system_u:object_r:vsftpd_exec_t >/var/run/vsftpd.pid -- system_u:object_r:vsftpd_var_run_t >/etc/vsftpd/vsftpd.conf -- system_u:object_r:vsftpd_etc_t > >I know they are lots of scenarios missing here, like actions related to nfs and >samba. I plan to keep adding more rules into these two files based on parsing >avc error messages. Currently, the above policy works well on my home pc >for both anonymous and non-anonymous ftp services without generating even >one AVC error message. Interesting ?! > >James > > Yes we have made some modifications to ftpd.te this past week to fix this problem. Could you grab the latest policy off of ftp://people.redhat.com/dwalsh/SELinux/Fedora Which should make it into FC4/Final. -- From selinux at gmail.com Thu May 19 14:43:39 2005 From: selinux at gmail.com (Tom London) Date: Thu, 19 May 2005 07:43:39 -0700 Subject: cupsd & targeted.... Message-ID: <4c4ba15305051907435d60d03f@mail.gmail.com> Running targeted/enforcing, latest rawhide. I get the following avc from cupsd on startup and during use of an HP USB printer: May 19 06:22:51 localhost kernel: audit(1116508971.985:0): avc: denied { read } for name=printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 19 06:23:48 localhost kernel: audit(1116509028.008:0): avc: denied { write } for name=printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 19 07:06:39 localhost kernel: audit(1116511599.151:0): avc: denied { read } for name=printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file May 19 07:06:48 localhost kernel: audit(1116511608.606:0): avc: denied { signal } for scontext=system_u:system_r:hald_t tcontext=system_u:system_r:cupsd_config_t tclass=process May 19 07:06:52 localhost kernel: audit(1116511612.418:0): avc: denied { write } for name=printconf.pickle dev=dm-0 ino=2158741 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:object_r:var_t tclass=file Some read/write avcs are for /var/foomatic/printconf.pickle. Is there an appropriate type for this (other than var_t)? Should hald.te have: ifdev(`cups.te', ` allow hald_t cupsd_config_t:process signal; ') Other? tom -- Tom London From twaugh at redhat.com Thu May 19 15:14:01 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 19 May 2005 16:14:01 +0100 Subject: cupsd & targeted.... In-Reply-To: <4c4ba15305051907435d60d03f@mail.gmail.com> References: <4c4ba15305051907435d60d03f@mail.gmail.com> Message-ID: <20050519151401.GS8706@redhat.com> On Thu, May 19, 2005 at 07:43:39AM -0700, Tom London wrote: > Some read/write avcs are for /var/foomatic/printconf.pickle. Is there > an appropriate type for this (other than var_t)? The /var/foomatic/printconf.pickle file is just the contents of the /var/foomatic/db directory cached in a format that system-config-printer can read more quickly. It is written (or at least, this is attempted) whenever the foomatic data itself is read -- in other words, whenever the cache file would have been useful. This happens in all users of printconf_conf: * system-config-printer * printconf-backend (cups initscript, RPM %postinstall scriptlets) * updateconf.py (RPM %postinstall scriptlets) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Thu May 19 17:00:10 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 19 May 2005 13:00:10 -0400 Subject: cupsd & targeted.... In-Reply-To: <20050519151401.GS8706@redhat.com> References: <4c4ba15305051907435d60d03f@mail.gmail.com> <20050519151401.GS8706@redhat.com> Message-ID: <428CC61A.4070503@redhat.com> Tim Waugh wrote: >On Thu, May 19, 2005 at 07:43:39AM -0700, Tom London wrote: > > > >>Some read/write avcs are for /var/foomatic/printconf.pickle. Is there >>an appropriate type for this (other than var_t)? >> >> > >The /var/foomatic/printconf.pickle file is just the contents of the >/var/foomatic/db directory cached in a format that >system-config-printer can read more quickly. > >It is written (or at least, this is attempted) whenever the foomatic >data itself is read -- in other words, whenever the cache file would >have been useful. > > > Why is cupsd_config trying to write to it? >This happens in all users of printconf_conf: > >* system-config-printer >* printconf-backend (cups initscript, RPM %postinstall scriptlets) >* updateconf.py (RPM %postinstall scriptlets) > >Tim. >*/ > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From twaugh at redhat.com Thu May 19 17:03:19 2005 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 19 May 2005 18:03:19 +0100 Subject: cupsd & targeted.... In-Reply-To: <428CC61A.4070503@redhat.com> References: <4c4ba15305051907435d60d03f@mail.gmail.com> <20050519151401.GS8706@redhat.com> <428CC61A.4070503@redhat.com> Message-ID: <20050519170319.GW8706@redhat.com> On Thu, May 19, 2005 at 01:00:10PM -0400, Daniel J Walsh wrote: > Why is cupsd_config trying to write to it? Well, which executable is that? Perhaps it is using printconf-tui. Basically, any time the foomatic data might need to be consulted, and printconf_conf is ultimately used to do that, the cache file will be read and/or written. It isn't a problem if this fails: it just means it will load the data more slowly. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Thu May 19 17:12:38 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 19 May 2005 13:12:38 -0400 Subject: cupsd & targeted.... In-Reply-To: <428CC61A.4070503@redhat.com> References: <4c4ba15305051907435d60d03f@mail.gmail.com> <20050519151401.GS8706@redhat.com> <428CC61A.4070503@redhat.com> Message-ID: <428CC906.6070509@redhat.com> Daniel J Walsh wrote: > Tim Waugh wrote: > >> On Thu, May 19, 2005 at 07:43:39AM -0700, Tom London wrote: >> >> >> >>> Some read/write avcs are for /var/foomatic/printconf.pickle. Is there >>> an appropriate type for this (other than var_t)? >>> >> >> >> The /var/foomatic/printconf.pickle file is just the contents of the >> /var/foomatic/db directory cached in a format that >> system-config-printer can read more quickly. >> >> It is written (or at least, this is attempted) whenever the foomatic >> data itself is read -- in other words, whenever the cache file would >> have been useful. >> >> >> > Why is cupsd_config trying to write to it? > >> This happens in all users of printconf_conf: >> >> * system-config-printer >> * printconf-backend (cups initscript, RPM %postinstall scriptlets) >> * updateconf.py (RPM %postinstall scriptlets) >> >> Tim. >> */ >> >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > Anyways should /var/foomatic/printconf.pickle be marked cupsd_rw_etc_t. Meaning this is something that is created by cups for use by cups? And is that the correct directory or should it be /var/cache/... Dan -- From SELinux at Compucenter.org Fri May 20 07:12:20 2005 From: SELinux at Compucenter.org (George J. Jahchan) Date: Fri, 20 May 2005 10:12:20 +0300 Subject: Auditd & Strict Policy 1.19 Message-ID: On a Bastilled FC3 latest kernel and with the strict SE Linux policy (1.19), if not in permissive mode, the auditd daemon refuses to start with the following error messages in /var/log/messages: ... Unable to set audit pid, exiting. ... Error sending failure mode request (Operation not permitted). Once the daemon starts in permissive mode, it is not a problem to revert SE Linux back to enforcing mode, the daemon stays up (and performs as expected). Have started Fedora with audit=1 kernel option and enabled the noisy events in SE Linux (make enableaudit & make load in the strict policy source directory), auditd-related denials have all been explicitly allowed in our custom.te policy under domains/misc. Auditd daemon still fails to start in enforcing mode, and no selinux denials are generated when we try to start it. Using the above method, we have been able to get the system to boot in enforcing mode and run all the programs & daemons we needed to run (with no selinux denials, except attempts to access shadow_t which is protected by an assertion in the strict policy), except for auditd. Any hints on how to resolve this issue? From twaugh at redhat.com Fri May 20 08:29:40 2005 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 20 May 2005 09:29:40 +0100 Subject: cupsd & targeted.... In-Reply-To: <428CC906.6070509@redhat.com> References: <4c4ba15305051907435d60d03f@mail.gmail.com> <20050519151401.GS8706@redhat.com> <428CC61A.4070503@redhat.com> <428CC906.6070509@redhat.com> Message-ID: <20050520082940.GX8706@redhat.com> On Thu, May 19, 2005 at 01:12:38PM -0400, Daniel J Walsh wrote: > Anyways should /var/foomatic/printconf.pickle be marked cupsd_rw_etc_t. > > Meaning this is something that is created by cups for use by cups? Yes, that's right. > And is that the correct directory or should it be /var/cache/... Sorry, the file is named: /var/cache/foomatic/printconf.pickle Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri May 20 12:08:45 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 20 May 2005 08:08:45 -0400 Subject: Auditd & Strict Policy 1.19 In-Reply-To: References: Message-ID: <1116590925.12489.10.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-20 at 10:12 +0300, George J. Jahchan wrote: > On a Bastilled FC3 latest kernel and with the strict SE Linux policy (1.19), if > not in permissive mode, the auditd daemon refuses to start with the following > error messages in /var/log/messages: > > ... Unable to set audit pid, exiting. > ... Error sending failure mode request (Operation not permitted). > > Once the daemon starts in permissive mode, it is not a problem to revert SE > Linux back to enforcing mode, the daemon stays up (and performs as expected). > > Have started Fedora with audit=1 kernel option and enabled the noisy events in > SE Linux (make enableaudit & make load in the strict policy source directory), > auditd-related denials have all been explicitly allowed in our custom.te policy > under domains/misc. Auditd daemon still fails to start in enforcing mode, and no > selinux denials are generated when we try to start it. > > Using the above method, we have been able to get the system to boot in enforcing > mode and run all the programs & daemons we needed to run (with no selinux > denials, except attempts to access shadow_t which is protected by an assertion > in the strict policy), except for auditd. > > Any hints on how to resolve this issue? With regard to the denial, I suspect it is due to recently introduced (as of 2.6.11) new capability checks performed in the receive-side kernel audit code, which unfortunately cannot generate audit messages presently. This will hopefully be resolved as part of some ongoing work. Hence, you likely need: allow auditd_t self:capability { audit_write audit_control }; in policy/domains/program/auditd.te, and you likely need to add those permission definitions to policy/flask/access_vectors at the end of the class capability definition as the FC3 policy would not have included them. BTW, when using strict policy, it is always advisable to use the latest rawhide policy (in this case, FC4/devel) in order to pick up the latest fixes. Also, there has been a lot of work done in FC4/devel on the kernel audit framework, auditd, auditctl, and other userspace support for auditing in order to prepare it for CAPP evaluation, so if you truly want to use auditing in general (beyond just the SELinux auditing), you may want to move to FC4. -- Stephen Smalley National Security Agency From rhally at mindspring.com Wed May 18 20:08:47 2005 From: rhally at mindspring.com (Richard Hally) Date: Wed, 18 May 2005 16:08:47 -0400 Subject: mozilla mail not starting under strict policy In-Reply-To: <428B437A.30508@redhat.com> References: <428A4BFA.3090704@mindspring.com> <428B437A.30508@redhat.com> Message-ID: <428BA0CF.2000401@mindspring.com> Daniel J Walsh wrote: > Richard Hally wrote: > >> when running strict policy on a fully updated rawhide, mozilla mail >> will not start when in enforcing mode of the strict policy. >> Doing a setenforce 0 allows it to start. >> (Note that the avc denied messages are only produce when in >> premissive mode) >> Below are the AVC denied messages: >> >> May 17 12:46:45 new2 kernel: audit(1116348405.108:0): avc: granted >> { setenforce } for scontext=root:sysadm_r:sysadm_t >> tcontext=system_u:object_r:security_t tclass=security >> May 17 12:46:45 new2 dbus: avc: received setenforce notice >> (enforcing=0) >> May 17 12:46:45 new2 dbus: avc: received setenforce notice >> (enforcing=0) >> May 17 12:46:56 new2 kernel: audit(1116348416.169:0): avc: denied { >> name_connect } for dest=110 scontext=richard:staff_r:staff_mozilla_t >> tcontext=system_u:object_r:pop_port_t tclass=tcp_socket >> May 17 12:46:56 new2 kernel: audit(1116348416.902:0): avc: denied { >> getattr } >> for name=/ dev=dm-0 ino=2 scontext=richard:staff_r:staff_mozilla_t >> tcontext=system_u:object_r:fs_t tclass=filesystem >> May 17 12:47:45 new2 kernel: audit(1116348465.718:0): avc: granted >> { setenforce } for scontext=root:sysadm_r:sysadm_t >> tcontext=system_u:object_r:security_t tclass=security >> May 17 12:47:45 new2 dbus: avc: received setenforce notice >> (enforcing=1) >> May 17 12:47:45 new2 dbus: avc: received setenforce notice >> (enforcing=1) >> > Yes use thunderbird . :^) > OK, switched to t'bird. (it works (so far)). =;-) > Problem is we are trying to lock down Firefox with Mozilla policy, and > mozilla mail is going away. Can you just add a name_connect > rule. > It's on the box that is strictly for testing SELinux, so I try to stay with the policy "as provided". thanks Dan, Richard From SELinux at Compucenter.org Fri May 20 15:24:01 2005 From: SELinux at Compucenter.org (George J. Jahchan) Date: Fri, 20 May 2005 18:24:01 +0300 Subject: Auditd & Strict Policy 1.19 Message-ID: Stephen, Followed your instructions, adding 'audit write & audit_control' at the end of the capability section in the policy/flask/access_vectors elicits the following error message when making the policy: ... too many permissions to fit in an access vector. It will accept any two of the three in the capability section of access_vectors, at which time it complains as follows: ... 'permission [omitted permission from the above] is not defined for class capability' ... Bearing in mind that the machines are live production hosts, how do you recommend we address this (from the available choices below)? 1) For a limited period of time (until FC4 is released), we can live with having to switch to permissive mode in order to start the audit daemon, and revert back to enforcing mode after it starts. The hosts are not taken down that often. 2) We can upgrade to FC4 strict policy, with no assurance that it will work or not cause other problems. 3) We can upgrade to pre-release FC4, again with no assurance that it will work or will not introduce new weaknesses. Thank you for your help. -----Original Message----- From: Stephen Smalley [mailto:sds at tycho.nsa.gov] Sent: Friday, May 20, 2005 3:09 PM To: George J. Jahchan Cc: Fedora SE Linux List Subject: Re: Auditd & Strict Policy 1.19 On Fri, 2005-05-20 at 10:12 +0300, George J. Jahchan wrote: > On a Bastilled FC3 latest kernel and with the strict SE Linux policy (1.19), if > not in permissive mode, the auditd daemon refuses to start with the following > error messages in /var/log/messages: > > ... Unable to set audit pid, exiting. > ... Error sending failure mode request (Operation not permitted). > > Once the daemon starts in permissive mode, it is not a problem to revert SE > Linux back to enforcing mode, the daemon stays up (and performs as expected). > > Have started Fedora with audit=1 kernel option and enabled the noisy events in > SE Linux (make enableaudit & make load in the strict policy source directory), > auditd-related denials have all been explicitly allowed in our custom.te policy > under domains/misc. Auditd daemon still fails to start in enforcing mode, and no > selinux denials are generated when we try to start it. > > Using the above method, we have been able to get the system to boot in enforcing > mode and run all the programs & daemons we needed to run (with no selinux > denials, except attempts to access shadow_t which is protected by an assertion > in the strict policy), except for auditd. > > Any hints on how to resolve this issue? With regard to the denial, I suspect it is due to recently introduced (as of 2.6.11) new capability checks performed in the receive-side kernel audit code, which unfortunately cannot generate audit messages presently. This will hopefully be resolved as part of some ongoing work. Hence, you likely need: allow auditd_t self:capability { audit_write audit_control }; in policy/domains/program/auditd.te, and you likely need to add those permission definitions to policy/flask/access_vectors at the end of the class capability definition as the FC3 policy would not have included them. BTW, when using strict policy, it is always advisable to use the latest rawhide policy (in this case, FC4/devel) in order to pick up the latest fixes. Also, there has been a lot of work done in FC4/devel on the kernel audit framework, auditd, auditctl, and other userspace support for auditing in order to prepare it for CAPP evaluation, so if you truly want to use auditing in general (beyond just the SELinux auditing), you may want to move to FC4. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 20 14:17:22 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 20 May 2005 10:17:22 -0400 Subject: Auditd & Strict Policy 1.19 In-Reply-To: References: Message-ID: <1116598642.12489.88.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-20 at 18:24 +0300, George J. Jahchan wrote: > Followed your instructions, adding 'audit write & audit_control' at the end of > the capability section in the policy/flask/access_vectors elicits the following > error message when making the policy: That's audit_write and audit_control - two permissions, not three. > ... too many permissions to fit in an access vector. Off-by-one bug in checkpolicy, fixed after FC3, but shouldn't matter as you only need two permissions here. > Bearing in mind that the machines are live production hosts, how do you > recommend we address this (from the available choices below)? > > 1) For a limited period of time (until FC4 is released), we can live with having > to switch to permissive mode in order to start the audit daemon, and revert back > to enforcing mode after it starts. The hosts are not taken down that often. > > 2) We can upgrade to FC4 strict policy, with no assurance that it will work or > not cause other problems. > > 3) We can upgrade to pre-release FC4, again with no assurance that it will work > or will not introduce new weaknesses. I've sent (via separate email) a copy of our current policy/flask/security_classes, policy/flask/access_vectors, policy/domains/program/auditd.te, and policy/file_contexts/program/auditd.fc, so you can at least try those to see if they resolve your issue for auditd (and they shouldn't impact anything else). If that resolves your problem, then feel free to stay with FC3 until FC4 is out (schedule says June 6). -- Stephen Smalley National Security Agency From selinux at gmail.com Sat May 21 20:55:49 2005 From: selinux at gmail.com (Tom London) Date: Sat, 21 May 2005 13:55:49 -0700 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... Message-ID: <4c4ba1530505211355236189c@mail.gmail.com> Running strict/enforcing, latest rawhide. Get the following when logging in: May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user tbl by (uid=0) May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied { write } for name=dmix.conf dev=hda2 ino=4523476 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=file May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf May 21 13:30:16 fedora ainit: Error: Permission denied The file in questions is /etc/alsa/pcm/dmix.conf. /etc/alsa/ainit.conf has: # # overwrite target files, if exists # overwrite = yes # # first config file - for dmix plugin # template_0 = /etc/alsa/pcm/dmix.template target_0 = /etc/alsa/pcm/dmix.conf target_root_file_0 = yes This seems less than perfect to me.... Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as xdm_rw_etc_t? (I don't know who else needs to read these files....) tom -- Tom London From selinux at gmail.com Sat May 21 21:03:25 2005 From: selinux at gmail.com (Tom London) Date: Sat, 21 May 2005 14:03:25 -0700 Subject: rhgb and /usr Message-ID: <4c4ba153050521140318ceea03@mail.gmail.com> Running strict/enforcing, today's rawhide. Booting, get these avc from rhgb: May 21 13:06:45 fedora smartd[2314]: Device: /dev/hda, opened May 21 13:06:45 fedora kernel: SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts May 21 13:06:45 fedora kernel: audit(1116680781.182:0): avc: denied { read } for name=index.theme dev=hda2 ino=4523023 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680781.513:0): avc: denied { getattr } for path="/usr/share/themes/Clearlooks/gtk-2.0/gtkrc" dev=hda2 ino=4592143 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680781.687:0): avc: denied { read } for name=large-computer.png dev=hda2 ino=4126600 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680781.869:0): avc: denied { getattr } for path="/usr/share/vte/termcap/xterm" dev=hda2 ino=4459308 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680784.842:0): avc: denied { read } for name=index.theme dev=hda2 ino=4523023 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680784.842:0): avc: denied { read } for name=index.theme dev=hda2 ino=4523023 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680784.962:0): avc: denied { read } for name=index.theme dev=hda2 ino=4523023 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680784.964:0): avc: denied { read } for name=system-logo.png dev=hda2 ino=4112422 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file May 21 13:06:45 fedora kernel: audit(1116680784.973:0): avc: denied { read } for name=throbber-anim.png dev=hda2 ino=4114138 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:usr_t tclass=file What's right here, dontaudit or allow? (System appears to boot just fine.) tom -- Tom London From selinux at gmail.com Sun May 22 16:27:08 2005 From: selinux at gmail.com (Tom London) Date: Sun, 22 May 2005 09:27:08 -0700 Subject: allow_write_xhm ? Message-ID: <4c4ba15305052209275fb30af6@mail.gmail.com> Running strict/enforcing, latest rawhide. During boot, I get an error complaining about boolean 'allow_write_xhm'. /etc/selinux/strict/booleans has allow_write_xhm=1 as last line. Should this be: allow_write_xshm=1 Is this something I did locally, or .... ? tom -- Tom London From selinux at gmail.com Sun May 22 17:02:20 2005 From: selinux at gmail.com (Tom London) Date: Sun, 22 May 2005 10:02:20 -0700 Subject: allow_write_xhm ? In-Reply-To: <4290B5DC.8090207@mindspring.com> References: <4c4ba15305052209275fb30af6@mail.gmail.com> <4290B5DC.8090207@mindspring.com> Message-ID: <4c4ba153050522100214142829@mail.gmail.com> On 5/22/05, Richard Hally wrote: > I see the same error... > Richard > OK. Changing last line of /etc/selinux/strict/booleans to 'allow_write_xshm=1' fixes this.... tom -- Tom London From selinux at gmail.com Sun May 22 17:21:59 2005 From: selinux at gmail.com (Tom London) Date: Sun, 22 May 2005 10:21:59 -0700 Subject: rhgb and /usr In-Reply-To: <4c4ba153050521140318ceea03@mail.gmail.com> References: <4c4ba153050521140318ceea03@mail.gmail.com> Message-ID: <4c4ba1530505221021780f2cb9@mail.gmail.com> More on this..... rhgb now produces a black screen with the X cursor and 'hangs' until the usual graphical login starts. adding read and getattr for usr_t makes this work again: --- /tmp/rhgb.te 2005-05-22 10:20:35.000000000 -0700 +++ ./rhgb.te 2005-05-22 10:09:49.000000000 -0700 @@ -95,4 +95,4 @@ allow initrc_t ramfs_t:sock_file write; allow initrc_t rhgb_t:unix_stream_socket { read write }; -allow rhgb_t default_t:file { getattr read }; +allow rhgb_t { default_t usr_t }:file { getattr read }; Seems a bit heavy weight, but .... tom -- Tom London From selinux at gmail.com Sun May 22 17:39:39 2005 From: selinux at gmail.com (Tom London) Date: Sun, 22 May 2005 10:39:39 -0700 Subject: domains/misc/kernel.te Message-ID: <4c4ba15305052210396f384c93@mail.gmail.com> domains/misc/kernel.te has the following lines: # Use capabilities. allow kernel_t self:capability *; allow kernel_t sysfs_t:dir search; allow kernel_t { usbfs_t usbdevfs_t sysfs_t }:dir search; # Run init in the init_t domain. Search for sysfs_t is in twice. Also, I'm getting avc's for kernel_t for getattr/read for sysfs_t: May 22 10:04:32 fedora kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied { getattr } for path="/sys/class/input/mouse1" dev=sysfs ino=1850 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t tclass=dir May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied { getattr } for path="/sys/class/input/mouse1/dev" dev=sysfs ino=2090 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t tclass=file May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied { read } for name=dev dev=sysfs ino=2090 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t tclass=file Would it be right to replace allow kernel_t sysfs_t:dir search; allow kernel_t { usbfs_t usbdevfs_t sysfs_t }:dir search; with r_dir_file(kernel_t, sysfs_t) allow kernel_t { usbfs_t usbdevfs_t }:dir search; tom -- Tom London From james.zheng.li at gmail.com Mon May 23 01:42:17 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Sun, 22 May 2005 21:42:17 -0400 Subject: /proc {getattr} failures Message-ID: <8a239a56050522184222d724ca@mail.gmail.com> targeted policy on FC3 /var/log/messages show lots of avcs: May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied { getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538 scontext=user_u:system_r:httpd_sys_script_t tcontext=user_u:system_r:unconfined_t tclass=dir ... May 22 20:54:42 bengal kernel: audit(1116809682.171:0): avc: denied { getattr } for pid=2733 exe=/bin/ps path=/proc/2660 dev=proc ino=174325762 scontext=user_u:system_r:httpd_sys_script_t tcontext=root:system_r:unconfined_t tclass=dir 'audit2allow' generates this rule in local.te allow httpd_sys_script_t unconfined_t:dir { getattr }; 'make load' shows the assertion error message Assertion on line 17328 violated by allow httpd_sys_script_t unconfined_t:dir { getattr }; make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 Then I learned that /proc, /selinux, and /sys do not have persistent labels. What should I do to solve this problem? Remove that assertion check? Btw, anyone has a policy file for Gallery (gallery.sourceforge.net) with httpd? Thanks a lot! From Valdis.Kletnieks at vt.edu Mon May 23 01:53:41 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 22 May 2005 21:53:41 -0400 Subject: /proc {getattr} failures In-Reply-To: Your message of "Sun, 22 May 2005 21:42:17 EDT." <8a239a56050522184222d724ca@mail.gmail.com> References: <8a239a56050522184222d724ca@mail.gmail.com> Message-ID: <200505230153.j4N1rgNs027496@turing-police.cc.vt.edu> On Sun, 22 May 2005 21:42:17 EDT, "James Z. Li" said: > targeted policy on FC3 > > /var/log/messages show lots of avcs: > May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied > { getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538 > scontext=user_u:system_r:httpd_sys_script_t > tcontext=user_u:system_r:unconfined_t tclass=dir Am I the only one here who thinks that this is really something that can't be supported in the context of the 'targeted' policy, and would be much easier to do in 'strict'? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From rhally at mindspring.com Sun May 22 16:39:56 2005 From: rhally at mindspring.com (Richard Hally) Date: Sun, 22 May 2005 12:39:56 -0400 Subject: allow_write_xhm ? In-Reply-To: <4c4ba15305052209275fb30af6@mail.gmail.com> References: <4c4ba15305052209275fb30af6@mail.gmail.com> Message-ID: <4290B5DC.8090207@mindspring.com> Tom London wrote: > Running strict/enforcing, latest rawhide. > > During boot, I get an error complaining about boolean 'allow_write_xhm'. > > /etc/selinux/strict/booleans has > allow_write_xhm=1 > as last line. > > Should this be: > allow_write_xshm=1 > > Is this something I did locally, or .... ? > > tom > I see the same error... Richard From ivg2 at cornell.edu Mon May 23 02:31:24 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 22 May 2005 22:31:24 -0400 Subject: rhgb and /usr In-Reply-To: <4c4ba1530505221021780f2cb9@mail.gmail.com> References: <4c4ba153050521140318ceea03@mail.gmail.com> <4c4ba1530505221021780f2cb9@mail.gmail.com> Message-ID: <1116815484.8110.8.camel@localhost.localdomain> On Sun, 2005-05-22 at 10:21 -0700, Tom London wrote: > More on this..... > > rhgb now produces a black screen with the X cursor and 'hangs' until > the usual graphical login starts. This is my fault (sort of). Testing whether rhgb needs usr_t or not was on my TODO list when Dan Walsh merged parts of my patch. I guess it is needed, for things other than fonts. > adding read and getattr for usr_t makes this work again: > --- /tmp/rhgb.te 2005-05-22 10:20:35.000000000 -0700 > +++ ./rhgb.te 2005-05-22 10:09:49.000000000 -0700 > @@ -95,4 +95,4 @@ > allow initrc_t ramfs_t:sock_file write; > allow initrc_t rhgb_t:unix_stream_socket { read write }; > > -allow rhgb_t default_t:file { getattr read }; > +allow rhgb_t { default_t usr_t }:file { getattr read }; -- Ivan Gyurdiev Cornell University From stas at zend.com Mon May 23 10:34:20 2005 From: stas at zend.com (Stanislav Malyshev) Date: Mon, 23 May 2005 13:34:20 +0300 (IDT) Subject: php+mysql under httpd in fc3 Message-ID: I run FC3 with targeted policies (default install). I have a problem running connecting to mysql server from php under apache - the problem is that httpd/php is denied write access to mysql.sock, something like this: fc3 kernel: audit(1116843116.146:0): avc: denied { write } for pid=7281 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=375162 scontext=root:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Now, I have seen various modifications to policy sources that would allow it to work, but what I am asking is if it possible to do it without rebuilding policy from sources. The reason for this is that we need to make our ptoduce to install mysql & certain modules using it on user servers, and we can not count on policy sources being installed there. Also, the security of mysqld itself does not matter in this particular case and it is OK for us to run it unrestricted (it's separate server for this application only without network connection). The only problem is to allow restricted httpd to connect to that particular Unix socket. I see that default system sources (apache.te) seem to include various types that seem to allow this, but I have no success in using them. If I try to use mysqld_var_run_t chcon gives me "Invalid argument", same with mysqld_db_t. Also, I see that httpd_php_t has can_unix_connect() rule, while httpd_t does not, however I did not find any documentation on what these types are, what's teh difference and how one can use httpd_php_t. I see httpd is running now under httpd_t according to ps -eZ. I tries also to set mysql.sock into tmp_t, then write error disappears, and this one appears instead: fc3 kernel: audit(1116844521.972:0): avc: denied { connectto } for pid=7275 exe=/usr/sbin/httpd path=/var/lib/mysql/mysql.sock scontext=root:system_r:httpd_t tcontext=user_u:system_r:unconfined_t tclass=unix_stream_socket I am rather new to all SELinux concepts, so if anyone can give me some explanations about this or point me to some docs that describe these things it will be appreciated. TIA, -- Stanislav Malyshev, Zend Products Engineer stas at zend.com http://www.zend.com/ +972-3-6139665 ext.115 From Valdis.Kletnieks at vt.edu Mon May 23 16:40:07 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 23 May 2005 12:40:07 -0400 Subject: php+mysql under httpd in fc3 In-Reply-To: Your message of "Mon, 23 May 2005 13:34:20 +0300." References: Message-ID: <200505231640.j4NGe7k9017075@turing-police.cc.vt.edu> On Mon, 23 May 2005 13:34:20 +0300, Stanislav Malyshev said: > I run FC3 with targeted policies (default install). I have a problem > running connecting to mysql server from php under apache - the problem is > that httpd/php is denied write access to mysql.sock, something like this: FC3 didn't do this sort of thing very well - FC4's targeted will handle mysql a lot better AFAIK... FC4 is likely about to escape. If you're not willing to wait, you might want to see if installing selinux-policy-targeted 1.23.14-2 from the -devel tree works better. (Anybody know what other things he (libsepol, policycoreutils, etc) he'll need, or can he just 'rpm -Fvh' that one, and let rpm tell him what he needs?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From dwalsh at redhat.com Mon May 23 21:37:00 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 23 May 2005 17:37:00 -0400 Subject: rhgb and /usr In-Reply-To: <1116815484.8110.8.camel@localhost.localdomain> References: <4c4ba153050521140318ceea03@mail.gmail.com> <4c4ba1530505221021780f2cb9@mail.gmail.com> <1116815484.8110.8.camel@localhost.localdomain> Message-ID: <42924CFC.9090202@redhat.com> Ivan Gyurdiev wrote: >On Sun, 2005-05-22 at 10:21 -0700, Tom London wrote: > > >>More on this..... >> >>rhgb now produces a black screen with the X cursor and 'hangs' until >>the usual graphical login starts. >> >> > >This is my fault (sort of). Testing whether rhgb needs usr_t or >not was on my TODO list when Dan Walsh merged parts of my patch. > >I guess it is needed, for things other than fonts. > > > >>adding read and getattr for usr_t makes this work again: >>--- /tmp/rhgb.te 2005-05-22 10:20:35.000000000 -0700 >>+++ ./rhgb.te 2005-05-22 10:09:49.000000000 -0700 >>@@ -95,4 +95,4 @@ >> allow initrc_t ramfs_t:sock_file write; >> allow initrc_t rhgb_t:unix_stream_socket { read write }; >> >>-allow rhgb_t default_t:file { getattr read }; >>+allow rhgb_t { default_t usr_t }:file { getattr read }; >> >> > > > Put back for 1.23.16-7 -- From russell at coker.com.au Tue May 24 03:41:40 2005 From: russell at coker.com.au (Russell Coker) Date: Tue, 24 May 2005 13:41:40 +1000 Subject: /proc {getattr} failures In-Reply-To: <8a239a56050522184222d724ca@mail.gmail.com> References: <8a239a56050522184222d724ca@mail.gmail.com> Message-ID: <200505241341.44185.russell@coker.com.au> On Monday 23 May 2005 11:42, "James Z. Li" wrote: > targeted policy on FC3 > > /var/log/messages show lots of avcs: > May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied > { getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538 > scontext=user_u:system_r:httpd_sys_script_t > tcontext=user_u:system_r:unconfined_t tclass=dir > ... > May 22 20:54:42 bengal kernel: audit(1116809682.171:0): avc: denied > { getattr } for pid=2733 exe=/bin/ps path=/proc/2660 dev=proc > ino=174325762 scontext=user_u:system_r:httpd_sys_script_t > tcontext=root:system_r:unconfined_t tclass=dir > > 'audit2allow' generates this rule in local.te > allow httpd_sys_script_t unconfined_t:dir { getattr }; CGI-BIN scripts have no need to know anything about init or to see it in ps output. The output of audit2allow does not need to be put directly into the policy, you can also change the "allow" key word to "dontaudit" if it seems appropriate. In this situation the program in question does not need such access, should not be given such access, and a "dontaudit" rule will remove the annoying log entries. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From james.zheng.li at gmail.com Tue May 24 05:06:14 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Tue, 24 May 2005 01:06:14 -0400 Subject: How to add a new application in targeted Message-ID: <8a239a560505232206328d4b4@mail.gmail.com> I wrote some policy files for sendmail, say /etc/selinux/targeted/src/policy/file_contexts/program/sendmail.fc /etc/selinux/targeted/src/policy/domain/program/sendmail.te I compiled them using 'make load' but it looks like selinux does not check against my policy files. I was wondering if there is a checklist where I could add 'sendmail' to let selinux know sendmail is now one of the targeted applications. Or should I put my sendmail.fc and sendmail.te in local.fc and local.te respectively? Thanks, James From Valdis.Kletnieks at vt.edu Tue May 24 06:10:03 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 May 2005 02:10:03 -0400 Subject: How to add a new application in targeted In-Reply-To: Your message of "Tue, 24 May 2005 01:06:14 EDT." <8a239a560505232206328d4b4@mail.gmail.com> References: <8a239a560505232206328d4b4@mail.gmail.com> Message-ID: <200505240610.j4O6A3EG014762@turing-police.cc.vt.edu> On Tue, 24 May 2005 01:06:14 EDT, "James Z. Li" said: > I wrote some policy files for sendmail, say > /etc/selinux/targeted/src/policy/file_contexts/program/sendmail.fc > /etc/selinux/targeted/src/policy/domain/program/sendmail.te Umm.. you *did* know that there's been a sendmail.fc and sendmail.te in 'targeted' for quite some time, right? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Tue May 24 14:47:12 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 24 May 2005 10:47:12 -0400 Subject: /proc {getattr} failures In-Reply-To: <200505230153.j4N1rgNs027496@turing-police.cc.vt.edu> References: <8a239a56050522184222d724ca@mail.gmail.com> <200505230153.j4N1rgNs027496@turing-police.cc.vt.edu> Message-ID: <1116946032.27904.100.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-05-22 at 21:53 -0400, Valdis.Kletnieks at vt.edu wrote: > On Sun, 22 May 2005 21:42:17 EDT, "James Z. Li" said: > > targeted policy on FC3 > > > > /var/log/messages show lots of avcs: > > May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied > > { getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538 > > scontext=user_u:system_r:httpd_sys_script_t > > tcontext=user_u:system_r:unconfined_t tclass=dir > > Am I the only one here who thinks that this is really something that can't > be supported in the context of the 'targeted' policy, and would be much > easier to do in 'strict'? It shouldn't be done at all, other than to dontaudit these attempts. No legitimate reason for a CGI script to be probing init's /proc/pid files. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue May 24 15:47:58 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 11:47:58 -0400 Subject: allow_write_xhm ? In-Reply-To: <4c4ba153050522100214142829@mail.gmail.com> References: <4c4ba15305052209275fb30af6@mail.gmail.com> <4290B5DC.8090207@mindspring.com> <4c4ba153050522100214142829@mail.gmail.com> Message-ID: <42934CAE.1010508@redhat.com> Tom London wrote: >On 5/22/05, Richard Hally wrote: > > >>I see the same error... >>Richard >> >> >> >OK. Changing last line of /etc/selinux/strict/booleans to >'allow_write_xshm=1' fixes this.... > >tom > > Fixed in selinux-policy-strict-1.23.16-7 -- From dwalsh at redhat.com Tue May 24 15:50:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 11:50:42 -0400 Subject: domains/misc/kernel.te In-Reply-To: <4c4ba15305052210396f384c93@mail.gmail.com> References: <4c4ba15305052210396f384c93@mail.gmail.com> Message-ID: <42934D52.7060400@redhat.com> Tom London wrote: >domains/misc/kernel.te has the following lines: > ># Use capabilities. >allow kernel_t self:capability *; > >allow kernel_t sysfs_t:dir search; >allow kernel_t { usbfs_t usbdevfs_t sysfs_t }:dir search; > ># Run init in the init_t domain. > >Search for sysfs_t is in twice. > >Also, I'm getting avc's for kernel_t for getattr/read for sysfs_t: >May 22 10:04:32 fedora kernel: SELinux: initialized (dev usbfs, type >usbfs), uses genfs_contexts >May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied >{ getattr } for path="/sys/class/input/mouse1" dev=sysfs ino=1850 >scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t >tclass=dir >May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied >{ getattr } for path="/sys/class/input/mouse1/dev" dev=sysfs ino=2090 >scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t >tclass=file >May 22 10:04:32 fedora kernel: audit(1116756222.766:0): avc: denied >{ read } for name=dev dev=sysfs ino=2090 >scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sysfs_t >tclass=file > >Would it be right to replace >allow kernel_t sysfs_t:dir search; >allow kernel_t { usbfs_t usbdevfs_t sysfs_t }:dir search; > >with >r_dir_file(kernel_t, sysfs_t) >allow kernel_t { usbfs_t usbdevfs_t }:dir search; > >tom > > in selinux-policy-*-1.23.16-7 -- From dwalsh at redhat.com Tue May 24 15:54:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 11:54:35 -0400 Subject: /proc {getattr} failures In-Reply-To: <8a239a56050522184222d724ca@mail.gmail.com> References: <8a239a56050522184222d724ca@mail.gmail.com> Message-ID: <42934E3B.8080702@redhat.com> James Z. Li wrote: >targeted policy on FC3 > >/var/log/messages show lots of avcs: >May 22 20:54:42 bengal kernel: audit(1116809682.160:0): avc: denied >{ getattr } for pid=2733 exe=/bin/ps path=/proc/1 dev=proc ino=65538 >scontext=user_u:system_r:httpd_sys_script_t >tcontext=user_u:system_r:unconfined_t tclass=dir >... >May 22 20:54:42 bengal kernel: audit(1116809682.171:0): avc: denied >{ getattr } for pid=2733 exe=/bin/ps path=/proc/2660 dev=proc >ino=174325762 scontext=user_u:system_r:httpd_sys_script_t >tcontext=root:system_r:unconfined_t tclass=dir > >'audit2allow' generates this rule in local.te >allow httpd_sys_script_t unconfined_t:dir { getattr }; > > > I guess the question is, what is this script attemting to do? If you dontaudit this access, does it work? I would advise creating a new script type using apache_domain(mycgi) allow httpd_mycgi_script_t unconfined_t:dir ... Then change to contraint.te to allow httpd_mycgi_script_t. >'make load' shows the assertion error message >Assertion on line 17328 violated by allow httpd_sys_script_t >unconfined_t:dir { getattr }; >make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > >Then I learned that /proc, /selinux, and /sys do not have persistent >labels. What should >I do to solve this problem? Remove that assertion check? > >Btw, anyone has a policy file for Gallery (gallery.sourceforge.net) with httpd? > >Thanks a lot! > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From dwalsh at redhat.com Tue May 24 15:55:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 11:55:31 -0400 Subject: php+mysql under httpd in fc3 In-Reply-To: References: Message-ID: <42934E73.9080807@redhat.com> Stanislav Malyshev wrote: > I run FC3 with targeted policies (default install). I have a problem > running connecting to mysql server from php under apache - the problem > is that httpd/php is denied write access to mysql.sock, something like > this: > > fc3 kernel: audit(1116843116.146:0): avc: denied { write } for > pid=7281 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=375162 > scontext=root:system_r:httpd_t tcontext=user_u:object_r:var_lib_t > tclass=sock_file > > Now, I have seen various modifications to policy sources that would > allow it to work, but what I am asking is if it possible to do it > without rebuilding policy from sources. The reason for this is that we > need to make our ptoduce to install mysql & certain modules using it > on user servers, and we can not count on policy sources being > installed there. Also, the security of mysqld itself does not matter > in this particular case and it is OK for us to run it unrestricted > (it's separate server for this application only without network > connection). The only problem is to allow restricted httpd to connect > to that particular Unix socket. > > I see that default system sources (apache.te) seem to include various > types that seem to allow this, but I have no success in using them. If > I try to use mysqld_var_run_t chcon gives me "Invalid argument", same > with mysqld_db_t. Also, I see that httpd_php_t has can_unix_connect() > rule, while httpd_t does not, however I did not find any documentation > on what these types are, what's teh difference and how one can use > httpd_php_t. I see httpd is running now under httpd_t according to ps > -eZ. > > I tries also to set mysql.sock into tmp_t, then write error > disappears, and this one appears instead: > > fc3 kernel: audit(1116844521.972:0): avc: denied { connectto } for > pid=7275 exe=/usr/sbin/httpd path=/var/lib/mysql/mysql.sock > scontext=root:system_r:httpd_t tcontext=user_u:system_r:unconfined_t > tclass=unix_stream_socket > > I am rather new to all SELinux concepts, so if anyone can give me some > explanations about this or point me to some docs that describe these > things it will be appreciated. > > TIA, Please update to the latest selinux policy and then restart mysql and apache. Dan -- From dwalsh at redhat.com Tue May 24 16:00:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 12:00:32 -0400 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... In-Reply-To: <4c4ba1530505211355236189c@mail.gmail.com> References: <4c4ba1530505211355236189c@mail.gmail.com> Message-ID: <42934FA0.4070606@redhat.com> Tom London wrote: >Running strict/enforcing, latest rawhide. > >Get the following when logging in: >May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user >tbl by (uid=0) >May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied >{ write } for name=dmix.conf dev=hda2 ino=4523476 >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >tclass=file >May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf >May 21 13:30:16 fedora ainit: Error: Permission denied > >The file in questions is /etc/alsa/pcm/dmix.conf. > >/etc/alsa/ainit.conf has: ># ># overwrite target files, if exists ># >overwrite = yes > ># ># first config file - for dmix plugin ># >template_0 = /etc/alsa/pcm/dmix.template >target_0 = /etc/alsa/pcm/dmix.conf >target_root_file_0 = yes > >This seems less than perfect to me.... >Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as >xdm_rw_etc_t? (I don't know who else needs to read these files....) > >tom > > > Do you have any idea if xdm is actually trying to write this file, or could this just be they used the wrong flags when opening the file? Dan -- From selinux at gmail.com Tue May 24 16:09:29 2005 From: selinux at gmail.com (Tom London) Date: Tue, 24 May 2005 09:09:29 -0700 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... In-Reply-To: <42934FA0.4070606@redhat.com> References: <4c4ba1530505211355236189c@mail.gmail.com> <42934FA0.4070606@redhat.com> Message-ID: <4c4ba153050524090946b99b83@mail.gmail.com> On 5/24/05, Daniel J Walsh wrote: > Tom London wrote: > > >Running strict/enforcing, latest rawhide. > > > >Get the following when logging in: > >May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user > >tbl by (uid=0) > >May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied > >{ write } for name=dmix.conf dev=hda2 ino=4523476 > >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t > >tclass=file > >May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf > >May 21 13:30:16 fedora ainit: Error: Permission denied > > > >The file in questions is /etc/alsa/pcm/dmix.conf. > > > >/etc/alsa/ainit.conf has: > ># > ># overwrite target files, if exists > ># > >overwrite = yes > > > ># > ># first config file - for dmix plugin > ># > >template_0 = /etc/alsa/pcm/dmix.template > >target_0 = /etc/alsa/pcm/dmix.conf > >target_root_file_0 = yes > > > >This seems less than perfect to me.... > >Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as > >xdm_rw_etc_t? (I don't know who else needs to read these files....) > > > >tom > > > > > > > Do you have any idea if xdm is actually trying to write this file, or > could this just be they used the wrong flags when opening the file? > No idea. I'll test tonight on my 'strict machine'. tom -- Tom London From Valdis.Kletnieks at vt.edu Tue May 24 17:06:29 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 24 May 2005 13:06:29 -0400 Subject: /proc {getattr} failures In-Reply-To: Your message of "Tue, 24 May 2005 10:47:12 EDT." <1116946032.27904.100.camel@moss-spartans.epoch.ncsc.mil> References: <8a239a56050522184222d724ca@mail.gmail.com> <200505230153.j4N1rgNs027496@turing-police.cc.vt.edu> <1116946032.27904.100.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200505241706.j4OH6Ts2011644@turing-police.cc.vt.edu> On Tue, 24 May 2005 10:47:12 EDT, Stephen Smalley said: > On Sun, 2005-05-22 at 21:53 -0400, Valdis.Kletnieks at vt.edu wrote: > > Am I the only one here who thinks that this is really something that can't > > be supported in the context of the 'targeted' policy, and would be much > > easier to do in 'strict'? > > It shouldn't be done at all, other than to dontaudit these attempts. No > legitimate reason for a CGI script to be probing init's /proc/pid files. I've always been leery of using dontaudit to shut things up - it means that there's a possibility that we miss the early warning signs of an actual attack. I wonder if the cgi script is just doing something like 'ps ax|grep mydaemon' to see if a daemon is running... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From james.zheng.li at gmail.com Tue May 24 17:41:30 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Tue, 24 May 2005 13:41:30 -0400 Subject: How to add a new application in targeted In-Reply-To: <200505240610.j4O6A3EG014762@turing-police.cc.vt.edu> References: <8a239a560505232206328d4b4@mail.gmail.com> <200505240610.j4O6A3EG014762@turing-police.cc.vt.edu> Message-ID: <8a239a5605052410417b516a51@mail.gmail.com> The genral question is that if I write policy files for an application which is currently not in targeted policy, like mydaemon.fc and mydaemon.te. What should I do besides 'make load' in order to let Selinux know that I add a new daemon in targeted ? Thanks. On 5/24/05, Valdis.Kletnieks at vt.edu wrote: > On Tue, 24 May 2005 01:06:14 EDT, "James Z. Li" said: > > I wrote some policy files for sendmail, say > > /etc/selinux/targeted/src/policy/file_contexts/program/sendmail.fc > > /etc/selinux/targeted/src/policy/domain/program/sendmail.te > > Umm.. you *did* know that there's been a sendmail.fc and sendmail.te > in 'targeted' for quite some time, right? > > > From sds at tycho.nsa.gov Tue May 24 18:28:29 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 24 May 2005 14:28:29 -0400 Subject: How to add a new application in targeted In-Reply-To: <8a239a5605052410417b516a51@mail.gmail.com> References: <8a239a560505232206328d4b4@mail.gmail.com> <200505240610.j4O6A3EG014762@turing-police.cc.vt.edu> <8a239a5605052410417b516a51@mail.gmail.com> Message-ID: <1116959309.27904.178.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-05-24 at 13:41 -0400, James Z. Li wrote: > The genral question is that if I write policy files for an application > which is currently not in targeted policy, like mydaemon.fc and > mydaemon.te. What should I do besides 'make load' in order to > let Selinux know that I add a new daemon in targeted ? You need to label the executable with the corresponding executable type, e.g. restorecon /sbin/mydaemon, after loading the new policy. That sets the extended attribute on the executable file, so that SELinux will subsequently perform a domain transition when it is executed. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Wed May 25 00:35:22 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 24 May 2005 20:35:22 -0400 Subject: /proc {getattr} failures In-Reply-To: <200505241706.j4OH6Ts2011644@turing-police.cc.vt.edu> References: <8a239a56050522184222d724ca@mail.gmail.com> <200505230153.j4N1rgNs027496@turing-police.cc.vt.edu> <1116946032.27904.100.camel@moss-spartans.epoch.ncsc.mil> <200505241706.j4OH6Ts2011644@turing-police.cc.vt.edu> Message-ID: <4293C84A.4040502@redhat.com> Valdis.Kletnieks at vt.edu wrote: >On Tue, 24 May 2005 10:47:12 EDT, Stephen Smalley said: > > >>On Sun, 2005-05-22 at 21:53 -0400, Valdis.Kletnieks at vt.edu wrote: >> >> > > > >>>Am I the only one here who thinks that this is really something that can't >>>be supported in the context of the 'targeted' policy, and would be much >>>easier to do in 'strict'? >>> >>> >>It shouldn't be done at all, other than to dontaudit these attempts. No >>legitimate reason for a CGI script to be probing init's /proc/pid files. >> >> > >I've always been leery of using dontaudit to shut things up - it means that there's >a possibility that we miss the early warning signs of an actual attack. > >I wonder if the cgi script is just doing something like 'ps ax|grep mydaemon' >to see if a daemon is running... > > > > kill5 and pidof can also cause these to happen. >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From russell at coker.com.au Wed May 25 05:32:34 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 25 May 2005 15:32:34 +1000 Subject: /proc {getattr} failures In-Reply-To: <200505241706.j4OH6Ts2011644@turing-police.cc.vt.edu> References: <8a239a56050522184222d724ca@mail.gmail.com> <1116946032.27904.100.camel@moss-spartans.epoch.ncsc.mil> <200505241706.j4OH6Ts2011644@turing-police.cc.vt.edu> Message-ID: <200505251532.38052.russell@coker.com.au> On Wednesday 25 May 2005 03:06, Valdis.Kletnieks at vt.edu wrote: > On Tue, 24 May 2005 10:47:12 EDT, Stephen Smalley said: > > On Sun, 2005-05-22 at 21:53 -0400, Valdis.Kletnieks at vt.edu wrote: > > > Am I the only one here who thinks that this is really something that > > > can't be supported in the context of the 'targeted' policy, and would > > > be much easier to do in 'strict'? > > > > It shouldn't be done at all, other than to dontaudit these attempts. No > > legitimate reason for a CGI script to be probing init's /proc/pid files. > > I've always been leery of using dontaudit to shut things up - it means that > there's a possibility that we miss the early warning signs of an actual > attack. If you want to complain about dontaudit then look for file_type - secure_file_type as the thing you want to complain about. > I wonder if the cgi script is just doing something like 'ps ax|grep > mydaemon' to see if a daemon is running... If the cgi script does "ps ax" as a regular operation then there's no way to determine the difference between that and "ps ax" for a hostile operation. Some people don't have cgi scripts running ps. We could have a boolean about this, but if so then the number of booleans would explode and become unmanagable. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at gmail.com Wed May 25 13:30:31 2005 From: selinux at gmail.com (Tom London) Date: Wed, 25 May 2005 06:30:31 -0700 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... In-Reply-To: <4c4ba153050524090946b99b83@mail.gmail.com> References: <4c4ba1530505211355236189c@mail.gmail.com> <42934FA0.4070606@redhat.com> <4c4ba153050524090946b99b83@mail.gmail.com> Message-ID: <4c4ba15305052506307e7b6c7@mail.gmail.com> On 5/24/05, Tom London wrote: > On 5/24/05, Daniel J Walsh wrote: > > Tom London wrote: > > > > >Running strict/enforcing, latest rawhide. > > > > > >Get the following when logging in: > > >May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user > > >tbl by (uid=0) > > >May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied > > >{ write } for name=dmix.conf dev=hda2 ino=4523476 > > >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t > > >tclass=file > > >May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf > > >May 21 13:30:16 fedora ainit: Error: Permission denied > > > > > >The file in questions is /etc/alsa/pcm/dmix.conf. > > > > > >/etc/alsa/ainit.conf has: > > ># > > ># overwrite target files, if exists > > ># > > >overwrite = yes > > > > > ># > > ># first config file - for dmix plugin > > ># > > >template_0 = /etc/alsa/pcm/dmix.template > > >target_0 = /etc/alsa/pcm/dmix.conf > > >target_root_file_0 = yes > > > > > >This seems less than perfect to me.... > > >Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as > > >xdm_rw_etc_t? (I don't know who else needs to read these files....) > > > > > >tom > > > > > > > > > > > Do you have any idea if xdm is actually trying to write this file, or > > could this just be they used the wrong flags when opening the file? > > > No idea. > > I'll test tonight on my 'strict machine'. > > tom > Running strict/permissive, I get this: May 25 06:19:54 fedora gdm(pam_unix)[2695]: session opened for user tbl by (uid=0) May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied { write } for pid=2739 comm="ainit" name=pcm dev=hda2 ino=4524122 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=dir May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied { add_name } for pid=2739 comm="ainit" name=dmix.conf scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=dir May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied { create } for pid=2739 comm="ainit" name=dmix.conf scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=file May 25 06:19:54 fedora kernel: audit(1117027194.340:0): avc: denied { write } for pid=2739 comm="ainit" name=dmix.conf dev=hda2 ino=4522361 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=file May 25 06:19:56 fedora gconfd (tbl-2801): starting (version 2.10.0), pid 2801 user 'tbl' So it looks like xdm wants to really create/write this.... Logging out does this: May 25 06:24:54 fedora gconfd (tbl-2801): Exiting May 25 06:24:54 fedora gdm(pam_unix)[2695]: session closed for user tbl May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied { write } for pid=3184 comm="ainit" name=pcm dev=hda2 ino=4524122 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=dir May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied { remove_name } for pid=3184 comm="ainit" name=dmix.conf.lock dev=hda2 ino=4522777 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=dir May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied { unlink } for pid=3184 comm="ainit" name=dmix.conf.lock dev=hda2 ino=4522777 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t tclass=file May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied { unix_read unix_write } for pid=3184 comm="ainit" key=1947154681 scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t tclass=shm May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied { associate } for pid=3184 comm="ainit" key=1947154681 scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t tclass=shm May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied { destroy } for pid=3184 comm="ainit" key=1947154681 scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t tclass=shm tom -- Tom London From dwalsh at redhat.com Wed May 25 14:44:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 25 May 2005 10:44:13 -0400 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... In-Reply-To: <4c4ba15305052506307e7b6c7@mail.gmail.com> References: <4c4ba1530505211355236189c@mail.gmail.com> <42934FA0.4070606@redhat.com> <4c4ba153050524090946b99b83@mail.gmail.com> <4c4ba15305052506307e7b6c7@mail.gmail.com> Message-ID: <42948F3D.9030908@redhat.com> Tom London wrote: >On 5/24/05, Tom London wrote: > > >>On 5/24/05, Daniel J Walsh wrote: >> >> >>>Tom London wrote: >>> >>> >>> >>>>Running strict/enforcing, latest rawhide. >>>> >>>>Get the following when logging in: >>>>May 21 13:30:16 fedora gdm(pam_unix)[2946]: session opened for user >>>>tbl by (uid=0) >>>>May 21 13:30:16 fedora kernel: audit(1116707416.740:0): avc: denied >>>>{ write } for name=dmix.conf dev=hda2 ino=4523476 >>>>scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >>>>tclass=file >>>>May 21 13:30:16 fedora ainit: Failed to open file /etc/alsa/pcm/dmix.conf >>>>May 21 13:30:16 fedora ainit: Error: Permission denied >>>> >>>>The file in questions is /etc/alsa/pcm/dmix.conf. >>>> >>>>/etc/alsa/ainit.conf has: >>>># >>>># overwrite target files, if exists >>>># >>>>overwrite = yes >>>> >>>># >>>># first config file - for dmix plugin >>>># >>>>template_0 = /etc/alsa/pcm/dmix.template >>>>target_0 = /etc/alsa/pcm/dmix.conf >>>>target_root_file_0 = yes >>>> >>>>This seems less than perfect to me.... >>>>Should dmix.conf (and dsnoop.conf) be someplace else? Labeled as >>>>xdm_rw_etc_t? (I don't know who else needs to read these files....) >>>> >>>>tom >>>> >>>> >>>> >>>> >>>> >>>Do you have any idea if xdm is actually trying to write this file, or >>>could this just be they used the wrong flags when opening the file? >>> >>> >>> >>No idea. >> >>I'll test tonight on my 'strict machine'. >> >>tom >> >> >> >Running strict/permissive, I get this: > >May 25 06:19:54 fedora gdm(pam_unix)[2695]: session opened for user >tbl by (uid=0) >May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied >{ write } for pid=2739 comm="ainit" name=pcm dev=hda2 ino=4524122 >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >tclass=dir >May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied >{ add_name } for pid=2739 comm="ainit" name=dmix.conf >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >tclass=dir >May 25 06:19:54 fedora kernel: audit(1117027194.325:0): avc: denied >{ create } for pid=2739 comm="ainit" name=dmix.conf >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >tclass=file >May 25 06:19:54 fedora kernel: audit(1117027194.340:0): avc: denied >{ write } for pid=2739 comm="ainit" name=dmix.conf dev=hda2 >ino=4522361 scontext=system_u:system_r:xdm_t >tcontext=system_u:object_r:etc_t tclass=file >May 25 06:19:56 fedora gconfd (tbl-2801): starting (version 2.10.0), >pid 2801 user 'tbl' > >So it looks like xdm wants to really create/write this.... > >Logging out does this: > >May 25 06:24:54 fedora gconfd (tbl-2801): Exiting >May 25 06:24:54 fedora gdm(pam_unix)[2695]: session closed for user tbl >May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied >{ write } for pid=3184 comm="ainit" name=pcm dev=hda2 ino=4524122 >scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:etc_t >tclass=dir >May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied >{ remove_name } for pid=3184 comm="ainit" name=dmix.conf.lock >dev=hda2 ino=4522777 scontext=system_u:system_r:xdm_t >tcontext=system_u:object_r:etc_t tclass=dir >May 25 06:24:54 fedora kernel: audit(1117027494.313:0): avc: denied >{ unlink } for pid=3184 comm="ainit" name=dmix.conf.lock dev=hda2 >ino=4522777 scontext=system_u:system_r:xdm_t >tcontext=system_u:object_r:etc_t tclass=file >May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied >{ unix_read unix_write } for pid=3184 comm="ainit" key=1947154681 >scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t >tclass=shm >May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied >{ associate } for pid=3184 comm="ainit" key=1947154681 >scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t >tclass=shm >May 25 06:24:54 fedora kernel: audit(1117027494.349:0): avc: denied >{ destroy } for pid=3184 comm="ainit" key=1947154681 >scontext=system_u:system_r:xdm_t tcontext=tbl:staff_r:staff_t >tclass=shm > >tom > > Ok looks like we need policy for ainit. and this directory. Anyone up for it? :^) Please open a bugzilla, so I will get it done, if no one volunteers. Dan -- From selinux at gmail.com Wed May 25 15:47:39 2005 From: selinux at gmail.com (Tom London) Date: Wed, 25 May 2005 08:47:39 -0700 Subject: ainit (xdm_t) wants to write /etc/alsa/pcm/dmix.conf (etc_t) ... In-Reply-To: <42948F3D.9030908@redhat.com> References: <4c4ba1530505211355236189c@mail.gmail.com> <42934FA0.4070606@redhat.com> <4c4ba153050524090946b99b83@mail.gmail.com> <4c4ba15305052506307e7b6c7@mail.gmail.com> <42948F3D.9030908@redhat.com> Message-ID: <4c4ba1530505250847523cc5b1@mail.gmail.com> On 5/25/05, Daniel J Walsh wrote: > Ok looks like we need policy for ainit. and this directory. > > Anyone up for it? :^) > > Please open a bugzilla, so I will get it done, if no one volunteers. > > > > Dan OK: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158772 -- Tom London From selinux at gmail.com Wed May 25 16:51:51 2005 From: selinux at gmail.com (Tom London) Date: Wed, 25 May 2005 09:51:51 -0700 Subject: relabeling of /etc/sysconfig/network-scripts/ifcfg-* (targeted) Message-ID: <4c4ba1530505250951533afc3f@mail.gmail.com> Running targeted/enforcing, latest rawhide. Each time I boot, running 'restorecon -v -R /etc' produces: restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth1 context system_u:object_r:etc_t->system_u:object_r:net_conf_t restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth0 context system_u:object_r:etc_t->system_u:object_r:net_conf_t restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth1 context system_u:object_r:net_conf_t->system_u:object_r:etc_t restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth0 context system_u:object_r:net_conf_t->system_u:object_r:etc_t Actually, after the restorecon, the labels are unchanged, that is, the first 2 are still etc_t, not net_conf_t. I'm not using NetworkManager, just the base stuff.... Nothing is broken, but I don't understand this.... tom -- Tom London From selinux at gmail.com Wed May 25 16:59:40 2005 From: selinux at gmail.com (Tom London) Date: Wed, 25 May 2005 09:59:40 -0700 Subject: ptal (hpoj) fixes ? Message-ID: <4c4ba1530505250959579c5c00@mail.gmail.com> Running strict/enforcing, latest rawhide. When hpoj/cups starts, I get: May 25 07:52:07 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652, dev=, pid=2189, e=2, t=1117032727 ptal-mlcd successfully initialized. May 25 07:52:07 fedora ptal-printd: ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using /var/run/ptal-printd/mlc_usb_PSC_900_Series*. May 25 07:52:09 fedora kernel: audit(1117032729.705:10): avc: denied { name_bind } for pid=2192 comm="ptal-photod" src=5703 scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t tclass=tcp_socket May 25 07:52:09 fedora ptal-photod: ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, listening on port 5703. May 25 07:52:12 fedora kernel: audit(1117032732.982:11): avc: denied { write } for pid=2189 comm="ptal-mlcd" name=002 dev=usbfs ino=4435 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=file May 25 07:52:13 fedora ptal-mlcd: SYSLOG at /usr/src/build/533581-i386/BUILD/hpoj-0.91/mlcd/ExMgr.h:646, dev=, pid=2189, e=5, t=1117032733 ptal-mlcd successfully activated, mode=1284.4. So allow ptal_t usbfs_t:file write; appears needed. For the name_bind avc, should ptal-photod be labeled ptal_t so we get a transition from initrc_t to ptal_t? tom -- Tom London From aleksander.adamowski.fedora at altkom.pl Thu May 26 01:39:52 2005 From: aleksander.adamowski.fedora at altkom.pl (Aleksander Adamowski) Date: Thu, 26 May 2005 03:39:52 +0200 Subject: HELP: transition denied regardless of policy? Message-ID: <429528E8.2070301@altkom.pl> Hi! I'm having a problem with FC3 strict policy. Basically, I've customised the policy to cover all that I need on that system, but there's one last denial that I'm unable to remedy: May 26 03:26:01 machinename kernel: audit(1117070761.996:0): avc: denied { transition } for pid=11773 exe=/bin/bash path=/home/twiki/bin/mailnotify dev=hda1 ino=51463 scontext=root:sysadm_r:sysadm_crond_t tcontext=root:system_r:twiki_t tclass=process (where /home/twiki/bin/mailnotify has a context of system_u:object_r:twiki_exec_t.) This is directly related to my twiki.te policy: #BEGIN daemon_domain(twiki) var_lib_domain(twiki) domain_auto_trans(httpd_t, twiki_exec_t, twiki_t) # daemon_domain(twiki) gets this done anyway: #role_transition sysadm_r twiki_exec_t system_r; domain_auto_trans(sysadm_crond_t, twiki_exec_t, twiki_t) # domain_auto_tras should do it, but duplicating it doesn't hurt: role sysadm_r types twiki_t; allow sysadm_crond_t twiki_t:process transition; # exe=/usr/bin/perl path=/etc/ld.so.cache : allow twiki_t etc_t:file { getattr read }; allow httpd_t twiki_exec_t:dir { getattr search }; allow httpd_t twiki_exec_t:file ioctl; allow httpd_t twiki_var_lib_t:dir { getattr read search }; allow httpd_t twiki_var_lib_t:file { append getattr ioctl read }; allow twiki_t bin_t:dir { search }; allow twiki_t bin_t:file { getattr }; allow twiki_t crond_t:fifo_file { ioctl read write }; allow twiki_t home_root_t:dir { search }; allow twiki_t twiki_exec_t:dir { search }; allow twiki_t urandom_device_t:chr_file { read }; allow twiki_t unlabeled_t:dir { getattr read search }; allow httpd_sys_script_t httpd_runtime_t:file write; allow httpd_sys_script_t httpd_t:tcp_socket ioctl; allow httpd_sys_script_t twiki_var_lib_t:dir { add_name remove_name search write }; allow httpd_sys_script_t twiki_var_lib_t:file { create getattr read unlink }; allow httpd_t twiki_var_lib_t:dir { add_name remove_name write }; allow httpd_t twiki_var_lib_t:file { create rename setattr unlink write }; #END The problem is, although the domain_auto_trans(sysadm_crond_t, twiki_exec_t, twiki_t) ...allows for: allow sysadm_crond_t twiki_t:process transition; And I've even allowed that process transition (allow sysadm_crond_t twiki_t:process transition;) explicitly a few rows later (actually audit2allow has given me this). But the transition to root:system_r:twiki_t is still denied. Am I missing something? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From SELinux at Compucenter.org Thu May 26 06:31:20 2005 From: SELinux at Compucenter.org (George J. Jahchan) Date: Thu, 26 May 2005 09:31:20 +0300 Subject: Auditd & Strict Policy 1.19 In-Reply-To: <1116598642.12489.88.camel@moss-spartans.epoch.ncsc.mil> Message-ID: As you correctly mentioned, auditd worked by adding audit and audit_control to the capability section of flask/access_vectors. Noticed that audit.log shows "avc: denied" kernel events that are not reported in messages. Are these suppressed by the dontaudit rules in the policy? Thank you for your help. -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com]On Behalf Of Stephen Smalley Sent: Friday, May 20, 2005 5:17 PM To: George J. Jahchan Cc: Fedora SE Linux List Subject: Re: Auditd & Strict Policy 1.19 On Fri, 2005-05-20 at 18:24 +0300, George J. Jahchan wrote: > Followed your instructions, adding 'audit write & audit_control' at the end of > the capability section in the policy/flask/access_vectors elicits the following > error message when making the policy: That's audit_write and audit_control - two permissions, not three. > ... too many permissions to fit in an access vector. Off-by-one bug in checkpolicy, fixed after FC3, but shouldn't matter as you only need two permissions here. > Bearing in mind that the machines are live production hosts, how do you > recommend we address this (from the available choices below)? > > 1) For a limited period of time (until FC4 is released), we can live with having > to switch to permissive mode in order to start the audit daemon, and revert back > to enforcing mode after it starts. The hosts are not taken down that often. > > 2) We can upgrade to FC4 strict policy, with no assurance that it will work or > not cause other problems. > > 3) We can upgrade to pre-release FC4, again with no assurance that it will work > or will not introduce new weaknesses. I've sent (via separate email) a copy of our current policy/flask/security_classes, policy/flask/access_vectors, policy/domains/program/auditd.te, and policy/file_contexts/program/auditd.fc, so you can at least try those to see if they resolve your issue for auditd (and they shouldn't impact anything else). If that resolves your problem, then feel free to stay with FC3 until FC4 is out (schedule says June 6). -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list From SELinux at Compucenter.org Thu May 26 06:41:29 2005 From: SELinux at Compucenter.org (George J. Jahchan) Date: Thu, 26 May 2005 09:41:29 +0300 Subject: Multi-level security Message-ID: Is there a way in SE Linux to set security levels to sources / targets and deny access from a source to any target whose security level is higher than that of the source? From SELinux at Compucenter.org Thu May 26 06:41:31 2005 From: SELinux at Compucenter.org (George J. Jahchan) Date: Thu, 26 May 2005 09:41:31 +0300 Subject: Private user directory trees. Message-ID: How can we setup private user directory that is (recursively) off-limits to anyone but the owner (including root), so long as the policy is being enforced. These directory trees would be similarly named for all users: "/home_dir_path/Private/" for instance. From sds at tycho.nsa.gov Thu May 26 12:22:34 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 May 2005 08:22:34 -0400 Subject: HELP: transition denied regardless of policy? In-Reply-To: <429528E8.2070301@altkom.pl> References: <429528E8.2070301@altkom.pl> Message-ID: <1117110154.2644.23.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-05-26 at 03:39 +0200, Aleksander Adamowski wrote: > Hi! > > I'm having a problem with FC3 strict policy. Basically, I've customised > the policy to cover all that I need on that system, but there's one last > denial that I'm unable to remedy: > > May 26 03:26:01 machinename kernel: audit(1117070761.996:0): avc: > denied { transition } for pid=11773 exe=/bin/bash > path=/home/twiki/bin/mailnotify dev=hda1 ino=51463 > scontext=root:sysadm_r:sysadm_crond_t tcontext=root:system_r:twiki_t > tclass=process Note that the above transition involves a role change, not just a type change. Hence, you are hitting a constraint in policy/constraints that says that a process may not change roles unless it meets certain restrictions. The role transition is occurring because you have declared it as a daemon domain, thus it is trying to transition to the system_r role for system processes. Questions: - Do you truly want this to run in the same domain when it is run from httpd as when it is run from the cron job? This implies that it has the same permissions in both cases. For example, I might envision the cron job as being more trusted (as it was set up by the admin) than the process spawned from httpd, and I doubt you want a httpd-spawned process to be able to attack the cron job if it happens to be running simultaneously. You can define two different domains, with a shared exec type, such that the cron job will transition to one domain and httpd will transition to another domain when they run the program. - Is using daemon_domain truly appropriate here? I'm a little skeptical. - Why are you giving it access to unlabeled_t? Suggests some other problem with your filesystem labels or use of non-labeled fs. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu May 26 12:32:34 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 May 2005 08:32:34 -0400 Subject: Auditd & Strict Policy 1.19 In-Reply-To: References: Message-ID: <1117110754.2644.34.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-05-26 at 09:31 +0300, George J. Jahchan wrote: > As you correctly mentioned, auditd worked by adding audit and audit_control to > the capability section of flask/access_vectors. > > Noticed that audit.log shows "avc: denied" kernel events that are not reported > in messages. Are these suppressed by the dontaudit rules in the policy? When auditd is running, the kernel sends audit messages to it and auditd writes them to /var/log/audit/audit.log per /etc/auditd.conf, so they do not appear in messages at all. When no auditd is running, audit messages are handled via the normal kernel logging mechanism, i.e. read by klogd which in turn sends them along to syslogd, which in turn writes them to /var/log/messages or elsewhere per /etc/syslog.conf. If a dontaudit rule exists, then SELinux won't generate an audit message at all for that denial, and it won't appear in any log. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu May 26 12:45:43 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 May 2005 08:45:43 -0400 Subject: Multi-level security In-Reply-To: References: Message-ID: <1117111543.2644.47.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-05-26 at 09:41 +0300, George J. Jahchan wrote: > Is there a way in SE Linux to set security levels to sources / targets and deny > access from a source to any target whose security level is higher than that of > the source? Yes, but the MLS support wasn't enabled in FC3. It is included in the FC4 kernels, but is only enabled if you build a MLS-enabled policy (by default, MLS is disabled in the policy). Dan Walsh has an experimental MLS policy package that he is presently maintaining on his site (see the selinux-policy-mls* packages under ftp://people.redhat.com/dwalsh/SELinux/Fedora/) that should be available in the FC5 development tree when it opens (after FC4 is released). Alternatively, you can emulate MLS in SELinux via TE rules, by defining domains and types that correspond to the desired MLS levels and explicitly defining how they may interact via TE allow rules in a manner that is consistent with MLS restrictions. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu May 26 13:43:41 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 26 May 2005 09:43:41 -0400 Subject: Private user directory trees. In-Reply-To: References: Message-ID: <1117115021.2644.86.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-05-26 at 09:41 +0300, George J. Jahchan wrote: > How can we setup private user directory that is (recursively) off-limits to > anyone but the owner (including root), so long as the policy is being enforced. > > These directory trees would be similarly named for all users: > "/home_dir_path/Private/" for instance. First, what do you mean by "root"? An arbitrary uid 0 process like a daemon or setuid application, or an authenticated administrative user? The former is easy to restrict, as it only has the capabilities and permissions allowed by the SELinux policy for its domain. The latter is difficult, as an admin often has legitimate need to access all files (e.g. backup), can subvert the OS (e.g. by installing updated OS software or configuration files that include his own modifications), and can bypass any OS restrictions (e.g. boot from CD or remove the disk and put it into a system under his control). Second, do you truly want per-user separation or just per- role/domain/level? MAC is more oriented toward the latter. For per- user separation, you have two options: - use the existing Linux DAC support, i.e. set file modes in the usual manner, and only use SELinux to help restrict what processes can override DAC, - define per-user entries in policy/users, define a new file type for these directories, and define a constraint in policy/constraints so that this type may only be accessed by a process with the same SELinux user identity. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu May 26 15:29:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 26 May 2005 11:29:33 -0400 Subject: relabeling of /etc/sysconfig/network-scripts/ifcfg-* (targeted) In-Reply-To: <4c4ba1530505250951533afc3f@mail.gmail.com> References: <4c4ba1530505250951533afc3f@mail.gmail.com> Message-ID: <4295EB5D.601@redhat.com> Tom London wrote: >Running targeted/enforcing, latest rawhide. > >Each time I boot, running 'restorecon -v -R /etc' produces: > >restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth1 context >system_u:object_r:etc_t->system_u:object_r:net_conf_t >restorecon reset /etc/sysconfig/network-scripts/ifcfg-eth0 context >system_u:object_r:etc_t->system_u:object_r:net_conf_t >restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth1 >context system_u:object_r:net_conf_t->system_u:object_r:etc_t >restorecon reset /etc/sysconfig/networking/profiles/default/ifcfg-eth0 >context system_u:object_r:net_conf_t->system_u:object_r:etc_t > >Actually, after the restorecon, the labels are unchanged, that is, the >first 2 are still etc_t, not net_conf_t. > >I'm not using NetworkManager, just the base stuff.... > >Nothing is broken, but I don't understand this.... > >tom > > I am changing back to etc_t, Turns out there was a bug in NetworkManager. Dan -- From dwalsh at redhat.com Thu May 26 15:49:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 26 May 2005 11:49:42 -0400 Subject: ptal (hpoj) fixes ? In-Reply-To: <4c4ba1530505250959579c5c00@mail.gmail.com> References: <4c4ba1530505250959579c5c00@mail.gmail.com> Message-ID: <4295F016.9070600@redhat.com> Tom London wrote: >Running strict/enforcing, latest rawhide. > >When hpoj/cups starts, I get: > >May 25 07:52:07 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652, >dev=, pid=2189, e=2, t=1117032727 >ptal-mlcd successfully initialized. >May 25 07:52:07 fedora ptal-printd: >ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using >/var/run/ptal-printd/mlc_usb_PSC_900_Series*. >May 25 07:52:09 fedora kernel: audit(1117032729.705:10): avc: denied >{ name_bind } for pid=2192 comm="ptal-photod" src=5703 >scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:port_t >tclass=tcp_socket >May 25 07:52:09 fedora ptal-photod: >ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, >listening on port 5703. >May 25 07:52:12 fedora kernel: audit(1117032732.982:11): avc: denied >{ write } for pid=2189 comm="ptal-mlcd" name=002 dev=usbfs ino=4435 >scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t >tclass=file >May 25 07:52:13 fedora ptal-mlcd: SYSLOG at >/usr/src/build/533581-i386/BUILD/hpoj-0.91/mlcd/ExMgr.h:646, >dev=, pid=2189, e=5, t=1117032733 > ptal-mlcd successfully activated, mode=1284.4. > >So >allow ptal_t usbfs_t:file write; >appears needed. > > > ok >For the name_bind avc, should ptal-photod be labeled ptal_t so we get >a transition from initrc_t to ptal_t? > > Yes. >tom > > -- From acastillo at condorweb.net Fri May 27 15:55:29 2005 From: acastillo at condorweb.net (Ma. Alejandra Castillo M.) Date: Fri, 27 May 2005 11:55:29 -0400 Subject: policy SSH References: <1117115021.2644.86.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> Dear, i need to know the current policy for ssh, is there such a policy? saludos -- Mai From aleksander.adamowski at altkom.pl Fri May 27 19:39:53 2005 From: aleksander.adamowski at altkom.pl (Aleksander Adamowski) Date: Fri, 27 May 2005 21:39:53 +0200 Subject: HELP: transition denied regardless of policy? In-Reply-To: <1117110154.2644.23.camel@moss-spartans.epoch.ncsc.mil> References: <429528E8.2070301@altkom.pl> <1117110154.2644.23.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <42977789.7060107@altkom.pl> Stephen Smalley wrote: >>May 26 03:26:01 machinename kernel: audit(1117070761.996:0): avc: >>denied { transition } for pid=11773 exe=/bin/bash >>path=/home/twiki/bin/mailnotify dev=hda1 ino=51463 >>scontext=root:sysadm_r:sysadm_crond_t tcontext=root:system_r:twiki_t >>tclass=process >> >> > >Note that the above transition involves a role change, not just a type >change. > Got it! sysadm_crond_t doesn't have the privrole attribute. Thanks for pointing it out, I didn't notice that, mainly because the sysadm_crond_t domain creation process is quite convoluted (it traverses several macros from different files). I had to modify macros/program/crond_macros.te by adding priv_system_role attribute to domains generated by the crond_domain macro: --- crond_macros.te.orig 2004-05-07 17:24:24.000000000 +0200 +++ crond_macros.te 2005-05-27 21:32:57.000000000 +0200 @@ -19,9 +20,13 @@ define(`crond_domain',` # Derived domain for user cron jobs, user user_crond_domain if not system ifelse(`system', `$1', ` -type $1_crond_t, domain, privlog, privmail; +type $1_crond_t, domain, privlog, privmail, nscd_client_domain; +', ` +ifelse(`sysadm', `$1', ` +type $1_crond_t, domain, user_crond_domain, priv_system_role; ', ` type $1_crond_t, domain, user_crond_domain; +') # Access user files and dirs. allow $1_crond_t home_root_t:dir search; @@ -31,8 +36,8 @@ Soon, checkpolicy for FC3 will have support for typeattribute construct: https://www.redhat.com/archives/fedora-cvs-commits/2005-May/msg00593.html And I will be able to simply augment the generated sysadm_crond_t domain with privrole from my program .te file like that: typeattribute sysadm_crond_t privrole; Until then, I can live with the manual modification to the macro, but it will get overwritten with every policy sources RPM upgrade. >Questions: >- Do you truly want this to run in the same domain when it is run from >httpd as when it is run from the cron job? This implies that it has the >same permissions in both cases. For example, I might envision the cron >job as being more trusted (as it was set up by the admin) than the >process spawned from httpd, and I doubt you want a httpd-spawned process >to be able to attack the cron job if it happens to be running >simultaneously. You can define two different domains, with a shared >exec type, such that the cron job will transition to one domain and >httpd will transition to another domain when they run the program. > > Thanks for suggestion. Thinking about that, I could make a separate domain for this process. But it needs access to files similar to httpd, so I might end up with duplicating lots of httpd domain AVC for it, which might beat the purpose... OTOH, i I label all those files it would make a lot more sense. I might not have enough time for that, though. >- Is using daemon_domain truly appropriate here? I'm a little >skeptical. > > Possibly not, I'll look into that, thanks! >- Why are you giving it access to unlabeled_t? Suggests some other >problem with your filesystem labels or use of non-labeled fs. > > Well, this .te is a work in progress, and I've made a preliminary version of that domain, relabeled the FS, then put all the errors through audit2allow to get AVC rules. I've put them into the .te file and right now I'm going through them, looking at suspicious ones and deciding what to do with them. So I'll take care of this one - yes, it's probably a problem with labels somewhere on my filesystem. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From lfsjeremy at gmail.com Fri May 27 22:42:41 2005 From: lfsjeremy at gmail.com (Jeremy Utley) Date: Fri, 27 May 2005 15:42:41 -0700 Subject: FC3 Strict Policy Message-ID: <3aaec88405052715426d8bed57@mail.gmail.com> Hello Everyone! I'm trying my first foray into experimenting with SELinux, and am failing before I even get very far. I've installed Fedora Core 3 and have enabled the SELinux strict policy. The only way I can log into the system now is if I put the system into permissive mode. Here's the denied errors I'm getting: May 27 15:15:18 localhost kernel: audit(1117232118.583:0): avc: denied { getattr } for pid=4380 exe=/sbin/unix_chkpwd path=/var/run/winbindd dev=sda1 ino=1653914 scontext=system_u:system_r:system_chkpwd_t tcontext=system_u:object_r:var_run_t tclass=dir May 27 15:15:18 localhost kernel: audit(1117232118.586:0): avc: denied { read write } for pid=4381 exe=/sbin/unix_chkpwd name=tty2 dev=tmpfs ino=2025 scontext=system_u:system_r:system_chkpwd_t tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file May 27 15:15:18 localhost kernel: audit(1117232118.589:0): avc: denied { getattr } for pid=4291 exe=/bin/login path=/var/run/winbindd dev=sda1 ino=1653914 scontext=system_u:system_r:local_login_t tcontext=system_u:object_r:var_run_t tclass=dir May 27 15:15:18 localhost kernel: audit(1117232118.590:0): avc: denied { getattr } for pid=4291 exe=/bin/login path=/root dev=sda1 ino=1864129 scontext=system_u:system_r:local_login_t tcontext=root:object_r:staff_home_dir_t tclass=dir The system is fully up to date via yum. I realize some problems can be expected when using the strict policy as opposed to targeted - but I can't believe the strict policy would ship in a configuration that prevents logging into the system. Anyone got any suggestions - I can't believe I'm the only person who's faced this, but I did a lot of searching online and couldn't find anything. Jeremy From bobk at ocf.berkeley.edu Sat May 28 01:41:44 2005 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Fri, 27 May 2005 18:41:44 -0700 Subject: FC3 Strict Policy In-Reply-To: <3aaec88405052715426d8bed57@mail.gmail.com> References: <3aaec88405052715426d8bed57@mail.gmail.com> Message-ID: <1117244504.4235.1.camel@chaucer> Try relabeling: touch /.autorelabel Then reboot your system. Bob On Fri, 2005-05-27 at 15:42 -0700, Jeremy Utley wrote: > Hello Everyone! > > I'm trying my first foray into experimenting with SELinux, and am > failing before I even get very far. I've installed Fedora Core 3 and > have enabled the SELinux strict policy. The only way I can log into > the system now is if I put the system into permissive mode. Here's > the denied errors I'm getting: > > May 27 15:15:18 localhost kernel: audit(1117232118.583:0): avc: > denied { getattr } for pid=4380 exe=/sbin/unix_chkpwd > path=/var/run/winbindd dev=sda1 ino=1653914 > scontext=system_u:system_r:system_chkpwd_t > tcontext=system_u:object_r:var_run_t tclass=dir > May 27 15:15:18 localhost kernel: audit(1117232118.586:0): avc: denied { read > write } for pid=4381 exe=/sbin/unix_chkpwd name=tty2 dev=tmpfs > ino=2025 scontext=system_u:system_r:system_chkpwd_t > tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file > May 27 15:15:18 localhost kernel: audit(1117232118.589:0): avc: > denied { getattr } for pid=4291 exe=/bin/login > path=/var/run/winbindd dev=sda1 ino=1653914 > scontext=system_u:system_r:local_login_t > tcontext=system_u:object_r:var_run_t tclass=dir > May 27 15:15:18 localhost kernel: audit(1117232118.590:0): avc: > denied { getattr } for pid=4291 exe=/bin/login path=/root dev=sda1 > ino=1864129 scontext=system_u:system_r:local_login_t > tcontext=root:object_r:staff_home_dir_t tclass=dir > > The system is fully up to date via yum. I realize some problems can > be expected when using the strict policy as opposed to targeted - but > I can't believe the strict policy would ship in a configuration that > prevents logging into the system. > > Anyone got any suggestions - I can't believe I'm the only person who's > faced this, but I did a lot of searching online and couldn't find > anything. > > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Bob Kashani http://www.ocf.berkeley.edu/~bobk/garnome From lkml at mac.com Sat May 28 09:39:59 2005 From: lkml at mac.com (Felipe Alfaro Solana) Date: Sat, 28 May 2005 11:39:59 +0200 Subject: policy SSH In-Reply-To: <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> References: <1117115021.2644.86.camel@moss-spartans.epoch.ncsc.mil> <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> Message-ID: On 27 May 2005, at 17:55, Ma. Alejandra Castillo M. wrote: > Dear, i need to know the current policy for ssh, is there such a > policy? What kind of policy? SELinux policy? Maintenance/upgrades policy? Please, explain? PS: Now, in Spanish: ?Qu? tipo de pol?tica? ?La pol?tica de SELinux? ?Pol?tica de mantenimiento y actualizaciones? Por favor, expl?cate mejor. From Valdis.Kletnieks at vt.edu Sun May 29 17:16:09 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 29 May 2005 13:16:09 -0400 Subject: On building a smaller 'strict' policy. Message-ID: <200505291716.j4THGA9b009438@turing-police.cc.vt.edu> OK, so I finally got fed up with having the 'strict' policy take up 4,821 or so *pages* of slab entries for avc_node, and decided to see how much I could pare it down. Moving stuff I didn't actually have or use from domains/program/foo.te into unused/foo.te more or less worked, and only using up 2,230 pages of slab (a noticable difference on a 256M laptop). Nits: In an effort to minimize the size even *more*, I tried nuking the corresponding macros/program/foo_macros.te files, since much of the bulk of the policy.conf is created by FOO_macros.te expanding a whole bunch of USER_FOO_t for all user types (cdrecord chunks out some 100 per role, as near as I can tell). The resmgrd, kerberos, and ypbind entries in macros/programs end up getting referenced in ways that fail gloriously when you try to build policy, so obviously, wholesale skipping over macros the way the .tc files get skipped over for unused .te isn't going to work. Fortunately, the four I had problems with are defined in such a way that there's little real growth in the policy because they're wrapped in a "ifdef(`foo.te')" Would it be a Good Idea to be more agressive in wrapping the other FOO_macros.te with such an ifdef? Or does this become a *total* non-issue with the soon-to-arrive 'loadable policy module' stuff? For what it's worth: [/etc/selinux/strict/src/policy]3 egrep -v '^#|^$' policy.conf | wc 28831 218148 1768137 A major savings. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From selinux at gmail.com Sun May 29 18:47:58 2005 From: selinux at gmail.com (Tom London) Date: Sun, 29 May 2005 11:47:58 -0700 Subject: more ptal_t (strict) Message-ID: <4c4ba153050529114742b88046@mail.gmail.com> Running strict/enforcing, latest rawhide. Previous suggested mods to cups.te for ptal-photod are insufficient. The following appears needed to allow gimp to connect up to the scanner; --- cups.te.save 2005-05-28 09:56:03.000000000 -0700 +++ cups.te 2005-05-29 11:30:10.000000000 -0700 @@ -150,6 +150,11 @@ allow ptal_t self:capability { chown sys_rawio }; allow ptal_t self:{ unix_dgram_socket unix_stream_socket } create_socket_perms; allow ptal_t self:unix_stream_socket { listen accept }; +can_network_tcp(ptal_t, self) +allow ptal_t port_t:tcp_socket name_bind; +allow userdomain ptal_t:unix_stream_socket connectto; +allow userdomain ptal_var_run_t:sock_file write; +allow userdomain ptal_var_run_t:dir search; allow ptal_t self:fifo_file rw_file_perms; allow ptal_t device_t:dir read; allow ptal_t printer_device_t:chr_file rw_file_perms; With these changes, gimp can acquire scanned image. A few comments: ptal-photod seems to only use 127.0.0.1 for tcp networking, and the allow for search on ptal_var_run_t:dir required 'enableaudit' to find. Is there an easier/better way to express this? Sorry for the incomplete update last time.... tom -- Tom London From ivg2 at cornell.edu Sun May 29 19:24:35 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 29 May 2005 15:24:35 -0400 Subject: [ PATCH ]: evolution/thunderbird/gconf/orbit/other stuff - comments? Message-ID: <1117394675.23920.0.camel@localhost.localdomain> Features: - policy for evolution - policy for thunderbird - policy for generic mail client that they derive from - policy for gconf - common gnome macros (mozilla, evolution, thunderbird, gift, games, gconf) use those - macro for secure storage at .gnome(2)_private - attempt at per role fonts - per application labeled orbit sockets - per application labeled ice sockets ( this is rather broken right now ) - begin structuring things to confine bonobo in the future - introduce untrusted type, but don't do anything with it yet - restricted home_domain macro set to allow specifying transition class in /home. Default is now { dir } only, which is more restrictive than before. - rework gift networking rules - start writing ethereal policy ( not finished ) - bugfixes I believe this is against selinux-policy-strict-sources-1.23.17-2 Issues: (see my other message (nsa-list) - file_type_auto_trans is not sufficient) - need to patch libfontconfig to create font cache with proper type - need to patch libgnome to create .gnome2 .gnome2_private, and .gnome2/share/*fonts* with correct type - need to patch ORBit to create /tmp/orbit-* with correct type - need to patch libICE to create /tmp/.ICE_unix with correct type - need to give getfscreate/setfscreate privileges to all of those (just like it's done for orbit_domain) - need to patch evolution to create autosave composer files in ~/.evolution, not in $HOME - need to fix everything relating to $HOME/.ICEauthority - need to finish evolution exchange policy - need to finish ethereal policy - need to update boolean file Status: - can log in with almost no denials. There are the usual strict policy bugs, there's some iceauth related denials, but nothing too bad. Evolution works, but it keeps popping up warning boxes every 15 seconds saying it can't write its autosave files to $HOME - that needs to be patched. -- Ivan Gyurdiev Cornell University -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 60411 bytes Desc: not available URL: From justin.conover at gmail.com Sun May 29 20:26:05 2005 From: justin.conover at gmail.com (Justin Conover) Date: Sun, 29 May 2005 15:26:05 -0500 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: References: Message-ID: On 5/29/05, Justin Conover wrote: > Can't create a logical volume, have no problems doing it on another > rawhide box. Plenty of space, I've done this ++++ times and for some > reason this box is just causing a problem. "permission denied" > > Could this be a dieing HD? The box has 4x36GB scsi drives in it, in > Raid0/lvm config. > > > [root at trinity ~]# lvcreate -L2G -nLogVol08 VolGroup01 > Logical volume "LogVol08" created > [root at trinity ~]# mke2fs -j /dev/VolGroup01/LogVol08 > mke2fs 1.37 (21-Mar-2005) > Could not stat /dev/VolGroup01/LogVol08 --- Permission denied > [root at trinity ~]# mkfs.ext3 -F -j /dev/VolGroup01/LogVol08 > mke2fs 1.37 (21-Mar-2005) > mkfs.ext3: Permission denied while trying to determine filesystem size > # mkfs.ext3 -F -j /dev/mapper/VolGroup01-LogVol08 > mke2fs 1.37 (21-Mar-2005) > mkfs.ext3: Permission denied while trying to determine filesystem size > ]# mkfs.ext3 -F -j /dev/mapper/VolGroup01-LogVol08 > mke2fs 1.37 (21-Mar-2005) > mkfs.ext3: Permission denied while trying to determine filesystem size > [root at trinity ~]# mke2fs -f /dev/mapper/VolGroup01-LogVol08 > mke2fs: bad fragment size - /dev/mapper/VolGroup01-LogVol08 > > [root at trinity ~]# id -Z > root:system_r:unconfined_t > [root at trinity ~]# ls -la /sbin/ | grep mkfs > -rwxr-xr-x 1 root root 7192 May 3 23:30 mkfs > -rwxr-xr-x 1 root root 15872 May 3 23:30 mkfs.cramfs > -rwxr-xr-x 3 root root 35888 May 10 04:17 mkfs.ext2 > -rwxr-xr-x 3 root root 35888 May 10 04:17 mkfs.ext3 > -rwxr-xr-x 3 root root 30180 Apr 28 09:31 mkfs.msdos > -rwxr-xr-x 3 root root 30180 Apr 28 09:31 mkfs.vfat > [root at trinity ~]# lsmod | grep ext3 > ext3 133193 8 > jbd 61785 1 ext3 > > [root at trinity ~]# vgdisplay > --- Volume group --- > VG Name VolGroup01 > System ID > Format lvm2 > Metadata Areas 1 > Metadata Sequence No 12 > VG Access read/write > VG Status resizable > MAX LV 0 > Cur LV 9 > Open LV 8 > Max PV 0 > Cur PV 1 > Act PV 1 > VG Size 101.28 GB > PE Size 32.00 MB > Total PE 3241 > Alloc PE / Size 672 / 21.00 GB > Free PE / Size 2569 / 80.28 GB > VG UUID 8A535T-TOpJ-Fzkg-BREJ-TJE7-E3Lp-nChZOg > > > The differences on the box that work don't work are following, > > Works (x86_64/rawhide) > # rpm -qa | grep lvm > lvm2-2.01.08-1.0 <----- WHY 2? > lvm2-2.01.08-2.1 > system-config-lvm-0.9.32-1.0 > # rpm -qa | grep e2fsprogs > e2fsprogs-devel-1.37-4 > e2fsprogs-1.37-4.x86_64 > e2fsprogs-1.37-4.i386 > > > > Doesn't work (x86/Rawhide) > # rpm -qa | grep lvm > lvm2-2.01.08-2.1 > system-config-lvm-0.9.32-1.0 > # rpm -qa | grep e2fsprogs > e2fsprogs-devel-1.37-4 > e2fsprogs-1.37-4 > Both box's are in a soft raid/lvm config, Not sure why the i386 box > defaulted to VolGroup01 but shouldn't matter in any case. > Well, it looks like the problem is between mkfs and selinux. The box that works is set to # sestatus SELinux status: disabled While the one that doesn't work is running selinux, so is this a bug, can anyone else mkfs on selinux=1 box's? I haven't run into this before and I know I have other box's running selinux that i've created new fs on. From ivg2 at cornell.edu Sun May 29 20:26:20 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 29 May 2005 16:26:20 -0400 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <4c4ba153050529114742b88046@mail.gmail.com> References: <4c4ba153050529114742b88046@mail.gmail.com> Message-ID: <1117398380.24683.30.camel@localhost.localdomain> > +can_network_tcp(ptal_t, self) Can someone clarify how networking rules are supposed to work. 1) There is poor documentation on all network macros - they all take 2 or 3 arguments, and only one is documented. 2) There is optional socket type and port type. Looking at policy, those don't seem to be used very often. Is that a bad thing? 3) Then there's name_connect and name_bind. Why are those not incorporated in any network macros, but at the same time you have the ability to specify a port type in base_can_network. Basically I've been writing: can_network_client(domain) allow domain specific_port:tcp_socket/udp_socket name_connect; can_network_server(domain) allow domain specific_port:tcp_socket/udp_socket name_bind; Now this seems wrong - what's are the proper rules? It seems to me that name_bind and name_connect should be integrated w/ network_macros, and I should specify a port/socket_type on network macros that I invoke. .... Then there wouldn't be need for special purpose name_connect macros like can_resolve, can_ldap... define(`can_ldap',` ifdef(`slapd.te',` can_network_client_tcp($1, `ldap_port_t') allow $1 ldap_port_t:tcp_socket name_connect; ') ') Why does slapd.te have to be present to name_connect to a ldap port? This seems wrong... I need to connect to ldap from evolution. The ldap port is not defined in slapd.te. > +allow ptal_t port_t:tcp_socket name_bind; This lets it bind to any port... why not a specific one? -- Ivan Gyurdiev Cornell University From justin.conover at gmail.com Sun May 29 20:28:45 2005 From: justin.conover at gmail.com (Justin Conover) Date: Sun, 29 May 2005 15:28:45 -0500 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: References: Message-ID: > Well, it looks like the problem is between mkfs and selinux. The box > that works is set to > > # sestatus > SELinux status: disabled > > > While the one that doesn't work is running selinux, so is this a bug, > can anyone else mkfs on selinux=1 box's? I haven't run into this > before and I know I have other box's running selinux that i've created > new fs on. > Forgot to include the fact I booted with selinux=0 and made the file system. From selinux at gmail.com Mon May 30 01:23:56 2005 From: selinux at gmail.com (Tom London) Date: Sun, 29 May 2005 18:23:56 -0700 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <1117398380.24683.30.camel@localhost.localdomain> References: <4c4ba153050529114742b88046@mail.gmail.com> <1117398380.24683.30.camel@localhost.localdomain> Message-ID: <4c4ba15305052918231fbe3e6d@mail.gmail.com> On 5/29/05, Ivan Gyurdiev wrote: > > > +can_network_tcp(ptal_t, self) > > Can someone clarify how networking rules are supposed to work. > > 1) There is poor documentation on all network macros - they all > take 2 or 3 arguments, and only one is documented. > > 2) There is optional socket type and port type. Looking at policy, > those don't seem to be used very often. Is that a bad thing? > > 3) Then there's name_connect and name_bind. > Why are those not incorporated in any network macros, > but at the same time you have the ability to specify a port type > in base_can_network. > > Basically I've been writing: > > can_network_client(domain) > allow domain specific_port:tcp_socket/udp_socket name_connect; > > can_network_server(domain) > allow domain specific_port:tcp_socket/udp_socket name_bind; > > Now this seems wrong - what's are the proper rules? > It seems to me that name_bind and name_connect should be integrated > w/ network_macros, and I should specify a port/socket_type on network > macros that I invoke. > > .... > Then there wouldn't be need for special purpose name_connect macros > like can_resolve, can_ldap... > > define(`can_ldap',` > ifdef(`slapd.te',` > can_network_client_tcp($1, `ldap_port_t') > allow $1 ldap_port_t:tcp_socket name_connect; > ') > ') > > Why does slapd.te have to be present to name_connect to a ldap port? > This seems wrong... I need to connect to ldap from evolution. > The ldap port is not defined in slapd.te. > > > +allow ptal_t port_t:tcp_socket name_bind; > > This lets it bind to any port... why not a specific one? > > -- > Ivan Gyurdiev > Cornell University > > My error on can_network_tcp(). Should be 'can_network_tcp(ptal_t)'. I agree with your comment on 'name_bind'. I thought 'can_network_tcp()' was just a combination of the client and server cases. Regarding specific port. Yeah, you're correct. ptal-photod wants to connect on 5703: May 28 10:01:53 fedora kernel: audit(1117299713.078:31): avc: denied { name_bind } for pid=3576 comm="ptal-photod" src=5703 scontext=root:system_r:ptal_t tcontext=system_u:object_r:port_t tclass=tcp_socket Havent't done this before. So I do this by adding something like the following to net_contexts? ifdef(`cups.te', `portcon tcp 5703 system_u:object_r:ptal_port_t') and add something like the following to types/network.te? ifdef(`cups.te', `type ptal_port_t, port_type, reserved_port_type;') and then change 'allow ptal_t port_t:tcp_socket name_bind' to? allow ptal_t ptal_t:ptal_port_t name_bind; Is that right? A better/simpler way to do this? tom -- Tom London From selinux at gmail.com Mon May 30 01:31:08 2005 From: selinux at gmail.com (Tom London) Date: Sun, 29 May 2005 18:31:08 -0700 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <4c4ba15305052918231fbe3e6d@mail.gmail.com> References: <4c4ba153050529114742b88046@mail.gmail.com> <1117398380.24683.30.camel@localhost.localdomain> <4c4ba15305052918231fbe3e6d@mail.gmail.com> Message-ID: <4c4ba15305052918313730a9c0@mail.gmail.com> On 5/29/05, Tom London wrote: > On 5/29/05, Ivan Gyurdiev wrote: > allow ptal_t ptal_t:ptal_port_t name_bind; Oops.... meant allow ptal_t ptal_port_t:tcp_socket name_bind; tom -- Tom London From dwalsh at redhat.com Mon May 30 09:35:15 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 May 2005 05:35:15 -0400 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <1117398380.24683.30.camel@localhost.localdomain> References: <4c4ba153050529114742b88046@mail.gmail.com> <1117398380.24683.30.camel@localhost.localdomain> Message-ID: <429ADE53.6000009@redhat.com> Ivan Gyurdiev wrote: >>+can_network_tcp(ptal_t, self) >> >> > >Can someone clarify how networking rules are supposed to work. > >1) There is poor documentation on all network macros - they all >take 2 or 3 arguments, and only one is documented. > > There should be 9 that are used can_network (Allow all network activity) can_network_server (tcp and udp, requires a name_bind) can_network_client (tcp and udp, requires a name_connect) can_network_client_udp (udp requires) can_network_client_tcp (tcp requires a name_connect) can_network_server_udp (udp requires a name_bind) can_network_server_tcp (tcp requires a name_bind) can_network_tcp (tcp requires a name_connect and a name_bind) can_network_udp (udp requires a name_bind) The other port type parameter can be used to "lock down" udp connects since name_connect does not work for udp. >2) There is optional socket type and port type. Looking at policy, >those don't seem to be used very often. Is that a bad thing? > > > socket type is used to lock down tcp/udp, port type is used to lock down whicp ports udp can connect to. socket type is basically used by other macros. >3) Then there's name_connect and name_bind. >Why are those not incorporated in any network macros, >but at the same time you have the ability to specify a port type >in base_can_network. > > I don't recall why, but name_connect was added the way it was because name_bind was done that way. Also passing a lot of parameters in macros is somewhat frowned on, since it complicates the code quite a bit. It was decided to break these functions in to multiple function calls. >Basically I've been writing: > >can_network_client(domain) >allow domain specific_port:tcp_socket/udp_socket name_connect; > >can_network_server(domain) >allow domain specific_port:tcp_socket/udp_socket name_bind; > >Now this seems wrong - what's are the proper rules? >It seems to me that name_bind and name_connect should be integrated >w/ network_macros, and I should specify a port/socket_type on network >macros that I invoke. > >.... >Then there wouldn't be need for special purpose name_connect macros >like can_resolve, can_ldap... > >define(`can_ldap',` >ifdef(`slapd.te',` >can_network_client_tcp($1, `ldap_port_t') >allow $1 ldap_port_t:tcp_socket name_connect; >') >') > >Why does slapd.te have to be present to name_connect to a ldap port? >This seems wrong... I need to connect to ldap from evolution. >The ldap port is not defined in slapd.te. > > > It is wrong. I will fix. >>+allow ptal_t port_t:tcp_socket name_bind; >> >> > >This lets it bind to any port... why not a specific one? > > > Not sure. Does ptal use portmap? If not then this is a bug. -- From dwalsh at redhat.com Mon May 30 09:52:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 May 2005 05:52:35 -0400 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <4c4ba15305052918231fbe3e6d@mail.gmail.com> References: <4c4ba153050529114742b88046@mail.gmail.com> <1117398380.24683.30.camel@localhost.localdomain> <4c4ba15305052918231fbe3e6d@mail.gmail.com> Message-ID: <429AE263.2060209@redhat.com> Tom London wrote: >On 5/29/05, Ivan Gyurdiev wrote: > > >>>+can_network_tcp(ptal_t, self) >>> >>> >>Can someone clarify how networking rules are supposed to work. >> >>1) There is poor documentation on all network macros - they all >>take 2 or 3 arguments, and only one is documented. >> >>2) There is optional socket type and port type. Looking at policy, >>those don't seem to be used very often. Is that a bad thing? >> >>3) Then there's name_connect and name_bind. >>Why are those not incorporated in any network macros, >>but at the same time you have the ability to specify a port type >>in base_can_network. >> >>Basically I've been writing: >> >>can_network_client(domain) >>allow domain specific_port:tcp_socket/udp_socket name_connect; >> >>can_network_server(domain) >>allow domain specific_port:tcp_socket/udp_socket name_bind; >> >>Now this seems wrong - what's are the proper rules? >>It seems to me that name_bind and name_connect should be integrated >>w/ network_macros, and I should specify a port/socket_type on network >>macros that I invoke. >> >>.... >>Then there wouldn't be need for special purpose name_connect macros >>like can_resolve, can_ldap... >> >>define(`can_ldap',` >>ifdef(`slapd.te',` >>can_network_client_tcp($1, `ldap_port_t') >>allow $1 ldap_port_t:tcp_socket name_connect; >>') >>') >> >>Why does slapd.te have to be present to name_connect to a ldap port? >>This seems wrong... I need to connect to ldap from evolution. >>The ldap port is not defined in slapd.te. >> >> >> >>>+allow ptal_t port_t:tcp_socket name_bind; >>> >>> >>This lets it bind to any port... why not a specific one? >> >>-- >>Ivan Gyurdiev >>Cornell University >> >> >> >> >My error on can_network_tcp(). Should be 'can_network_tcp(ptal_t)'. I >agree with your comment on 'name_bind'. > >I thought 'can_network_tcp()' was just a combination of the client and >server cases. > >Regarding specific port. Yeah, you're correct. ptal-photod wants to >connect on 5703: >May 28 10:01:53 fedora kernel: audit(1117299713.078:31): avc: denied >{ name_bind } for pid=3576 comm="ptal-photod" src=5703 >scontext=root:system_r:ptal_t tcontext=system_u:object_r:port_t >tclass=tcp_socket > >Havent't done this before. > >So I do this by adding something like the following to net_contexts? >ifdef(`cups.te', `portcon tcp 5703 system_u:object_r:ptal_port_t') > >and add something like the following to types/network.te? >ifdef(`cups.te', `type ptal_port_t, port_type, reserved_port_type;') > >and then change 'allow ptal_t port_t:tcp_socket name_bind' to? >allow ptal_t ptal_t:ptal_port_t name_bind; > >Is that right? A better/simpler way to do this? > tom > > Can ptal be a client? If not then you should call can_network_server_tcp If it can be a client, you need a name_connect allow rule. -- From dwalsh at redhat.com Mon May 30 09:56:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 30 May 2005 05:56:31 -0400 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: References: Message-ID: <429AE34F.2080404@redhat.com> Justin Conover wrote: >>Well, it looks like the problem is between mkfs and selinux. The box >>that works is set to >> >># sestatus >>SELinux status: disabled >> >> >>While the one that doesn't work is running selinux, so is this a bug, >>can anyone else mkfs on selinux=1 box's? I haven't run into this >>before and I know I have other box's running selinux that i've created >>new fs on. >> >> >> > >Forgot to include the fact I booted with selinux=0 and made the file system. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > You machine needs to be relabeled. If you boot as selinux=0 you will need to relabel when you want to run selinux again. Using enforcing=0 (setenforce 0) is a better option, since it maintains the file context. touch /.autorelabel reboot -- From justin.conover at gmail.com Mon May 30 13:30:49 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 30 May 2005 08:30:49 -0500 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: <429AE34F.2080404@redhat.com> References: <429AE34F.2080404@redhat.com> Message-ID: > >Forgot to include the fact I booted with selinux=0 and made the file system. > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > You machine needs to be relabeled. If you boot as selinux=0 you will > need to relabel when you want to run > selinux again. Using enforcing=0 (setenforce 0) is a better option, > since it maintains the file context. > touch /.autorelabel > reboot > Right, but why did it not let me created a file system with selinux=1? I did a fresh install of fc4t3 on this box too, with the same results. From ivg2 at cornell.edu Mon May 30 13:54:30 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 30 May 2005 09:54:30 -0400 Subject: Questions about network_macros [ was: Re: more ptal_t (strict) ] In-Reply-To: <429ADE53.6000009@redhat.com> References: <4c4ba153050529114742b88046@mail.gmail.com> <1117398380.24683.30.camel@localhost.localdomain> <429ADE53.6000009@redhat.com> Message-ID: <1117461270.17742.19.camel@localhost.localdomain> > There should be 9 that are used > can_network (Allow all network activity) > can_network_server (tcp and udp, requires a name_bind) > can_network_client (tcp and udp, requires a name_connect) > can_network_client_udp (udp requires) > can_network_client_tcp (tcp requires a name_connect) > can_network_server_udp (udp requires a name_bind) > can_network_server_tcp (tcp requires a name_bind) > can_network_tcp (tcp requires a name_connect and a name_bind) > can_network_udp (udp requires a name_bind) > > The other port type parameter can be used to "lock down" udp connects > since name_connect does not work for udp. So why don't we add name_connect and name_bind to the macros where required. > I don't recall why, but name_connect was added the way it was because > name_bind was done that way. ... > Also passing a lot of parameters in macros is somewhat frowned on, since > it complicates the code quite > a bit. It was decided to break these functions in to multiple function > calls. I don't argue with the breaking of calls - that seems like a good idea, but if you say name_bind and name_connect are required in certain scenarios, then we should probably add those to the networking macros. For example, the port_type argument in base_can_macros could be used for name_connect, not only for send_msg/rcv_msg. For name_bind I guess you'd need another argument, since servers should be able to send/receive to all ports (actually - should this be all unrestristed ports?) > >Basically I've been writing: > > > >can_network_client(domain) > >allow domain specific_port:tcp_socket/udp_socket name_connect; > > > >can_network_server(domain) > >allow domain specific_port:tcp_socket/udp_socket name_bind; I'm thinking something like: - include name_bind and name_connect where appropriate - require socket_type (but only if udp/tcp not specified) - include port_type in server for the port that server can bind to (maybe require port_type too - why is all of this optional if you want to enforce stricter policy?) can_network_client(domain, socket_type, (, port_type)?); can_network_client_(tcp|udp) (domain (,port_type)?); socket_type - type of socket over which to communicate port_type - server port the client is authorized to talk to can_network_server(domain, socket_type, (, port_type)?); can_network_server_(tcp_udp) (domain (,port_type)?); socket_type - type of socket over which to communicate port_type - server port the server is authorized to bind to/listen on (it can connect to all unrestricted ports (but not name_connect?)); or something like that... Then instead of calling can_resolve: can_network_client_udp(domain, dns_port_t) or can_network_client(domain, udp_socket, dns_port_t) Instead of can_ldap: can_network_client_tcp(domain, ldap_port_t) or can_network_client(domain, tcp_socket, ldap_port_t) -- Ivan Gyurdiev Cornell University From Valdis.Kletnieks at vt.edu Mon May 30 16:14:25 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 May 2005 12:14:25 -0400 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: Your message of "Mon, 30 May 2005 08:30:49 CDT." References: <429AE34F.2080404@redhat.com> Message-ID: <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> On Mon, 30 May 2005 08:30:49 CDT, Justin Conover said: > Right, but why did it not let me created a file system with selinux=1? > I did a fresh install of fc4t3 on this box too, with the same > results. If you didn't already post the avc messages that mkfs generated (I've already deleted the first few msgs of this thread), could you do so? They'd be in /var/log/messages (if you have a default syslog config and aren't using auditd) or in /var/log/audit/audit.log if you have auditd running.... Although I'm suspecting the problem is, as others have mentioned, that your system needs to be relabeled, and that an improper label on something broke the mkfs. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From justin.conover at gmail.com Mon May 30 16:33:28 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 30 May 2005 11:33:28 -0500 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> References: <429AE34F.2080404@redhat.com> <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> Message-ID: On 5/30/05, Valdis.Kletnieks at vt.edu wrote: > On Mon, 30 May 2005 08:30:49 CDT, Justin Conover said: > > > Right, but why did it not let me created a file system with selinux=1? > > I did a fresh install of fc4t3 on this box too, with the same > > results. > > If you didn't already post the avc messages that mkfs generated (I've already > deleted the first few msgs of this thread), could you do so? They'd be > in /var/log/messages (if you have a default syslog config and aren't using > auditd) or in /var/log/audit/audit.log if you have auditd running.... > > Although I'm suspecting the problem is, as others have mentioned, that your > system needs to be relabeled, and that an improper label on something broke > the mkfs. Ok, still have problems, set "enforcing=0" and relabeled and here is all the bits. # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 19 Policy from config file: targeted # mkdir /lvm_test_dir # vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 4 Metadata Sequence No 11 VG Access read/write VG Status resizable MAX LV 0 Cur LV 9 Open LV 9 Max PV 0 Cur PV 4 Act PV 4 VG Size 135.28 GB PE Size 32.00 MB Total PE 4329 Alloc PE / Size 1408 / 44.00 GB Free PE / Size 2921 / 91.28 GB VG UUID TxPt55-hDYK-lJmC-Aohb-LbGe-glnr-7046hW # lvcreate -L2G -nLogVol10 VolGroup00 Logical volume "LogVol10" created # mkfs.ext3 /dev/VolGroup00/LogVol10 mke2fs 1.37 (21-Mar-2005) Could not stat /dev/VolGroup00/LogVol10 --- Permission denied # grep mkfs audit/audit.log type=SYSCALL msg=audit(1117397418.851:206892): arch=40000003 syscall=195 success=no exit=-13 a0=bf8aebdf a1=bf8605d8 a2=838ff4 a3=0 items=1 pid=2247 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file type=SYSCALL msg=audit(1117397783.921:261196): arch=40000003 syscall=195 success=no exit=-13 a0=bf856bdf a1=bf7eed58 a2=bc7ff4 a3=0 items=1 pid=2308 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t tclass=file type=SYSCALL msg=audit(1117470602.109:1094349): arch=40000003 syscall=195 success=no exit=-13 a0=bf87fc52 a1=bf87e7a8 a2=a1dff4 a3=0 items=1 pid=4009 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkfs.ext3" exe="/sbin/mkfs.ext3" type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs ino=56551 scontext=root:system_r:fsadm_t tcontext=root:object_r:device_t tclass=blk_file From selinux at gmail.com Mon May 30 17:18:06 2005 From: selinux at gmail.com (Tom London) Date: Mon, 30 May 2005 10:18:06 -0700 Subject: ptal, strict patch - thanks for the comments Message-ID: <4c4ba1530505301018500c26a8@mail.gmail.com> Daniel, Ivan, thanks for the helpful comments. Appears that ptal only needs 'server', so I changed to 'can_network_server_tcp(ptal_t)'. I defined 'ptal_port_t' in network.te, and bound it to port 5703 in network_contexts. Hope this is better. Please correct.... tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: ptal.diffs Type: application/octet-stream Size: 1472 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Mon May 30 17:25:20 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 May 2005 13:25:20 -0400 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: Your message of "Mon, 30 May 2005 11:33:28 CDT." References: <429AE34F.2080404@redhat.com> <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> Message-ID: <200505301725.j4UHPKXi014249@turing-police.cc.vt.edu> On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said: OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;) > # lvcreate -L2G -nLogVol10 VolGroup00 > Logical volume "LogVol10" created > > # mkfs.ext3 /dev/VolGroup00/LogVol10 > mke2fs 1.37 (21-Mar-2005) > Could not stat /dev/VolGroup00/LogVol10 --- Permission denied Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate left LogVol10 labelled correctly - although I suspect that it got left what lvm thought it should be, and the policy wanted something else.... > # grep mkfs audit/audit.log > type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } > for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t > tclass=file This one looks like an attempt to scribble on a file called fedora.img - can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name fedora.img -ls' and perhaps ls -lZ the file? (Anybody recognize this one? I'm guessing it's a mkinitrd and dm-7 is /tmp...) > type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } > for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t > tclass=file Another one of the same... > type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } > for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs > ino=56551 scontext=root:system_r:fsadm_t > tcontext=root:object_r:device_t tclass=blk_file Here's the one that's causing yu the pain, and yes, it's borked up, and no, it doesn't apear to be your fault - the system (lvm in particular) could be doing a better job of labelling... Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will work just fine, as they're created as fixed_disk_device_t. At least on my box, the symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the targets in /dev/mapper are tmpfs_t (quite borked) of all things. Fortuitously, we have this in fsadm.te: # for /dev/shm allow fsadm_t tmpfs_t:dir { getattr search }; allow fsadm_t tmpfs_t:file { read write }; which seems to be likely to allow the access for all the wrong reasons. I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and /dev/mapper/* entries for the same device are the same type (a nasty security exposure otherwise...) How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc to fix the /dev/mapper entries: --- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 @@ -12,6 +12,7 @@ /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t /dev/lvm -c system_u:object_r:fixed_disk_device_t +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t /dev/mapper/control -c system_u:object_r:lvm_control_t /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t At least on my system, that leaves the /dev/mapper/* entries more sane.... (Justin - the above patch won't fly unless you have policy-sources installed. If you're feeling brave, crazy, and adventurous, make a similar change to /etc/selinux/strict/contexts/files/file_contexts, and then do a 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;) After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10' But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need to add a 'follow symlink' in lvm.te? We can't fix this one in the file_contexts, because that dirname is essentially user-selected - on my system it's /dev/rootvg (guess who comes from an AIX background? ;) Or is there other borkedness here, and that it's the /dev/mapper/* that's causing Justin's indigestion, but we're reporting the context of the symlink rather than the target that's actually failing? (Anybody want to devise a quick test case for this one?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From justin.conover at gmail.com Mon May 30 20:02:44 2005 From: justin.conover at gmail.com (Justin Conover) Date: Mon, 30 May 2005 15:02:44 -0500 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: <200505301725.j4UHPKXi014249@turing-police.cc.vt.edu> References: <429AE34F.2080404@redhat.com> <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> <200505301725.j4UHPKXi014249@turing-police.cc.vt.edu> Message-ID: On 5/30/05, Valdis.Kletnieks at vt.edu wrote: > On Mon, 30 May 2005 11:33:28 CDT, Justin Conover said: > > OK, with this info, I'm convinced that (a) you're not nuts, (b) your system is > labelled the way we told it to be labelled, and (c) we told it the wrong thing. ;) > Not so fast on "A" :D > > # lvcreate -L2G -nLogVol10 VolGroup00 > > Logical volume "LogVol10" created > > > > # mkfs.ext3 /dev/VolGroup00/LogVol10 > > mke2fs 1.37 (21-Mar-2005) > > Could not stat /dev/VolGroup00/LogVol10 --- Permission denied > > Could you do a 'ls -lZ /dev/VolGroup00'? I'd like to verify that lvcreate > left LogVol10 labelled correctly - although I suspect that it got left what > lvm thought it should be, and the policy wanted something else.... # ls -lZ /dev/VolGroup00 lrwxrwxrwx root root system_u:object_r:device_t LogVol00 -> /dev/mapper/VolGroup00-LogVol00 lrwxrwxrwx root root system_u:object_r:device_t LogVol01 -> /dev/mapper/VolGroup00-LogVol01 lrwxrwxrwx root root system_u:object_r:device_t LogVol02 -> /dev/mapper/VolGroup00-LogVol02 lrwxrwxrwx root root system_u:object_r:device_t LogVol03 -> /dev/mapper/VolGroup00-LogVol03 lrwxrwxrwx root root system_u:object_r:device_t LogVol04 -> /dev/mapper/VolGroup00-LogVol04 lrwxrwxrwx root root system_u:object_r:device_t LogVol05 -> /dev/mapper/VolGroup00-LogVol05 lrwxrwxrwx root root system_u:object_r:device_t LogVol06 -> /dev/mapper/VolGroup00-LogVol06 lrwxrwxrwx root root system_u:object_r:device_t LogVol07 -> /dev/mapper/VolGroup00-LogVol07 lrwxrwxrwx root root system_u:object_r:device_t LogVol08 -> /dev/mapper/VolGroup00-LogVol08 lrwxrwxrwx root root system_u:object_r:device_t LogVol10 -> /dev/mapper/VolGroup00-LogVol10 > > > # grep mkfs audit/audit.log > > type=AVC msg=audit(1117397418.851:206892): avc: denied { getattr } > > for pid=2247 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 > > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t > > tclass=file > > This one looks like an attempt to scribble on a file called fedora.img - > can you do a 'grep dm-7 /proc/mounts' and then do a 'find /filesys -name > fedora.img -ls' and perhaps ls -lZ the file? > fedora.img is part of some Xen stuff I was doing, which initially started this whole thing of mkfs not working. > (Anybody recognize this one? I'm guessing it's a mkinitrd and dm-7 is /tmp...) > > > type=AVC msg=audit(1117397783.921:261196): avc: denied { getattr } > > for pid=2308 comm="mkfs.ext3" name=fedora.img dev=dm-7 ino=12 > > scontext=root:system_r:fsadm_t tcontext=root:object_r:file_t > > tclass=file > > Another one of the same... > > > type=AVC msg=audit(1117470602.109:1094349): avc: denied { getattr } > > for pid=4009 comm="mkfs.ext3" name=VolGroup00-LogVol10 dev=tmpfs > > ino=56551 scontext=root:system_r:fsadm_t > > tcontext=root:object_r:device_t tclass=blk_file > > Here's the one that's causing yu the pain, and yes, it's borked up, and no, > it doesn't apear to be your fault - the system (lvm in particular) could be > doing a better job of labelling... > > Hmm.. I'll place bets that if you do a 'mkfs.ext3 /dev/dm-N' that it will work > just fine, as they're created as fixed_disk_device_t. At least on my box, the > symlink entries in /dev/VolGroup00 are being created as 'device_t' - and the > targets in /dev/mapper are tmpfs_t (quite borked) of all things. > > Fortuitously, we have this in fsadm.te: > > # for /dev/shm > allow fsadm_t tmpfs_t:dir { getattr search }; > allow fsadm_t tmpfs_t:file { read write }; > > which seems to be likely to allow the access for all the wrong reasons. > > I'm thinking the symlinks in /dev/VolGroup00 should be fixed_disk_device_t rather > than device_t - do others concur? And I'm suspecting the stuff in /dev/mapper > needs to be set to fixed_disk_device_t as well - that way the /dev/dm-* and > /dev/mapper/* entries for the same device are the same type (a nasty security > exposure otherwise...) > > How do we get lvm to DTRT here? We can add a line to file_contexts/program/lvm.fc > to fix the /dev/mapper entries: > > --- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 > +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 > @@ -12,6 +12,7 @@ > /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t > /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t > /dev/lvm -c system_u:object_r:fixed_disk_device_t > +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t > /dev/mapper/control -c system_u:object_r:lvm_control_t > /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t > /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t > > At least on my system, that leaves the /dev/mapper/* entries more sane.... > > (Justin - the above patch won't fly unless you have policy-sources installed. > If you're feeling brave, crazy, and adventurous, make a similar change to > /etc/selinux/strict/contexts/files/file_contexts, and then do a > 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first.. ;) > > After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10' > > But that still leaves the symlinks in /dev/VolGroup00 set wrong. Do we need > to add a 'follow symlink' in lvm.te? We can't fix this one in the file_contexts, > because that dirname is essentially user-selected - on my system it's /dev/rootvg > (guess who comes from an AIX background? ;) > > Or is there other borkedness here, and that it's the /dev/mapper/* that's causing > Justin's indigestion, but we're reporting the context of the symlink rather than > the target that's actually failing? (Anybody want to devise a quick test case > for this one?) > I have no problem doing some of this if someone else chimes in too, it's a new box I'm working on so there is nothing that a new install wont cure for a borked system. From Valdis.Kletnieks at vt.edu Mon May 30 20:14:30 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 30 May 2005 16:14:30 -0400 Subject: mkfs.ext3: Permission denied while trying to determine filesystem size In-Reply-To: Your message of "Mon, 30 May 2005 15:02:44 CDT." References: <429AE34F.2080404@redhat.com> <200505301614.j4UGEP7v011250@turing-police.cc.vt.edu> <200505301725.j4UHPKXi014249@turing-police.cc.vt.edu> Message-ID: <200505302014.j4UKEXpL021010@turing-police.cc.vt.edu> On Mon, 30 May 2005 15:02:44 CDT, Justin Conover said: > Not so fast on "A" :D Well, the *current* evidence indicates you're not off the deep end on this specific issue, anyhow.. ;) > fedora.img is part of some Xen stuff I was doing, which initially > started this whole thing of mkfs not working. We probably need to come back sometime and address the issues of mkfs on a file intended for loopback-mount - that's a separate borkage.. > > --- file_contexts/program/lvm.fc.dist 2005-05-20 14:53:12.000000000 -0400 > > +++ file_contexts/program/lvm.fc 2005-05-30 13:10:03.000000000 -0400 > > @@ -12,6 +12,7 @@ > > /etc/lvm/lock(/.*)? system_u:object_r:lvm_lock_t > > /var/lock/lvm(/.*)? system_u:object_r:lvm_lock_t > > /dev/lvm -c system_u:object_r:fixed_disk_device_t > > +/dev/mapper/.* -c system_u:object_r:fixed_disk_device_t > > /dev/mapper/control -c system_u:object_r:lvm_control_t > > /lib/lvm-10/.* -- system_u:object_r:lvm_exec_t > > /lib/lvm-200/.* -- system_u:object_r:lvm_exec_t > > > > At least on my system, that leaves the /dev/mapper/* entries more sane.... > > > > (Justin - the above patch won't fly unless you have policy-sources installe d. > > If you're feeling brave, crazy, and adventurous, make a similar change to > > /etc/selinux/strict/contexts/files/file_contexts, and then do a > > 'restorecon -v -R /dev' - make sure to save a backup of file_contexts first .. ;) > > > > After that, you *should* be able to do a 'mkfs.ext3 /dev/mapper/VolGroup00-LogVol10' > I have no problem doing some of this if someone else chimes in too, > it's a new box I'm working on so there is nothing that a new install > wont cure for a borked system. If you can try the file_contexts tweak I mentioned, and verify that you can or can't do a mkfs on /dev/dm-N and /dev/mapper/VolGrouo00-LogVol10, that would help some (and at least give you a known-good workaround while we come up with a proper fix. Even if I've recommended something stupid, a re-install will clear it. ;) /dev/VolGroup00/LogVol?? will require some other fix which I'd speculate on, but I have to be at a barbeque in 30 mins.. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From selinux at gmail.com Tue May 31 00:47:51 2005 From: selinux at gmail.com (Tom London) Date: Mon, 30 May 2005 17:47:51 -0700 Subject: acroread needs one more file set to texrel... Message-ID: <4c4ba1530505301747338aabb@mail.gmail.com> Running targed/enforcing, latest rawhide. Running acroread, if you select File->Document Properties, acroread dies. Here is the avc: May 30 17:35:53 localhost kernel: audit(1117499753.135:6): avc: denied { execmod } for pid=5026 comm="acroread" name=ADMPlugin.apl dev=dm-0 ino=2321999 scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:usr_t tclass=file Points to /usr/local/Adobe/Acrobat7.0/Reader/intellinux/SPPlugins/ADMPlugin.apl Sigh... Does this seem like an appropriate fix?: --- distros.fc 2005-05-20 11:54:57.000000000 -0700 +++ /tmp/distros.fc 2005-05-30 17:46:08.000000000 -0700 @@ -156,6 +156,7 @@ /usr(/.*)?/Reader/intellinux/plug_ins/.*\.api -- system_u:object_r:shlib_t /usr(/.*)?/Reader/intellinux/plug_ins/AcroForm\.api -- system_u:object_r:texrel_shlib_t /usr(/.*)?/Reader/intellinux/plug_ins/EScript\.api -- system_u:object_r:texrel_shlib_t +/usr(/.*)?/Reader/intellinux/SPPlugins/ADMPlugin\.apl -- system_u:object_r:texrel_shlib_t ') tom -- Tom London From alex at milivojevic.org Tue May 31 02:48:52 2005 From: alex at milivojevic.org (Aleksandar Milivojevic) Date: Mon, 30 May 2005 21:48:52 -0500 Subject: disabilng selinux warnings Message-ID: <429BD094.2040903@milivojevic.org> I have some NFS mounted file systems (from Solaris box). Whenever moving files between them (mv shell command), users are getting "security context not preserved" warning. I know what the warning is about, and why it is being generated. Is it possible to disable it? It's kind of confusing for the users (they think file isn't moved, so they are calling administrators about non-existing problem), and in my case really pointless. The source and destination are both mounted form Solaris boxes, so there's really not anything that could have been preserved. Not to mention how annoying it is to have hundreds or thousands of them printed when moving a lot of files in one batch (and basically, my users are rightfully asking for those warning to be disabled). From sds at tycho.nsa.gov Tue May 31 14:03:19 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 31 May 2005 10:03:19 -0400 Subject: policy SSH In-Reply-To: <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> References: <1117115021.2644.86.camel@moss-spartans.epoch.ncsc.mil> <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> Message-ID: <1117548199.28924.95.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-27 at 11:55 -0400, Ma. Alejandra Castillo M. wrote: > Dear, i need to know the current policy for ssh, is there such a policy? In the strict policy, yes. In the targeted policy, I think it is unconfined. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 31 14:11:45 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 31 May 2005 10:11:45 -0400 Subject: HELP: transition denied regardless of policy? In-Reply-To: <42977789.7060107@altkom.pl> References: <429528E8.2070301@altkom.pl> <1117110154.2644.23.camel@moss-spartans.epoch.ncsc.mil> <42977789.7060107@altkom.pl> Message-ID: <1117548705.28924.109.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-05-27 at 21:39 +0200, Aleksander Adamowski wrote: > Soon, checkpolicy for FC3 will have support for typeattribute construct: > > https://www.redhat.com/archives/fedora-cvs-commits/2005-May/msg00593.html I doubt it. FC3 only gets bug fixes, not enhancements. You'll have to pull from FC4/development if you want those changes. Also, in general, if using strict policy, you are advised to track the development tree, as Red Hat hasn't been issuing updates to strict policy in FC3 at all. -- Stephen Smalley National Security Agency From tscherf at redhat.com Tue May 31 14:24:50 2005 From: tscherf at redhat.com (Thorsten Scherf) Date: Tue, 31 May 2005 16:24:50 +0200 Subject: policy SSH In-Reply-To: <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> References: <1117115021.2644.86.camel@moss-spartans.epoch.ncsc.mil> <009d01c562d4$819ebd60$800410ac@rocl.csavgroup.com> Message-ID: <1117549490.5678.13.camel@tiffy.rhel.homelinux.com> Ma. Alejandra Castillo M. wrote: > Dear, i need to know the current policy for ssh, is there such a policy? depends on the selinux-policy you are using. in the (default) targeted policy, sshd runs in the unconfined domain: [root at tiffy rhds]# ps -AZ|grep sshd user_u:system_r:unconfined_t 4249 ? 00:00:00 sshd [root at tiffy rhds]# but of course you can use another selinux-policy which has its own domain for sshd, or write your own. happy day. thorsten -- Thorsten Scherf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kps0557 at i-heart.co.kr Tue May 31 16:00:24 2005 From: kps0557 at i-heart.co.kr (kps0557 at i-heart.co.kr) Date: Wed, 1 Jun 2005 01:00:24 +0900 (KST) Subject: fedora-selinux-list Digest, Vol 15, Issue 31 Message-ID: <20050531160024.2C9C611183@spam.i-heart.co.kr> An HTML attachment was scrubbed... URL: From Valdis.Kletnieks at vt.edu Tue May 31 17:17:09 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 31 May 2005 13:17:09 -0400 Subject: fedora-selinux-list Digest, Vol 15, Issue 31 In-Reply-To: Your message of "Wed, 01 Jun 2005 01:00:24 +0900." <20050531160024.2C9C611183@spam.i-heart.co.kr> References: <20050531160024.2C9C611183@spam.i-heart.co.kr> Message-ID: <200505311717.j4VHH9G4009195@turing-police.cc.vt.edu> On Wed, 01 Jun 2005 01:00:24 +0900, kps0557 at i-heart.co.kr said: > Please complete the verification so that I can receive your email. a) 25K of ugly HTML for this message is overkill. b) Please read the following pages on why Challenge/Response is evil: http://www.politechbot.com/p-04746.html http://tardigrade.net/challengeresponse.html c) If you're going to persist in this sort of misguided behavior, at least Google for 'whitelist', and then do it for mailing lists you subscribe to. (And no, I have no intention of responding to any challenges that this mail generates - at least one of the listed addresses *should not* generate a challenge). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From james.zheng.li at gmail.com Tue May 31 18:50:53 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Tue, 31 May 2005 14:50:53 -0400 Subject: how does rpm work under Selinux Message-ID: <8a239a56050531115036c044dc@mail.gmail.com> Hi all, I was wondering how rpm works with Selinux, say I downloaded a third-party rpm package and installed it with rpm -i. Will rpm label the newly installed file properly or I have to relabel filesystem or do 'restorecon' manually ? Any webpages I could read on this problem? Thanks a lot. James From sds at tycho.nsa.gov Tue May 31 19:11:30 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 31 May 2005 15:11:30 -0400 Subject: how does rpm work under Selinux In-Reply-To: <8a239a56050531115036c044dc@mail.gmail.com> References: <8a239a56050531115036c044dc@mail.gmail.com> Message-ID: <1117566690.28924.263.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-05-31 at 14:50 -0400, James Z. Li wrote: > Hi all, > > I was wondering how rpm works with Selinux, say I downloaded > a third-party rpm package and installed it with rpm -i. Will rpm > label the newly installed file properly or I have to relabel filesystem > or do 'restorecon' manually ? > > Any webpages I could read on this problem? Thanks a lot. rpm has been modified to set the security context on newly installed files in accordance with the policy (based on the file_contexts configuration). It originally incorporated a copy of the setfiles logic for this purpose, and has recently been changed in FC4/devel to use matchpathcon(3) instead, IIUC. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue May 31 19:21:55 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 31 May 2005 15:21:55 -0400 Subject: how does rpm work under Selinux In-Reply-To: <8a239a56050531115036c044dc@mail.gmail.com> References: <8a239a56050531115036c044dc@mail.gmail.com> Message-ID: <429CB953.3070205@redhat.com> James Z. Li wrote: >Hi all, > >I was wondering how rpm works with Selinux, say I downloaded >a third-party rpm package and installed it with rpm -i. Will rpm >label the newly installed file properly or I have to relabel filesystem >or do 'restorecon' manually ? > >Any webpages I could read on this problem? Thanks a lot. > >James > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > It will label the file according the the file_context file installed on the machine. This may or may not be "correctly". Usually this is only a problem if the app is installed in a non standard directory. Dan -- From gyurdiev at redhat.com Tue May 31 19:03:30 2005 From: gyurdiev at redhat.com (Ivan Gyurdiev) Date: Tue, 31 May 2005 15:03:30 -0400 Subject: how does rpm work under Selinux In-Reply-To: <8a239a56050531115036c044dc@mail.gmail.com> References: <8a239a56050531115036c044dc@mail.gmail.com> Message-ID: <1117566210.2962.11.camel@dhcp83-8.boston.redhat.com> On Tue, 2005-05-31 at 14:50 -0400, James Z. Li wrote: > Hi all, > > I was wondering how rpm works with Selinux, say I downloaded > a third-party rpm package and installed it with rpm -i. Will rpm > label the newly installed file properly or I have to relabel filesystem > or do 'restorecon' manually ? rpm will label the files according to their context as specified in the policy. Additionally, if a third party program is installed using the "install" command, that will also restorecon files automatically. However, if you're installing third party programs, and they have no policy written for them, they might not work properly if they require elevated privileges. From mike at navi.cx Tue May 31 23:53:46 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 01 Jun 2005 00:53:46 +0100 Subject: how does rpm work under Selinux References: <8a239a56050531115036c044dc@mail.gmail.com> <1117566690.28924.263.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Tue, 31 May 2005 15:11:30 -0400, Stephen Smalley wrote: > rpm has been modified to set the security context on newly installed > files in accordance with the policy (based on the file_contexts > configuration). I thought RPMs could contain their own file contexts for each contained file, rather than relying on external regular expressions. Is this not the case? Was it ever the case? :)