From rhallyx at mindspring.com Sun Oct 2 05:46:28 2005 From: rhallyx at mindspring.com (Richard Hally) Date: Sun, 02 Oct 2005 01:46:28 -0400 Subject: strict policy problem Message-ID: <433F7434.9000208@mindspring.com> would someone please fix the problem with firefox and thunderbird not starting when using the latest strict policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages from audit.log when trying to start them Thanks, Richard Hally type=AVC msg=audit(1128231114.093:32): avc: denied { execmod } for pid=2731 comm="firefox-bin" name="libxpcom_core.so" dev=dm-0 ino=3965047 scontext=richard:staff_r:staff_mozilla_t:s0-s0:c0.c127 tcontext=system_u:object_r:shlib_t:s0 tclass=file type=SYSCALL msg=audit(1128231114.093:32): arch=40000003 syscall=125 success=no exit=-13 a0=e9c000 a1=e0000 a2=5 a3=bfd2a710 items=0 pid=2731 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="firefox-bin" exe="/usr/lib/firefox-1.5/firefox-bin" type=AVC_PATH msg=audit(1128231114.093:32): path="/usr/lib/firefox-1.5/libxpcom_core.so" ----------------------------------------------------------- type=AVC msg=audit(1128231322.472:40): avc: denied { execmod } for pid=2869 comm="thunderbird-bin" name="libxpcom_core.so" dev=dm-0 ino=3701297 scontext=richard:staff_r:staff_thunderbird_t:s0-s0:c0.c127 tcontext=system_u:object_r:shlib_t:s0 tclass=file type=SYSCALL msg=audit(1128231322.472:40): arch=40000003 syscall=125 success=no exit=-13 a0=739000 a1=e0000 a2=5 a3=bfe1ebc0 items=0 pid=2869 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="thunderbird-bin" exe="/usr/lib/thunderbird-1.5/thunderbird-bin" type=AVC_PATH msg=audit(1128231322.472:40): path="/usr/lib/thunderbird-1.5/libxpcom_core.so" From ivg2 at cornell.edu Sun Oct 2 07:19:44 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 02 Oct 2005 03:19:44 -0400 Subject: strict policy problem In-Reply-To: <433F7434.9000208@mindspring.com> References: <433F7434.9000208@mindspring.com> Message-ID: <433F8A10.9020400@cornell.edu> Richard Hally wrote: > would someone please fix the problem with firefox and thunderbird not > starting when using the latest strict > policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages > from audit.log when trying to start them > Hi Richard, the problem is easily worked around by marking the following libraries texrel_shlib_t, as they contain Text Relocations. However, I think a better goal would be to eliminate those text relocations where possible, along with the rest of the libraries marked in distros.fc. Steven, can you clarify what needs to be done to get fix those applications... I am currently not very clear on what the problem is, since I'm not familiar with the linking process. /usr/lib/firefox-1.5/libgfxpsshar.so /usr/lib/firefox-1.5/libgkgfx.so /usr/lib/firefox-1.5/libxpcom_compat.so /usr/lib/firefox-1.5/libgtkembedmoz.so /usr/lib/firefox-1.5/libxpcom_core.so /usr/lib/firefox-1.5/libgtkxtbin.so /usr/lib/firefox-1.5/libxpcom.so /usr/lib/firefox-1.5/libjsj.so /usr/lib/firefox-1.5/libsoftokn3.so /usr/lib/firefox-1.5/libxpistub.so From iocc at fedora-selinux.lists.flashdance.cx Sun Oct 2 15:07:22 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Sun, 2 Oct 2005 17:07:22 +0200 (CEST) Subject: cant create dirs from vsftpd In-Reply-To: <431EE914.50708@redhat.com> References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> <200508291025.21447.lamont@gurulabs.com> <431EE914.50708@redhat.com> Message-ID: On Wed, 7 Sep 2005, Daniel J Walsh wrote: >> Correct! >> My non-anonymous vsftpd server under FC3 works exactly like that. But >> selinux in FC4 have problems with that. The polcy is broken. > Then you can turn off selinux protection on the ftpd server. How? From russell at coker.com.au Mon Oct 3 09:27:53 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 3 Oct 2005 19:27:53 +1000 Subject: FC3 strict policy Message-ID: <200510031928.01476.russell@coker.com.au> I had a user ask me off-list about strict policy for FC3. It hadn't been updated for name_connect and the policy in FC4 doesn't work. Attached is a first pass at updating the FC3 strict policy to work with the latest kernels. I encourage anyone who is running FC3 strict machines to use selinux-policy-strict-sources-1.19.10-2 plus this patch instead of trying to use FC4 policy. NB It will take a little more work to get anything other than a basic server going with this policy, but it should be less work than the other options and the results should be better. -- 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: diff.gz Type: application/x-gzip Size: 6191 bytes Desc: not available URL: From sds at tycho.nsa.gov Mon Oct 3 13:15:04 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 03 Oct 2005 09:15:04 -0400 Subject: strict policy problem In-Reply-To: <433F7434.9000208@mindspring.com> References: <433F7434.9000208@mindspring.com> Message-ID: <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote: > would someone please fix the problem with firefox and thunderbird not > starting when using the latest strict > policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages > from audit.log when trying to start them You should always bugzilla such issues so that they can be tracked properly... -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Oct 3 13:57:10 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 03 Oct 2005 09:57:10 -0400 Subject: strict policy problem In-Reply-To: <433F8A10.9020400@cornell.edu> References: <433F7434.9000208@mindspring.com> <433F8A10.9020400@cornell.edu> Message-ID: <1128347830.26285.44.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-10-02 at 03:19 -0400, Ivan Gyurdiev wrote: > Hi Richard, the problem is easily worked around by marking the following > libraries texrel_shlib_t, as they contain Text Relocations. However, I > think a better goal would be to eliminate those text relocations where > possible, along with the rest of the libraries marked in distros.fc. > > Steven, can you clarify what needs to be done to get fix those > applications... > I am currently not very clear on what the problem is, since I'm not > familiar with the linking process. > > /usr/lib/firefox-1.5/libgfxpsshar.so > /usr/lib/firefox-1.5/libgkgfx.so > /usr/lib/firefox-1.5/libxpcom_compat.so > /usr/lib/firefox-1.5/libgtkembedmoz.so > /usr/lib/firefox-1.5/libxpcom_core.so > /usr/lib/firefox-1.5/libgtkxtbin.so > /usr/lib/firefox-1.5/libxpcom.so > /usr/lib/firefox-1.5/libjsj.so > /usr/lib/firefox-1.5/libsoftokn3.so > /usr/lib/firefox-1.5/libxpistub.so I think that one would have to go look at the actual code and build process for those objects to determine why they are being marked as requiring textrel and what needs to be done to fix them. Were they built with -fpic? Do they include hand-written assembly? Ulrich, is there a FAQ anywhere already to which we can refer people to help them track down the cause of text relocations and fix them (not just working around them in policy)? -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Oct 3 18:38:57 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 03 Oct 2005 14:38:57 -0400 Subject: cant create dirs from vsftpd In-Reply-To: References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> <200508291025.21447.lamont@gurulabs.com> <431EE914.50708@redhat.com> Message-ID: <43417AC1.1080309@redhat.com> Peter Magnusson wrote: > On Wed, 7 Sep 2005, Daniel J Walsh wrote: > >>> Correct! >>> My non-anonymous vsftpd server under FC3 works exactly like that. >>> But selinux in FC4 have problems with that. The polcy is broken. >> Then you can turn off selinux protection on the ftpd server. > > How? setsebool -P ftpd_disable_trans=1 -- From aoliva at redhat.com Mon Oct 3 19:09:58 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 03 Oct 2005 16:09:58 -0300 Subject: devel's mcs breaks prelink and FC4 compat Message-ID: I've been running FC devel forever. Ever since mcs was introduced, prelink has started displaying odd behavior: it would fail to set the context for some of the linked binaries and crash at the end. Some time ago, I put some time aside to investigate the issue. As it turned out, prelink would getxattr("selinux.context") for the old binary, and setxattr the new binary with the same context. For some reason, for binaries whose context did not end in :s0, the setxattr was denied. Running restorecon -F or chcon would reset the context of the binary correctly, enabling prelink to run; a simple fixfiles relabel would not; perhaps fixfiles -F relabel would, but I didn't try that. Oddly, even after I cleaned up all binaries to enable a full prelink run to complete successfully, after additional updates installed by yum, new libraries and binaries were introduced that fail to prelink, and I have to reset their contexts to get :s0 added in order for it to succeed. Since I'm told the mcs thingie was designed to not require relabeling and to be totally transparent, I thought I'd report this. I'm just not sure what package to file it against in bugzilla. Thoughts? For reference, here's the command I used to get all contexts reset. It can run for hours, so beware. rm -f /tmp/prelink.restorecon.log; while /usr/sbin/prelink -av -mR -q 2>&1 | tee /tmp/prelink.log; sed -n 's,/usr/sbin/prelink: Could not set security context for \(.*\): Invalid argument,\1,p' /tmp/prelink.log | xargs restorecon -v -F | tee -a /tmp/prelink.restorecon.log | grep .; do cmp /tmp/prelink.log /tmp/prelink.log.prev && break; mv -f /tmp/prelink.log /tmp/prelink.log.prev; done -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sds at tycho.nsa.gov Mon Oct 3 20:18:26 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 03 Oct 2005 16:18:26 -0400 Subject: devel's mcs breaks prelink and FC4 compat In-Reply-To: References: Message-ID: <1128370706.26285.277.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-10-03 at 16:09 -0300, Alexandre Oliva wrote: > I've been running FC devel forever. Ever since mcs was introduced, > prelink has started displaying odd behavior: it would fail to set the > context for some of the linked binaries and crash at the end. Some > time ago, I put some time aside to investigate the issue. > > As it turned out, prelink would getxattr("selinux.context") for the > old binary, and setxattr the new binary with the same context. For > some reason, for binaries whose context did not end in :s0, the > setxattr was denied. > > Running restorecon -F or chcon would reset the context of the binary > correctly, enabling prelink to run; a simple fixfiles relabel would > not; perhaps fixfiles -F relabel would, but I didn't try that. > > Oddly, even after I cleaned up all binaries to enable a full prelink > run to complete successfully, after additional updates installed by > yum, new libraries and binaries were introduced that fail to prelink, > and I have to reset their contexts to get :s0 added in order for it to > succeed. > > Since I'm told the mcs thingie was designed to not require relabeling > and to be totally transparent, I thought I'd report this. I'm just > not sure what package to file it against in bugzilla. > > Thoughts? - Normally, this is hidden from userspace by libsetrans, which adds the :s0 suffix when it is missing. But prelink uses the static libselinux and thus doesn't pick up the dlopen of libsetrans and the transparent context translation support. - fixfiles relabel runs setfiles, and setfiles does use the shared libselinux, so it ends up seeing the contexts as already having the :s0 and doesn't bother relabeling them. It appears that the force flag to setfiles doesn't change this behavior, which is a bug in setfiles. restorecon does honor the force flag in that respect. - I don't understand how subsequent updates could end up creating new files that lack :s0 after you've switched over to using MCS; the kernel should prohibit setxattr or /proc/pid/attr/fscreate values that lack the suffix, and should default it into new files. - There is a patch pending against 2.6.15 that will enable SELinux to canonicalize getxattr results, so that it will return the :s0 always under MCS, even if the file hasn't been relabeled on disk. -- Stephen Smalley National Security Agency From lamont at gurulabs.com Mon Oct 3 20:39:58 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 3 Oct 2005 14:39:58 -0600 Subject: cant create dirs from vsftpd In-Reply-To: References: <200508291025.21447.lamont@gurulabs.com> Message-ID: <200510031440.31307.lamont@gurulabs.com> On Sunday 04 September 2005 07:26pm, Peter Magnusson wrote: > On Mon, 29 Aug 2005, Lamont R. Peterson wrote: [SNIP] > > Perhaps, I'm just a little bit confused. Are you wanting your FTP server > > to provide access to the entire filesystem space? It seems like that is > > what you are asking for and that is not how FTP works. > > Correct! > My non-anonymous vsftpd server under FC3 works exactly like that. But > selinux in FC4 have problems with that. The polcy is broken. > > > FTP like HTTP serves up files only from a subset of the filesystem space. > > You wouldn't want your web server providing access to the entire > > filesystem, would you? The same is true of FTP. > > > > Please, if I am misunderstanding what you are trying to accomplish here, > > feel free to explain it. > > Yes, you are. Im NOT talking about an anonymous ftp server. I login with my > user and I expect to have the same files available as when I login over > ssh or sits in front of the computer. Daniel has already replied and told you how to make the change you want. I will just say that the setup you describe here is VERY VERY insecure. Remember, FTP is not encrypted, so your username and password are going over the wire in clear text. Also, since the FTP daemon has access to the whole filesystem, anyone can get anything on your box (possibly even write any files they want, though that would depend on more configuration details than what you have told me about). FTP is the wrong tool for this. You should use sftp (from SSH not SSL) or scp. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rhally at mindspring.com Tue Oct 4 03:16:56 2005 From: rhally at mindspring.com (Richard Hally) Date: Mon, 03 Oct 2005 23:16:56 -0400 Subject: strict policy problem In-Reply-To: <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> References: <433F7434.9000208@mindspring.com> <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4341F428.5020605@mindspring.com> Stephen Smalley wrote: > On Sun, 2005-10-02 at 01:46 -0400, Richard Hally wrote: > >>would someone please fix the problem with firefox and thunderbird not >>starting when using the latest strict >>policy(selinux-policy-strict-1.27.1-11)? Below are the AVC messages >>from audit.log when trying to start them > > > You should always bugzilla such issues so that they can be tracked > properly... > Perhaps someone who understands the problem and possibly the solution and which package to file against could help us out here? BTW, the other part of the problem is possibly related to the "devel's mcs breaks prelink and FC4 compat" thread. When I do 'touch /.autorelabel' and reboot, Firefox and Thunderbird will start. If I then do another reboot without the autorelabel they will then not start. Just speculating here but it seems that something is being kept in memory from relabeling that allows these apps to start but is not there when doing an ordinary boot. But that is just speculation. Is it FF and T'bird or is it SELinux? Also, this problem has been occurring with Firefox for several months but has only started occurring with T'bird in the last week or so. These are the only two apps I have tried on my strict/MCS test box. Richard Hally From sds at tycho.nsa.gov Tue Oct 4 12:08:51 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 04 Oct 2005 08:08:51 -0400 Subject: strict policy problem In-Reply-To: <4341F428.5020605@mindspring.com> References: <433F7434.9000208@mindspring.com> <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> <4341F428.5020605@mindspring.com> Message-ID: <1128427731.26285.328.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-10-03 at 23:16 -0400, Richard Hally wrote: > Perhaps someone who understands the problem and possibly the solution > and which package to file against could help us out here? I'd file it against firefox, as that owns the .so files that are triggering these denials. Someone needs to look at the build process and code for those .so files to determine why they presently require text relocations and how to fix them. > Just speculating here but it seems that something is being kept in > memory from relabeling that allows these apps to start but is not there > when doing an ordinary boot. But that is just speculation. Is it FF and > T'bird or is it SELinux? Hmm...well, SELinux should trigger an execmod denial on shlib_t always, regardless of the MCS level. Labeling them with texrel_shlib_t should make it go away, but it would be better to fix the files to not require text relocations. It is possible for the incore inode security label to become inconsistent with the on-disk xattr (example: access a file with a given type to bring its inode incore and map its xattr to an incore label, then remove the type from the policy and reload it, at which point the incore label will be remapped to the unlabeled_t type, and remain that way until the inode is evicted from memory even if a subsequent policy reload re-adds the type). The patch queued up for 2.6.15 that will allow SELinux to canonicalize getxattr results will ensure that a getxattr/getfilecon will always return the actual incore inode security label to userspace. -- Stephen Smalley National Security Agency From rhally at mindspring.com Tue Oct 4 21:04:51 2005 From: rhally at mindspring.com (Richard Hally) Date: Tue, 04 Oct 2005 17:04:51 -0400 Subject: strict policy problem In-Reply-To: <1128427731.26285.328.camel@moss-spartans.epoch.ncsc.mil> References: <433F7434.9000208@mindspring.com> <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> <4341F428.5020605@mindspring.com> <1128427731.26285.328.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4342EE73.6000207@mindspring.com> Stephen Smalley wrote: > On Mon, 2005-10-03 at 23:16 -0400, Richard Hally wrote: > >>Perhaps someone who understands the problem and possibly the solution >>and which package to file against could help us out here? > > > I'd file it against firefox, as that owns the .so files that are > triggering these denials. Someone needs to look at the build process > and code for those .so files to determine why they presently require > text relocations and how to fix them. > Perhaps it would be appropriate to reevaluate the implementation strategy for this particular "feature" of SELinux. If there is no coherent, concise, convincing explanation provided to the people who need to make changes to their software to conform to the requirements of this "feature" then there isn't much hope of them doing what is required. Since this "feature" was implemented many months ago and these problems are still appearing please consider filing bugs with the appropriate explanation so that the appropriate people can make the required changes. Thanks, Richard Hally From aoliva at redhat.com Tue Oct 4 21:38:58 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: Tue, 04 Oct 2005 18:38:58 -0300 Subject: devel's mcs breaks prelink and FC4 compat In-Reply-To: <1128370706.26285.277.camel@moss-spartans.epoch.ncsc.mil> (Stephen Smalley's message of "Mon, 03 Oct 2005 16:18:26 -0400") References: <1128370706.26285.277.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Oct 3, 2005, Stephen Smalley wrote: > - There is a patch pending against 2.6.15 that will enable SELinux to > canonicalize getxattr results, so that it will return the :s0 always > under MCS, even if the file hasn't been relabeled on disk. Any chance it could also strip it out when writing to disk? This would improve on-disk compatibility with non-mcs, a point that I'd planned to address in my previous e-mail, but forgot. Currently, any directories or files created while running FC devel become inaccessible when I boot into FC4 on the same box, which is a little bit annoying. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From sds at tycho.nsa.gov Wed Oct 5 19:56:53 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Oct 2005 15:56:53 -0400 Subject: strict policy problem In-Reply-To: <4342EE73.6000207@mindspring.com> References: <433F7434.9000208@mindspring.com> <1128345304.26285.23.camel@moss-spartans.epoch.ncsc.mil> <4341F428.5020605@mindspring.com> <1128427731.26285.328.camel@moss-spartans.epoch.ncsc.mil> <4342EE73.6000207@mindspring.com> Message-ID: <1128542213.24059.232.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-04 at 17:04 -0400, Richard Hally wrote: > Perhaps it would be appropriate to reevaluate the implementation > strategy for this particular "feature" of SELinux. > > If there is no coherent, concise, convincing explanation provided to the > people who need to make changes to their software to conform to the > requirements of this "feature" then there isn't much hope of them doing > what is required. Since this "feature" was implemented many months ago > and these problems are still appearing please consider filing bugs with > the appropriate explanation so that the appropriate people can make the > required changes. Hi, I think all you need to do is file a bugzilla against firefox and report what you reported originally, and note that these .so's have text relocations. Then it is up to the maintainer for that package (and ultimately the upstream developers) to address the issue. The notion that text relocations are bad isn't something novel to SELinux by any means. We simply added controls to SELinux over the resulting attempt to modify the memory protections at the suggestion of the Red Hat developers so that this can be controlled by policy. You can also bugzilla policy if you like so that the permissions can be added in the short term until the package is fixed. This is no different than any other bug you might encounter in a particular package; when you find the bug, file it against the package. The policy can certainly workaround it in the short term, but that doesn't improve security; it just permits the status quo. -- Stephen Smalley National Security Agency From russell at coker.com.au Thu Oct 6 04:58:56 2005 From: russell at coker.com.au (Russell Coker) Date: Thu, 6 Oct 2005 14:58:56 +1000 Subject: initlog and syslogd performance with setfiles Message-ID: <200510061459.02430.russell@coker.com.au> Initlog can save up a large number of log entries (particularly if logging a SE Linux relabel). If these are processed by syslogd synchronously then the performance is very poor and the system apparently can be running for quite a while before the boot messages are logged. Another possible issue is the memory use of initlog, if using a machine with the minimum recommended RAM (256M) it is not inconceivable that initlog could run out of memory which would probably break things in a bad way (relabel happens before swapon). This was brought to my attention when a RHEL4 user spoke of the "feature" whereby the files would be relabeled in the background. Of course it turned out that the relabelling was not happening in the background it was merely the logging that was happening after the system boot. I think it would make sense to have this data written directly to a log file under /var/log (/var/log/setfiles or something). How about the following: LOGFILE=/var/log/setfiles SYSLOGFLAG="" -- 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 notting at redhat.com Thu Oct 6 16:25:50 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 6 Oct 2005 12:25:50 -0400 Subject: initlog and syslogd performance with setfiles In-Reply-To: <200510061459.02430.russell@coker.com.au> References: <200510061459.02430.russell@coker.com.au> Message-ID: <20051006162550.GA5565@apone.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > Initlog can save up a large number of log entries (particularly if logging a > SE Linux relabel). initlog isn't used in FC4 and later. Is it really worth the change then? Bill From byronkeys at inxpress.net Fri Oct 7 11:30:36 2005 From: byronkeys at inxpress.net (Brian) Date: Fri, 07 Oct 2005 06:30:36 -0500 Subject: Audacity in FC, anyone? Message-ID: <43465C5C.40800@inxpress.net> Does anyone know of a "short-list" means to get the Audacity application to compile under Fedora Core 3 or 4? Some of us in a group here have been trying, but the results either fail outright, or have rather strange issues with the MP3 format. We know that the "libmad" modules are done separately, and that the "wxWidgets" modules are also required as separately obtained modules for the link-stage. What we don't know is why the simple compilation of an app from a "trusted source" (sourceforge.net) should be so problematic. Is there a makefile which is relatively routine for this app? The documention does not seem to mention any such thing, and also does not clearly list any environment settings which are mandatory. Audacity is bundled with the /Mandrake/ distro, but as many of us know, that one is notoriously hard to "get under the hood" for maintenance. As far as we know, only the app itself is bundled with Mandrake, not any development materials. Any constructive suggestions are welcome. Brian Hagen From andy at warmcat.com Fri Oct 7 12:13:47 2005 From: andy at warmcat.com (Andy Green) Date: Fri, 07 Oct 2005 13:13:47 +0100 Subject: Audacity in FC, anyone? In-Reply-To: <43465C5C.40800@inxpress.net> References: <43465C5C.40800@inxpress.net> Message-ID: <4346667B.3010607@warmcat.com> Brian wrote: You're on the wrong list, you want fedora-list > Does anyone know of a "short-list" means to get the Audacity application > to compile under Fedora Core 3 or 4? Enable the Livna repo in yum, then yum install audacity Example /etc/yum.repos.d/livna.repo: [livna] name=Livna for Fedora Core $releasever - $basearch - Base baseurl=http://rpm.livna.org/fedora/$releasever/$basearch/RPMS.lvn enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-livna > Brian Hagen Hope you don't run into anyone called Siegfried ;-) -Andy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4492 bytes Desc: S/MIME Cryptographic Signature URL: From russell at coker.com.au Sat Oct 8 07:28:58 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 8 Oct 2005 17:28:58 +1000 Subject: FC3 strict policy In-Reply-To: <200510031928.01476.russell@coker.com.au> References: <200510031928.01476.russell@coker.com.au> Message-ID: <200510081729.06098.russell@coker.com.au> On Monday 03 October 2005 19:27, Russell Coker wrote: > Attached is a first pass at updating the FC3 strict policy to work with the > latest kernels. I encourage anyone who is running FC3 strict machines to I've attached an update to this with a few other things fixed. There's still more work to be done, but someone who is prepared to modify their own policy (which means everyone who uses strict policy in FC3) should find it easy to get things going after applying the attached patch. Dan, are you planning to provide updated strict policy packages for FC3? -- 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: diff.gz Type: application/x-gzip Size: 6789 bytes Desc: not available URL: From russell at coker.com.au Sat Oct 8 09:07:16 2005 From: russell at coker.com.au (Russell Coker) Date: Sat, 8 Oct 2005 19:07:16 +1000 Subject: FC4 last updates kill postfix+postgrey In-Reply-To: <433946FA.70301@warmcat.com> References: <433946FA.70301@warmcat.com> Message-ID: <200510081907.21739.russell@coker.com.au> On Tuesday 27 September 2005 23:19, Andy Green wrote: > Using FC4 postfix with 'postgrey', a greylisting service that > communicates via a unix socket: Best to install selinux-policy-strict-sources and copy postgrey.te and postgrey.fc from there. Running postgrey in it's own domain is much better than any other option. -- 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 silvano at global.it Sat Oct 8 12:45:06 2005 From: silvano at global.it (Silvano Malaguti) Date: Sat, 08 Oct 2005 14:45:06 +0200 Subject: FC3 selinux pam_auth Message-ID: <200510081338.j98DcxiY030918@mx3.redhat.com> I have installed three servers with Fedora C3. One of this three have selinux installed and just in this machine I have some trouble to authenticate squid users with pam_auth. /var/log/messages reports error form avc about the execution of pam_auth. Is real to think next to problems of interaction between selinux and pam_auth? Thanks in advance. Best regards. _________________________________________________ Silvano Malaguti System Administrator silvano at global.it - supporto.tecnico at global.it - www.global.it Global eXperience since 1995 _________________________________________________ Punto Net S.r.l Socio Unico Professione Internet dal 1995 Via Orsatti, 8 - 44038 - Pontelagoscuro - Ferrara - Italy (UE) Centro Servizi Ferrara: Tel: 0532.490.150 Fax: 0532.490.101 From silvano at global.it Sat Oct 8 12:38:17 2005 From: silvano at global.it (Silvano Malaguti) Date: Sat, 08 Oct 2005 14:38:17 +0200 Subject: selinux squid pam_auth Message-ID: <200510081350.j98DoUrX011150@mx1.redhat.com> I have installed three server with Fedora C3. One of this three have selinux installed and just in this machine I have some trouble to authenticate squid users with pam_auth. /var/log/messages reports error form avc about the execution of pam_auth. Is real to think next to problems of interaction between selinux and pam_auth? Thanks in advance. Best regards. _________________________________________________ Silvano Malaguti System Administrator silvano at global.it - supporto.tecnico at global.it - www.global.it Global eXperience since 1995 _________________________________________________ Punto Net S.r.l Socio Unico Professione Internet dal 1995 Via Orsatti, 8 - 44038 - Pontelagoscuro - Ferrara - Italy (UE) Centro Servizi Ferrara: Tel: 0532.490.150 Fax: 0532.490.101 From iocc at fedora-selinux.lists.flashdance.cx Sun Oct 9 21:01:03 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Sun, 9 Oct 2005 23:01:03 +0200 (CEST) Subject: cant create dirs from vsftpd In-Reply-To: <200510031440.31307.lamont@gurulabs.com> References: <200508291025.21447.lamont@gurulabs.com> <200510031440.31307.lamont@gurulabs.com> Message-ID: On Mon, 3 Oct 2005, Lamont R. Peterson wrote: >> Yes, you are. Im NOT talking about an anonymous ftp server. I login with my >> user and I expect to have the same files available as when I login over >> ssh or sits in front of the computer. > > Daniel has already replied and told you how to make the change you want. I > will just say that the setup you describe here is VERY VERY insecure. Yes. Just like it worked in FC3. > Remember, FTP is not encrypted, so your username and password are going over > the wire in clear text. Also, since the FTP daemon has access to the whole > filesystem, anyone can get anything on your box (possibly even write any > files they want, though that would depend on more configuration details than > what you have told me about). I know, if I am at some untrusted location I ftp to a temp-ftp account that I change the password for each time. Or use scp. > FTP is the wrong tool for this. You should use sftp (from SSH not SSL) or > scp. Problems with scp: cant tab dirs, cant use -R like in ncftp to upload whole dirs. scp -r works but thats not always how I want it. From fedora at grifent.com Mon Oct 10 19:20:48 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 10 Oct 2005 15:20:48 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 9 In-Reply-To: <20051010160010.B4F53734C3@hormel.redhat.com> References: <20051010160010.B4F53734C3@hormel.redhat.com> Message-ID: <434ABF10.803@grifent.com> fedora-selinux-list-request at redhat.com wrote: > > ------------------------------------------------------------------------ > > Subject: > Re: cant create dirs from vsftpd > From: > Peter Magnusson > Date: > Sun, 9 Oct 2005 23:01:03 +0200 (CEST) > To: > "Lamont R. Peterson" > > To: > "Lamont R. Peterson" > CC: > Fedora SELinux > > > On Mon, 3 Oct 2005, Lamont R. Peterson wrote: > >>> Yes, you are. Im NOT talking about an anonymous ftp server. I login >>> with my >>> user and I expect to have the same files available as when I login over >>> ssh or sits in front of the computer. >> >> >> Daniel has already replied and told you how to make the change you >> want. I >> will just say that the setup you describe here is VERY VERY insecure. > > > Yes. Just like it worked in FC3. > >> Remember, FTP is not encrypted, so your username and password are >> going over >> the wire in clear text. Also, since the FTP daemon has access to the >> whole >> filesystem, anyone can get anything on your box (possibly even write any >> files they want, though that would depend on more configuration >> details than >> what you have told me about). > > > I know, if I am at some untrusted location I ftp to a temp-ftp account > that I change the password for each time. Or use scp. > >> FTP is the wrong tool for this. You should use sftp (from SSH not >> SSL) or >> scp. > > > Problems with scp: cant tab dirs, cant use -R like in ncftp to upload > whole dirs. > > scp -r works but thats not always how I want it. Use sftp. John Griffiths From cochranb at speakeasy.net Mon Oct 10 23:49:44 2005 From: cochranb at speakeasy.net (Robert L Cochran) Date: Mon, 10 Oct 2005 19:49:44 -0400 Subject: SELinux Control of Network Cards? Message-ID: <434AFE18.5060902@speakeasy.net> If I have two network adapters e.g. eth0 and eth1 installed in a Fedora Core 4 system under SELinux control, does SELinux control the operation of these devices in any way? For example, suppose I have my own iptables firewall script. The script performs routing functions as well. Does SELinux impact this? Thanks Bob Cochran From jmorris at namei.org Tue Oct 11 00:58:16 2005 From: jmorris at namei.org (James Morris) Date: Mon, 10 Oct 2005 20:58:16 -0400 (EDT) Subject: SELinux Control of Network Cards? In-Reply-To: <434AFE18.5060902@speakeasy.net> References: <434AFE18.5060902@speakeasy.net> Message-ID: On Mon, 10 Oct 2005, Robert L Cochran wrote: > If I have two network adapters e.g. eth0 and eth1 installed in a Fedora Core 4 > system under SELinux control, does SELinux control the operation of these > devices in any way? For example, suppose I have my own iptables firewall > script. The script performs routing functions as well. Does SELinux impact > this? There are controls relating to network interfaces, but they're not used by default and should have no impact. - James -- James Morris From dwalsh at redhat.com Tue Oct 11 17:43:20 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 11 Oct 2005 13:43:20 -0400 Subject: FC3 strict policy In-Reply-To: <200510081729.06098.russell@coker.com.au> References: <200510031928.01476.russell@coker.com.au> <200510081729.06098.russell@coker.com.au> Message-ID: <434BF9B8.8080606@redhat.com> Russell Coker wrote: > On Monday 03 October 2005 19:27, Russell Coker wrote: > >> Attached is a first pass at updating the FC3 strict policy to work with the >> latest kernels. I encourage anyone who is running FC3 strict machines to >> > > I've attached an update to this with a few other things fixed. There's still > more work to be done, but someone who is prepared to modify their own policy > (which means everyone who uses strict policy in FC3) should find it easy to > get things going after applying the attached patch. > > Dan, are you planning to provide updated strict policy packages for FC3? > > No. -- From mike at plan99.net Tue Oct 11 20:05:52 2005 From: mike at plan99.net (Mike Hearn) Date: Tue, 11 Oct 2005 21:05:52 +0100 Subject: Binary policy modules Message-ID: Hi, Can we have an update on this please - last I heard it was targetted for FC5. Is this still on the cards? If so, are there any docs on how to use it? I'm waiting for this feature so I can integrate autopackage with SELinux (for instance by preventing packages loading kernel modules and other risky things whilst still letting them run as root). thanks -mike From sds at tycho.nsa.gov Wed Oct 12 16:15:42 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 12 Oct 2005 12:15:42 -0400 Subject: Binary policy modules In-Reply-To: References: Message-ID: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-11 at 21:05 +0100, Mike Hearn wrote: > Hi, > > Can we have an update on this please - last I heard it was targetted for > FC5. Is this still on the cards? If so, are there any docs on how to use > it? I'm waiting for this feature so I can integrate autopackage with > SELinux (for instance by preventing packages loading kernel modules and > other risky things whilst still letting them run as root). The module support is already in rawhide (as part of the existing SELinux packages plus the introduction of libsemanage) but getting it properly integrated and used there is still work in progress (but still expected for FC5, I believe, barring any unexpected obstacles). Documentation is woefully lacking presently, but there is a README.MODULES in selinux-doc and some information over at http://sepolicy-server.sourceforge.net/index.php?page=module-language However, by itself, the module support doesn't solve the problem of confining packages/package managers. It just allows policy modules to be built and shipped separately from the base distro policy, with proper dependency checking when they are installed. For access control over the policy itself, you further need the policy server, which is also work in progress but I don't think targeted for FC5. -- Stephen Smalley National Security Agency From mike at plan99.net Wed Oct 12 18:14:52 2005 From: mike at plan99.net (Mike Hearn) Date: Wed, 12 Oct 2005 19:14:52 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Wed, 12 Oct 2005 12:15:42 -0400, Stephen Smalley wrote: > The module support is already in rawhide (as part of the existing SELinux > packages plus the introduction of libsemanage) but getting it properly > integrated and used there is still work in progress (but still expected > for FC5, I believe, barring any unexpected obstacles). Documentation is > woefully lacking presently, but there is a README.MODULES in selinux-doc > and some information over at > http://sepolicy-server.sourceforge.net/index.php?page=module-language The module language looks nice. I especially like the optionals feature, if only ELF had that :) > However, by itself, the module support doesn't solve the problem of > confining packages/package managers. It just allows policy modules to be > built and shipped separately from the base distro policy, with proper > dependency checking when they are installed. For access control over the > policy itself, you further need the policy server, which is also work in > progress but I don't think targeted for FC5. Hmm, I don't quite understand - my intention was to ship a binary policy module installed when the package manager is first installed, which then defines a new domain almost_but_not_quite_root (with a better name of course ;). Packages/installers would then be run in this domain instead of being unconfined. Why does this need access control on the policy itself? Or do you mean, that in FC5 it won't actually be possible to install third party policy modules? thanks -mike From sds at tycho.nsa.gov Wed Oct 12 18:24:25 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 12 Oct 2005 14:24:25 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-10-12 at 19:14 +0100, Mike Hearn wrote: > Hmm, I don't quite understand - my intention was to ship a binary policy > module installed when the package manager is first installed, which then > defines a new domain almost_but_not_quite_root (with a better name of > course ;). Packages/installers would then be run in this domain instead of > being unconfined. Ok, that can be done without the policy server. > Why does this need access control on the policy itself? Or do you mean, > that in FC5 it won't actually be possible to install third party > policy modules? No, that should be possible. What I meant was the ability to confine the rules that can exist in a given policy module installed from a given package, e.g. so that a policy module shipped in the foo package can't open up read access to /etc/shadow. That requires the policy server, see http://sepolicy-server.sourceforge.net/index.php However, the good news is that the module infrastructure has been developed with this in mind, so whether or not a module install is performed directly on the module store by libsemanage or sent off to the policy server for handling is hidden behind the libsemanage interface, and the user programs like semodule use that interface. Switching over to the policy server just requires altering a config file for libsemanage. -- Stephen Smalley National Security Agency From mike at plan99.net Wed Oct 12 18:46:29 2005 From: mike at plan99.net (Mike Hearn) Date: Wed, 12 Oct 2005 19:46:29 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Wed, 12 Oct 2005 14:24:25 -0400, Stephen Smalley wrote: > No, that should be possible. What I meant was the ability to confine the > rules that can exist in a given policy module installed from a given > package, e.g. so that a policy module shipped in the foo package can't > open up read access to /etc/shadow. That requires the policy server, see > http://sepolicy-server.sourceforge.net/index.php Wow, meta-policy? That sounds useful but mind-expanding :) Anyway, good to know! I look forward to getting my hands on FC5 when it comes out. It'll be interesting to see how far we can restrict installers before we start breaking them. thanks -mike From mike at plan99.net Wed Oct 12 19:27:31 2005 From: mike at plan99.net (Mike Hearn) Date: Wed, 12 Oct 2005 20:27:31 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Oh, some other questions I should have asked: * What are the binary compatibility guarantees for binary policy modules? Is the format stable/will it be? * Are the .pp files cpu-architecture-neutral? * Are they distribution neutral? * Any other things people distributing PP files with their software should know? thanks -mike From jbrindle at tresys.com Wed Oct 12 19:37:35 2005 From: jbrindle at tresys.com (Joshua Brindle) Date: Wed, 12 Oct 2005 15:37:35 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <434D65FF.9040209@tresys.com> Mike Hearn wrote: > Oh, some other questions I should have asked: > > * What are the binary compatibility guarantees for binary policy > modules? Is the format stable/will it be? > The format is versioned the same way the kernel binary format is, so any changes to the format use a different version number, and backward compatbility is retained. > * Are the .pp files cpu-architecture-neutral? > yes. > * Are they distribution neutral? > only as neutral as policies are, which isn't all that neutral right now. Hopefully this will change when reference policy is used by everyone and optional tunables are built in to the language. > * Any other things people distributing PP files with their software should > know? > you might look at this thread: http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more information. Particularly the justification for building seperate packages for policy and the application. > thanks -mike > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From jmorris at redhat.com Wed Oct 12 19:36:54 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 12 Oct 2005 15:36:54 -0400 (EDT) Subject: [ANN] SELinux Symposium Delegate Program Message-ID: HP and Red Hat are pleased to sponsor the SELinux Symposium Community Delegate program. The Program sponsors community-based delegates to the Second Annual SELinux Symposium held February 28 to March 2, 2006 at the Wyndham Hotel in Baltimore Maryland. This program is designed to encourage and recognize outstanding community contributors of the SELinux project. The program will select and sponsor up to three community delegates to attend the Symposium, covering the costs of: * Travel to and from the Symposium * Hotel accommodations * Professional registration Nominations for delegates (including self-nominations) should be sent to selinux-delegate-program at redhat.com by November 30, 2005. HP and Red Hat will announce the names of the chosen delegates December 15, 2005. Nomination emails must include: * Up to 200 words describing the contributions of the nominee to the SELinux project and any related noteworthy Linux community achievements. Nominations are not limited to developers and open to all SELinux community members worldwide who are not employees of SELinux Symposium sponsors. See: Please forward as necessary. - James -- James Morris From ktl at bornet.net Thu Oct 13 05:42:48 2005 From: ktl at bornet.net (Tomas Larsson) Date: Thu, 13 Oct 2005 07:42:48 +0200 Subject: Security context, how to change? Message-ID: How do I change the security context automatically. I.e if I am moving one file from one folder, is it possible to automatically to Put the context for the new directory on the file. For example, if I move a file from the FTP-upload folder to HTTPD download folder. With best regards Tomas Larsson Sweden http://www.naks.mine.nu for downloads etc. ftp://ktl.mine.nu for uploads. Verus Amicus Est Tamquam Alter Idem From Valdis.Kletnieks at vt.edu Thu Oct 13 06:04:50 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 13 Oct 2005 02:04:50 -0400 Subject: Security context, how to change? In-Reply-To: Your message of "Thu, 13 Oct 2005 07:42:48 +0200." References: Message-ID: <200510130604.j9D64pxK022647@turing-police.cc.vt.edu> On Thu, 13 Oct 2005 07:42:48 +0200, Tomas Larsson said: > How do I change the security context automatically. > I.e if I am moving one file from one folder, is it possible to automatically > to > Put the context for the new directory on the file. > For example, if I move a file from the FTP-upload folder to HTTPD download > folder. It may make more sense to create a new context 'user_uploaded_t' or some such, and give the FTP server the access needed to write it, and the httpd the needed read access. That way, it gets "sandboxed" and even if it's malicious code, nothing else can accidentally read/execute it, so your system integrity is enhanced. Depending on your paranoia level, you may or may not want to allow some way for a process running in some user_t to un-sandbox the file. It may be sufficient to allow user_t to read it, as there probably shouldn't be any automated processes running as user_t - with the implicit "the user is taking responsibility for this"... -------------- 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 Thu Oct 13 09:03:51 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 13 Oct 2005 05:03:51 -0400 Subject: Security context, how to change? In-Reply-To: <200510130604.j9D64pxK022647@turing-police.cc.vt.edu> References: <200510130604.j9D64pxK022647@turing-police.cc.vt.edu> Message-ID: <434E22F7.6010201@cornell.edu> Valdis.Kletnieks at vt.edu wrote: > On Thu, 13 Oct 2005 07:42:48 +0200, Tomas Larsson said: > >> How do I change the security context automatically. >> I.e if I am moving one file from one folder, is it possible to automatically >> to >> Put the context for the new directory on the file. >> For example, if I move a file from the FTP-upload folder to HTTPD download >> folder. >> If you're talking about moving things via shell commands, then using the cp command will automatically change the context, if you have sufficient rights to do so (read the old context, write the new context, write to the folder...etc). > It may make more sense to create a new context 'user_uploaded_t' or some > such, and give the FTP server the access needed to write it, and the httpd > the needed read access. That way, it gets "sandboxed" and even if it's > malicious code, nothing else can accidentally read/execute it, so your > system integrity is enhanced. > A type to taint untrusted content already exists (in strict policy anyway, not sure about targeted) - it is called $1_untrusted_content_t. This type does not "guard" the content within, so you wouldn't use it to target information to be used by a specific program (like, if you wanted the information to be available to httpd only, but nothing else). Instead, it controls access by all content consumers, based on global boolean (read_untrusted_content). Currently, this is used mostly by desktop programs, for things like... gpg (signing content), mplayer (playing movies), lpr (print stuff), mail programs (upload stuff), mozilla client (upload stuff). Those applications currently use a macro called read_content() to access all "trusted" data in /tmp, /home (not what you want), and "untrusted" data, if you choose so. You can disable access to reading "untrusted" data globally by setting the boolean. In any event, $1_t has { relabelto relabelfrom } rights for this type. My point here is that an appropriate data type exists, IMHO. It might have macros for it, designed for a different purpose in mind, but the goal of the type is essentially the same (taint malicious data). It's also customizable, so the taint persists after restorecon. I think a lot of this desktop stuff could be further refined to be relevant to servers. If we can solve the desktop problem, then the server problem becomes easy (desktop is a lot more complicated). > Depending on your paranoia level, you may or may not want to allow some > way for a process running in some user_t to un-sandbox the file. It may be > sufficient to allow user_t to read it, as there probably shouldn't be any > automated processes running as user_t - with the implicit "the user is taking > responsibility for this"... > user_t has { relabelto relabelfrom } rights to the type I was discussing. Note that you can still revoke user_t's rights to read such content, to prevent accidental opening of dangerous files. user_t keeps { getattr and unlink }. From sds at tycho.nsa.gov Thu Oct 13 13:07:45 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 13 Oct 2005 09:07:45 -0400 Subject: Security context, how to change? In-Reply-To: References: Message-ID: <1129208865.26188.127.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-10-13 at 07:42 +0200, Tomas Larsson wrote: > How do I change the security context automatically. > I.e if I am moving one file from one folder, is it possible to automatically > to > Put the context for the new directory on the file. > For example, if I move a file from the FTP-upload folder to HTTPD download > folder. If the file was just renamed (intra-filesystem mv), then you can run restorecon on the file to reset its file context to the default for its location. If the file was copied, the new copy should inherit the directory context automatically unless a) policy defines a type transition, or b) you used the option to preserve security contexts on the copy. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Oct 13 13:16:48 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 13 Oct 2005 09:16:48 -0400 Subject: Security context, how to change? In-Reply-To: <434E22F7.6010201@cornell.edu> References: <200510130604.j9D64pxK022647@turing-police.cc.vt.edu> <434E22F7.6010201@cornell.edu> Message-ID: <434E5E40.4000500@redhat.com> Ivan Gyurdiev wrote: > Valdis.Kletnieks at vt.edu wrote: >> On Thu, 13 Oct 2005 07:42:48 +0200, Tomas Larsson said: >> >>> How do I change the security context automatically. >>> I.e if I am moving one file from one folder, is it possible to >>> automatically >>> to >>> Put the context for the new directory on the file. >>> For example, if I move a file from the FTP-upload folder to HTTPD >>> download >>> folder. >>> > If you're talking about moving things via shell commands, then using > the cp command will automatically change the context, if you have > sufficient rights to do so (read the old context, write the new > context, write to the folder...etc). >> It may make more sense to create a new context 'user_uploaded_t' or some >> such, and give the FTP server the access needed to write it, and the >> httpd >> the needed read access. That way, it gets "sandboxed" and even if it's >> malicious code, nothing else can accidentally read/execute it, so your >> system integrity is enhanced. >> public_content_rw_t (Formerly ftpd_anon_rw_t) has this characteristic. You can set booleans on whether http or ftp and write to it. All sharing apps can read it. (httpd, ftp, samba, rsync) > A type to taint untrusted content already exists (in strict policy > anyway, not sure about targeted) - it is called > $1_untrusted_content_t. This type does not "guard" the content within, > so you wouldn't use it to target information to be used by a specific > program (like, if you wanted the information to be available to httpd > only, but nothing else). Instead, it controls access by all content > consumers, based on global boolean (read_untrusted_content). > Currently, this is used mostly by desktop programs, for things like... > gpg (signing content), mplayer (playing movies), lpr (print stuff), > mail programs (upload stuff), mozilla client (upload stuff). > > Those applications currently use a macro called read_content() to > access all "trusted" data in /tmp, /home (not what you want), and > "untrusted" data, if you choose so. You can disable access to reading > "untrusted" data globally by setting the boolean. In any event, $1_t > has { relabelto relabelfrom } rights for this type. > > My point here is that an appropriate data type exists, IMHO. It might > have macros for it, designed for a different purpose in mind, but the > goal of the type is essentially the same (taint malicious data). It's > also customizable, so the taint persists after restorecon. > > I think a lot of this desktop stuff could be further refined to be > relevant to servers. If we can solve the desktop problem, then the > server problem becomes easy (desktop is a lot more complicated). >> Depending on your paranoia level, you may or may not want to allow some >> way for a process running in some user_t to un-sandbox the file. It >> may be >> sufficient to allow user_t to read it, as there probably shouldn't be >> any >> automated processes running as user_t - with the implicit "the user >> is taking >> responsibility for this"... >> > user_t has { relabelto relabelfrom } rights to the type I was discussing. > Note that you can still revoke user_t's rights to read such content, > to prevent accidental opening of dangerous files. > user_t keeps { getattr and unlink }. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From mike at plan99.net Thu Oct 13 13:55:46 2005 From: mike at plan99.net (Mike Hearn) Date: Thu, 13 Oct 2005 14:55:46 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> Message-ID: On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote: > The format is versioned the same way the kernel binary format is, so any > changes to the format use a different version number, and backward > compatbility is retained. That's good, but it's not what I asked. What are the binary compatibility commitments you guys are making? Is it expected that the format will change in future? Was it designed to be extendable? Is there some kind of internal chunking system so new data can be added in a way that older versions of SELinux will ignore? > only as neutral as policies are, which isn't all that neutral right now. Hmm, that sucks. For very simple policy like "this process can do XYZ" shouldn't it be independent of targeted vs strict/fedora vs gentoo? Are the capability names actually variable between distributions? > Hopefully this will change when reference policy is used by everyone > and optional tunables are built in to the language. OK, I'm glad there's a plan for this. > you might look at this thread: > http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more > information. Particularly the justification for building seperate packages > for policy and the application. OK. This doesn't affect autopackage so much as it's meant for third party packages, and therefore developers are expected to define their own policy which would be independent of strict/targeted. I question the solution given for RPM - why not simply fix RPM so it loads policy before installing files? thanks -mike From jbrindle at tresys.com Thu Oct 13 15:33:05 2005 From: jbrindle at tresys.com (Joshua Brindle) Date: Thu, 13 Oct 2005 11:33:05 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> Message-ID: <434E7E31.8070508@tresys.com> Mike Hearn wrote: > On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote: > >>The format is versioned the same way the kernel binary format is, so any >>changes to the format use a different version number, and backward >>compatbility is retained. > > > That's good, but it's not what I asked. What are the binary compatibility > commitments you guys are making? Is it expected that the format will > change in future? Was it designed to be extendable? Is there some kind of > internal chunking system so new data can be added in a way that older > versions of SELinux will ignore? > Ok, my answer was about the module format. The module format is versioned so that older policies will work with newer selinux systems, but vice versa isn't automatic, the module would need to be downgraded (there is a similar discussion to this on the selinux list currently) however, the package itself isn't versioned, if the format is changed older systems may not be able to cope with it. This is something we need to look at. > >>only as neutral as policies are, which isn't all that neutral right now. > > > Hmm, that sucks. For very simple policy like "this process can do XYZ" > shouldn't it be independent of targeted vs strict/fedora vs gentoo? > Are the capability names actually variable between distributions? > in all of the mentioned policies types and attributes may or may not be present and may have different meanings; filesystem labels may also be different. modules have the ability to enable policy based on the presence of symbols (types, attributes, etc) and this may help some but probably not entirely. > >> Hopefully this will change when reference policy is used by everyone >>and optional tunables are built in to the language. > > > OK, I'm glad there's a plan for this. > > >>you might look at this thread: >>http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more >>information. Particularly the justification for building seperate packages >>for policy and the application. > > > OK. This doesn't affect autopackage so much as it's meant for third party > packages, and therefore developers are expected to define their own policy > which would be independent of strict/targeted. I question the solution > given for RPM - why not simply fix RPM so it loads policy before > installing files? I think it is relavent because there are important concepts, proper integration with a package manager means several things: The modules must be associated with the packages someway (I suggest dependancies) The package manager must apply policy before installing an application, so that labeling will work correctly The package manager should install policy modules to a directory it 'owns' such as /usr/lib/selinux and then use libsemanage (semodule) to add modules. The package manager should understand how policy transactions work, conflicting modules that must be removed/added within the same transaction (such targeted and strict variations of the same policy) It should also fetch and install policy modules before installing a chain of applications, this way the policy isn't rebuilt/reloaded between every app that has a policy, which can lead to inconsistancies or worse, races. > > thanks -mike > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From sds at tycho.nsa.gov Thu Oct 13 15:29:10 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 13 Oct 2005 11:29:10 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> Message-ID: <1129217350.26188.216.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-10-13 at 14:55 +0100, Mike Hearn wrote: > On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote: > > The format is versioned the same way the kernel binary format is, so any > > changes to the format use a different version number, and backward > > compatbility is retained. > > That's good, but it's not what I asked. What are the binary compatibility > commitments you guys are making? Is it expected that the format will > change in future? Was it designed to be extendable? Is there some kind of > internal chunking system so new data can be added in a way that older > versions of SELinux will ignore? Good questions; I don't think that this has been fully resolved. MLS compatibility is also an issue; Fedora has enabled MLS/MCS, whereas other distros have not yet done so, and the format is affected by that. > Hmm, that sucks. For very simple policy like "this process can do XYZ" > shouldn't it be independent of targeted vs strict/fedora vs gentoo? > Are the capability names actually variable between distributions? Not the "capability names" i.e. class/permission names, but the domain/type names can vary. To the extent that the distributions use a common baseline for their policies, such variations should be minimal, and the reference policy will help in that respect going forward as well. To date, the NSA example policy has served that purpose, but not all distros have followed it. In the strict vs. targeted case, you have the issue that not all domains/types defined in the strict policy have equivalents in the targeted policy (since strict policy confines more processes and provides finer-grained distinctions), but that can largely be addressed via type aliases in the targeted policy so that you can refer to the strict policy type names regardless. > OK. This doesn't affect autopackage so much as it's meant for third party > packages, and therefore developers are expected to define their own policy > which would be independent of strict/targeted. I question the solution > given for RPM - why not simply fix RPM so it loads policy before > installing files? Yes, I agree with that. One potential issue is with installing a large number of packages; you'd like to be able to batch up all of the policy modules into a single policy update and load, and then unpack all of the packages. -- Stephen Smalley National Security Agency From mike at plan99.net Thu Oct 13 17:19:23 2005 From: mike at plan99.net (Mike Hearn) Date: Thu, 13 Oct 2005 18:19:23 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> <1129217350.26188.216.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Thu, 13 Oct 2005 11:29:10 -0400, Stephen Smalley wrote: > Good questions; I don't think that this has been fully resolved. MLS > compatibility is also an issue; Fedora has enabled MLS/MCS, whereas other > distros have not yet done so, and the format is affected by that. Ah, right ... yes this is the sort of thing we have to watch out for. I want to be able to distribute a single binary that works on any distro - think commercial software, though it's useful for open source projects too. > Not the "capability names" i.e. class/permission names, but the > domain/type names can vary. Right, OK, that's what I thought. My initial target is super-simple: restrict installers from loading kernel modules. I know there are lots of ways around that if this is the only restriction but I want to start simple and work up from there (next step would be to stop installers interfering with critical system files etc). One issue that will affect that is how uniform labelling is under /etc - hopefully Fedora, Gentoo and any other distros that support SELinux will move to the reference policy soon. Of course as only Fedora ships it on by default in a desktop install for now being Fedora specific is acceptable. > Yes, I agree with that. One potential issue is with installing a large > number of packages; you'd like to be able to batch up all of the policy > modules into a single policy update and load, and then unpack all of the > packages. Indeed. Autopackage can cope with that fine as it uses a two-phase install, but as AP isn't designed to run a distribution but rather distribute 3rd party software Loki Setup style, that's not much use here :) thanks -mike From mike at plan99.net Thu Oct 13 17:26:13 2005 From: mike at plan99.net (Mike Hearn) Date: Thu, 13 Oct 2005 18:26:13 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> <434E7E31.8070508@tresys.com> Message-ID: On Thu, 13 Oct 2005 11:33:05 -0400, Joshua Brindle wrote: > Ok, my answer was about the module format. The module format is versioned > so that older policies will work with newer selinux systems, but vice > versa isn't automatic, the module would need to be downgraded (there is a > similar discussion to this on the selinux list currently) Hmm, OK. As long as it's possible to generate the policy files on a standard desktop system then this is an OK tradeoff, though for efficiency reasons one backwards/forwards compatible file would be the best. What I'd really like to avoid is the sillyness we are in with header files and symbol versions, where you need obscure tricks to build on newer and run on older (or just do it in a VM). Having to use a VM to build portable policy wouldn't be much fun. > in all of the mentioned policies types and attributes may or may not be > present and may have different meanings; filesystem labels may also be > different. modules have the ability to enable policy based on the presence > of symbols (types, attributes, etc) and this may help some but probably > not entirely. It would be nice if there were some standards on how to identify particular vendor policy, eg: optional { require { fedora_targeted_t } # fedora specific stuff goes here } optional { require { gentoo_policy_t } # gentoo specific stuff goes here } But a unified policy would be the best solution. I hope Red Hat support the reference policy effort. > I think it is relavent because there are important concepts, proper > integration with a package manager means several things: > > The modules must be associated with the packages someway (I suggest > dependancies) Why not simply include the policy inside the package? Remember the use case for autopackage - a non-technical user goes to the SuperTux website and clicks the "Install SuperTux" button, Firefox downloads and opens the autopackage and the software installs. On any distro. I don't see why separating policy into a separate package here would be beneficial (though it could be done, AP supports dep resolution). > The package manager must apply policy before installing an application, so > that labeling will work correctly This can certainly be done. > The package manager should install policy modules to a directory it 'owns' > such as /usr/lib/selinux and then use libsemanage (semodule) to add > modules. If policy can go anywhere, I'd really like to see a standard directory like there is for .desktop files. If policy can be installed without root in a user-specific manner in future, then having a standard location in $HOME for it would be good. You said they were architecture-independent, so /usr/share/policy and $HOME/.config/policy (~/.config is a freedesktop.or thing) would seem sensible. > The package manager should understand how policy transactions work, > conflicting modules that must be removed/added within the same transaction > (such targeted and strict variations of the same policy) Can we have more information on this? Presumably for an upstream provided package, the answer is simply to uninstall the relevant RPM if present and install the new package - of course if policy is in a separate package then the old policy would still be lying around in this case. What happens if two policy modules define conflicting policy? Is it possible to find this out before install time? > It should also fetch and install policy modules before installing a chain > of applications, this way the policy isn't rebuilt/reloaded between every > app that has a policy, which can lead to inconsistancies or worse, races. That's not too hard for us to do. thanks -mike From jbrindle at tresys.com Thu Oct 13 18:00:54 2005 From: jbrindle at tresys.com (Joshua Brindle) Date: Thu, 13 Oct 2005 14:00:54 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> <434E7E31.8070508@tresys.com> Message-ID: <434EA0D6.5030901@tresys.com> Mike Hearn wrote: > On Thu, 13 Oct 2005 11:33:05 -0400, Joshua Brindle wrote: > >>Ok, my answer was about the module format. The module format is versioned >>so that older policies will work with newer selinux systems, but vice >>versa isn't automatic, the module would need to be downgraded (there is a >>similar discussion to this on the selinux list currently) > > > Hmm, OK. As long as it's possible to generate the policy files on a > standard desktop system then this is an OK tradeoff, though for efficiency > reasons one backwards/forwards compatible file would be the best. > > What I'd really like to avoid is the sillyness we are in with header files > and symbol versions, where you need obscure tricks to build on newer and > run on older (or just do it in a VM). Having to use a VM to build portable > policy wouldn't be much fun. > This is an interesting issue that I hadn't been thinking about.. > >>in all of the mentioned policies types and attributes may or may not be >>present and may have different meanings; filesystem labels may also be >>different. modules have the ability to enable policy based on the presence >>of symbols (types, attributes, etc) and this may help some but probably >>not entirely. > > > It would be nice if there were some standards on how to identify > particular vendor policy, eg: > > optional { > require { fedora_targeted_t } > > # fedora specific stuff goes here > } > > optional { > require { gentoo_policy_t } > > # gentoo specific stuff goes here > } > > But a unified policy would be the best solution. I hope Red Hat support > the reference policy effort. > we've talked about decorative types before, it's not that elegant but it would probably work. It doesn't address version issues though, if you watch the rawhide policy development you'll see alot happening, policy version specific dependencies are going to be a problem I think. > >>I think it is relavent because there are important concepts, proper >>integration with a package manager means several things: >> >>The modules must be associated with the packages someway (I suggest >>dependancies) > > > Why not simply include the policy inside the package? Remember the use > case for autopackage - a non-technical user goes to the SuperTux website > and clicks the "Install SuperTux" button, Firefox downloads and opens the > autopackage and the software installs. On any distro. I don't see why > separating policy into a separate package here would be beneficial > (though it could be done, AP supports dep resolution). > > >>The package manager must apply policy before installing an application, so >>that labeling will work correctly > > > This can certainly be done. > > >>The package manager should install policy modules to a directory it 'owns' >>such as /usr/lib/selinux and then use libsemanage (semodule) to add >>modules. > > > If policy can go anywhere, I'd really like to see a standard directory > like there is for .desktop files. If policy can be installed without root > in a user-specific manner in future, then having a standard location in > $HOME for it would be good. > > You said they were architecture-independent, so /usr/share/policy and > $HOME/.config/policy (~/.config is a freedesktop.or thing) would seem > sensible. > There should never be home or user based policies so they should go to a system location. It doesn't matter to me, so long as the package manager doesn't try mucking around in the module store directly. > >>The package manager should understand how policy transactions work, >>conflicting modules that must be removed/added within the same transaction >>(such targeted and strict variations of the same policy) > > > Can we have more information on this? Presumably for an upstream provided > package, the answer is simply to uninstall the relevant RPM if present and > install the new package - of course if policy is in a separate package > then the old policy would still be lying around in this case. > uninstalling the policy RPM won't remove it from the policy. Since the module installed to the system (/usr/share/selinux/policy or whatever) it will be removed but the one in the module store (not owned by RPM) wouldn't be. The RPM could probably use semodule to remove it as part of the uninstallation phase though. The AP packages also need to be able to handle this. However, say you are changing modules, you shouldn't uninstall one and then install the other in seperate transactions because the applications labels will become invalid (file and process). Of course the install of the new module should try to relabel affected files, but you'd have process labels invalidated in the process. The correct way is to start a transaction, remove the old module, add the new one and commit. If the type names change you'd have to shut down the application beforehand and relabel the files afterward. > What happens if two policy modules define conflicting policy? Is it > possible to find this out before install time? > They won't link so you'll get an error when you try to commit the transaction. > >>It should also fetch and install policy modules before installing a chain >>of applications, this way the policy isn't rebuilt/reloaded between every >>app that has a policy, which can lead to inconsistancies or worse, races. > > > That's not too hard for us to do. > This is the main reason I think seperate policy packages are better, if you are able to take all the pending packages, do the policy installs upfront and then the package installs it would be fine to package them together but the idea of doing 2 phase installs of a set of packages seems awkward. From mike at plan99.net Thu Oct 13 18:24:53 2005 From: mike at plan99.net (Mike Hearn) Date: Thu, 13 Oct 2005 19:24:53 +0100 Subject: Binary policy modules References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> <434E7E31.8070508@tresys.com> <434EA0D6.5030901@tresys.com> Message-ID: On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote: > There should never be home or user based policies so they should go to a > system location. It doesn't matter to me, so long as the package manager > doesn't try mucking around in the module store directly. Why not home/user based policies? If the user can install software to $HOME (and they can), why not policy too? If the meta-policy stuff works out then you should be able to impose extra restrictions/add extra rules, but not reduce the security of the system surely? > uninstalling the policy RPM won't remove it from the policy. Since the > module installed to the system (/usr/share/selinux/policy or whatever) it > will be removed but the one in the module store (not owned by RPM) > wouldn't be. The RPM could probably use semodule to remove it as part of > the uninstallation phase though. The AP packages also need to be able to > handle this. OK. > However, say you are changing modules, you shouldn't uninstall one and > then install the other in seperate transactions because the applications > labels will become invalid (file and process). Of course the install of > the new module should try to relabel affected files, but you'd have > process labels invalidated in the process. The correct way is to start a > transaction, remove the old module, add the new one and commit. If the > type names change you'd have to shut down the application beforehand and > relabel the files afterward. Does semodule let you do this kind of atomic exchange? thanks -mike From jbrindle at tresys.com Thu Oct 13 18:44:28 2005 From: jbrindle at tresys.com (Joshua Brindle) Date: Thu, 13 Oct 2005 14:44:28 -0400 Subject: Binary policy modules In-Reply-To: References: <1129133742.3308.306.camel@moss-spartans.epoch.ncsc.mil> <1129141465.3308.340.camel@moss-spartans.epoch.ncsc.mil> <434D65FF.9040209@tresys.com> <434E7E31.8070508@tresys.com> <434EA0D6.5030901@tresys.com> Message-ID: <434EAB0C.60802@tresys.com> Mike Hearn wrote: > On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote: > >>There should never be home or user based policies so they should go to a >>system location. It doesn't matter to me, so long as the package manager >>doesn't try mucking around in the module store directly. > > > Why not home/user based policies? If the user can install software to > $HOME (and they can), why not policy too? If the meta-policy stuff works > out then you should be able to impose extra restrictions/add extra rules, > but not reduce the security of the system surely? > I am dubious about this but in reality it isn't necessary to keep the module around at all so it isn't dangerous storing them in $HOME or anywhere else, so long as we are controlling access to the module store (coarse grained access via direct semanage and fine grained via policy management server) > >>uninstalling the policy RPM won't remove it from the policy. Since the >>module installed to the system (/usr/share/selinux/policy or whatever) it >>will be removed but the one in the module store (not owned by RPM) >>wouldn't be. The RPM could probably use semodule to remove it as part of >>the uninstallation phase though. The AP packages also need to be able to >>handle this. > > > OK. > > >>However, say you are changing modules, you shouldn't uninstall one and >>then install the other in seperate transactions because the applications >>labels will become invalid (file and process). Of course the install of >>the new module should try to relabel affected files, but you'd have >>process labels invalidated in the process. The correct way is to start a >>transaction, remove the old module, add the new one and commit. If the >>type names change you'd have to shut down the application beforehand and >>relabel the files afterward. > > > Does semodule let you do this kind of atomic exchange? > Yes. > thanks -mike > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From ejtr at layer3.co.uk Fri Oct 14 15:41:11 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 14 Oct 2005 16:41:11 +0100 Subject: Evolution - /var/spool and OpenOffice launching In-Reply-To: <1129295102.5186.26.camel@topaz.bugfinder.co.uk> References: <1129295102.5186.26.camel@topaz.bugfinder.co.uk> Message-ID: <1129304472.9139.18.camel@topaz.bugfinder.co.uk> After some more trawling through the policy for dontaudit references, I found that I needed to add the following: allow user_t { user_tmp_t tmp_t}:sock_file { getattr }; allow user_evolution_t { user_tmp_t tmp_t}:sock_file { getattr }; in addition to my existing patch granting { create write unlink } permissions to get OO to launch from Evo. As mentioned before, it seems that OO launched from user_t creates the socket as user_tmp_t, whereas when launched from user_evolution_t, OO creates the socket as tmp_t. Hence there is possibly still some tidyup to do to the evolution policy to make sure the socket is always created user_tmp_t? Now that I can launch OO from Evolution, another little problem has become apparent. If I launch OO from Evo, then launch OO natively from user_t, then close the native OO instance, I find that the user_evolution_t OO instance can't be closed cleanly. The process list before trying to close either shows two different copies of swriter.bin in user_t and user_evolution_t domains, but of course the sock_file appears to be shared by both instances with the same filename. Some more experimentation may reveal how to tweak SELinux to allow for a clean close of both instances, but I would imagine this is at best a fudge. On Fri, 2005-10-14 at 14:05 +0100, Ted Rule wrote: > I have a couple of problems with Evolution/OpenOffice running on > FC4/strict with policy: > > selinux-policy-strict-sources-1.27.1-2.3 > > The first, relatively simple, issue is that the user_evolution_t policy > doesn't seem to have provision for reading /var/spool/mail. I have > sendmail setup to forward root mail to my local non-root account, and > then Evolution setup to read the ensuing Unix mail spool locally in > addition to my remote IMAP/POP3 accounts. > > The extra var_spool_t and mail_spool_t policy listed below seems to do > the trick, though obviously a more complete solution would require > proper "macro-ising" to take account of staff_evolution_t and so on. > > As far as I can tell, there isn't a boolean switch to allow for this. > > > The second, slightly more intractable problem is that of > OpenOffice/Evolution integration. > > I have the allow_execmem boolean enabled to allow for a plain launch of > OpenOffice, but I find that an additional execmem policy - see below - > is needed to allow for the launch of OO from within Evolution's > "attachment view dialog" as it now has its own user_evolution_t domain > which seems to ignore the allow_execmem boolean. > > The execmem policy is still not sufficient to allow me to launch OO from > Evolution. I've added some extra policy to cope with denial messages > that I've seen for this socket file > > /tmp/OSL_PIPE_500_SingleOfficeIPC_2df8e6ac565346ee4ccc8ac992ddaa83 > > which OO creates, but this is still not enough to make OO fire up. > > The socket created by OO appears to get left behind once OO has > finished, which makes me suspect that part of the problem is that the > socket has a different file_context when created from user_t as opposed > to user_evolution_t. > > With my current patched policy, I get no further SELinux denial > messages, so debugging the problem has become trickier. Presumably there > is a dontaudit policy somewhere suppressing the error message I'm > interested in, but I haven't tracked it down yet. > > Any suggestions, folks? > > > Current patches to strict policy: > > ================================================================= > > > cat /etc/selinux/strict/src/policy/domains/program/localpolicy.te > # Miscellaneous Local SELinux policy not > # covered by other .te configuration > ... > > ############################################################## > # Patch to allow Evolution to read home mail spools > # Seemingly still required as not included in default policy > allow user_evolution_t var_spool_t:dir { search }; > allow user_evolution_t mail_spool_t:dir { read getattr search }; > allow user_evolution_t mail_spool_t:file { read getattr write }; > > ... > > ############################################################# > # Patch to allow Evolution to launch OpenOffice.... > allow user_evolution_t self:process { execmem }; > auditallow user_evolution_t self:process { execmem }; > > ############################################################# > # Patch to allow OpenOffice to write to a temporary socket.... > allow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; > auditallow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; > > ... > > # Patches to allow OpenOffice to write to a temporary socket....from > Evolution > allow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write > unlink }; > auditallow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write > unlink }; > > -- Ted Rule Director, Layer3 Systems Ltd E: ejtr at layer3.co.uk M: 07770 431471 W: http://www.layer3.co.uk/ From ejtr at layer3.co.uk Fri Oct 14 13:05:02 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Fri, 14 Oct 2005 14:05:02 +0100 Subject: Evolution - /var/spool and OpenOffice launching Message-ID: <1129295102.5186.26.camel@topaz.bugfinder.co.uk> I have a couple of problems with Evolution/OpenOffice running on FC4/strict with policy: selinux-policy-strict-sources-1.27.1-2.3 The first, relatively simple, issue is that the user_evolution_t policy doesn't seem to have provision for reading /var/spool/mail. I have sendmail setup to forward root mail to my local non-root account, and then Evolution setup to read the ensuing Unix mail spool locally in addition to my remote IMAP/POP3 accounts. The extra var_spool_t and mail_spool_t policy listed below seems to do the trick, though obviously a more complete solution would require proper "macro-ising" to take account of staff_evolution_t and so on. As far as I can tell, there isn't a boolean switch to allow for this. The second, slightly more intractable problem is that of OpenOffice/Evolution integration. I have the allow_execmem boolean enabled to allow for a plain launch of OpenOffice, but I find that an additional execmem policy - see below - is needed to allow for the launch of OO from within Evolution's "attachment view dialog" as it now has its own user_evolution_t domain which seems to ignore the allow_execmem boolean. The execmem policy is still not sufficient to allow me to launch OO from Evolution. I've added some extra policy to cope with denial messages that I've seen for this socket file /tmp/OSL_PIPE_500_SingleOfficeIPC_2df8e6ac565346ee4ccc8ac992ddaa83 which OO creates, but this is still not enough to make OO fire up. The socket created by OO appears to get left behind once OO has finished, which makes me suspect that part of the problem is that the socket has a different file_context when created from user_t as opposed to user_evolution_t. With my current patched policy, I get no further SELinux denial messages, so debugging the problem has become trickier. Presumably there is a dontaudit policy somewhere suppressing the error message I'm interested in, but I haven't tracked it down yet. Any suggestions, folks? Current patches to strict policy: ================================================================= cat /etc/selinux/strict/src/policy/domains/program/localpolicy.te # Miscellaneous Local SELinux policy not # covered by other .te configuration ... ############################################################## # Patch to allow Evolution to read home mail spools # Seemingly still required as not included in default policy allow user_evolution_t var_spool_t:dir { search }; allow user_evolution_t mail_spool_t:dir { read getattr search }; allow user_evolution_t mail_spool_t:file { read getattr write }; ... ############################################################# # Patch to allow Evolution to launch OpenOffice.... allow user_evolution_t self:process { execmem }; auditallow user_evolution_t self:process { execmem }; ############################################################# # Patch to allow OpenOffice to write to a temporary socket.... allow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; auditallow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; ... # Patches to allow OpenOffice to write to a temporary socket....from Evolution allow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write unlink }; auditallow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write unlink }; -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From rhp.lpt at gmail.com Fri Oct 14 06:35:49 2005 From: rhp.lpt at gmail.com (rhp) Date: Fri, 14 Oct 2005 13:35:49 +0700 Subject: seinfo on default umodified policy.conf reports policy syntax error Message-ID: 14-oct-05 Hello: Problem Summary: Two FC3 systems running permissive-targeted with identical error messages. targeted source rpm: selinux-policy-targeted-sources-1.17.30-3.16 'seinfo' run on umodified policy.conf reports syntax error in policy. 'sestatus' shows policy version 19 but policy files are policy.18 'checkpolicy' errors out on failure to open policy.conf Details: I have just started to work with SELinux, on my two Fedora Core 3, i686 systems. I am getting identical errors on both systems that I hope can be easily explained: During initial installation of FC3, I installed the targeted-binary policy and have been running in the default permissive-targeted mode. Recently I downloaded and installed the policy-targeted-source, policy-strict-source, and policy-strict rpm packages via yum so that I could begin to learn more about SELinux policy configuration. Here are the system identifications: 65 ellipse:~> uname -a Linux ellipse 2.6.12-1.1378_FC3.stk16 #1 Thu Sep 22 13:41:41 EDT 2005 i686 i686 i386 GNU/Linux 41 torus:~> uname -a Linux torus 2.6.13 #1 Mon Sep 5 16:37:24 ICT 2005 i686 i686 i386 GNU/Linux Here is a listing of the installed selinux packages on both systems: selinux-policy-targeted-sources-1.17.30-3.16 selinux-policy-strict-1.19.10-2 libselinux-1.19.1-8 selinux-policy-targeted-1.17.30-3.16 libselinux-devel-1.19.1-8 selinux-policy-strict-sources-1.19.10-2 selinux-doc-1.14.1-1 setools-1.4.1-5 setools-gui-1.4.1-5 checkpolicy-1.17.5-1.2 The following error/status conditions are identical on both systems: When running a test of seinfo against the default installation on both systems I get this error message: 'seinfo /etc/selinux/targeted/src/policy/policy.conf' error in the statement ending on line 3675 (token 'typeattribute'): syntax errorerror(s) encountered while parsing configuration (first pass, line: 3675) error reading policy A partial listing of policy.conf showing the putative syntax error location: 3666 3667 type unconfined_t, domain, privuser, privhome, privrole, privowner, admi 3667 n, auth_write, fs_domain, privmem; 3668 role system_r types unconfined_t; 3669 role user_r types unconfined_t; 3669 role user_r types unconfined_t; 3671 3672 #line 11 3673 3674 #line 11 -->> 3675 typeattribute unconfined_t unrestricted; 3676 #line 11 3677 I find it hard to believe that the default, umodified policy.conf would be released with syntax errors. Running seinfo against the binary policy returns: 66 ellipse:~> seinfo /etc/selinux/targeted/policy/policy.18 Statistics for policy file: /etc/selinux/targeted/policy/policy.18 Policy Version: v.18 Policy Type: binary Classes: 55 Permissions: 205 Types: 343 Attributes: 0 Users: 3 Roles: 4 Booleans: 30 Cond. Expr.: 32 Allow: 17620 Neverallow: 0 Auditallow: 3 Dontaudit: 1204 Type_trans: 201 Type_change: 0 Role allow: 5 Role trans: 0 Initial SIDs: 0 Note the policy version is 18. Running sestatus, on both systems I get this: SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 19 Policy from config file:targeted ... Note the Policy Version is listed as 19. However, checking the policy file extents I see they are policy.18: ls /etc/selinux/targeted/policy/ policy.18 ls /etc/selinux/strict/policy/ policy.18 However, checking the contents of the /etc/selinux/targeted/src/policy/VERSION and /etc/selinux/strict/src/policy/VERSION files I get 1.17 & 1.19 respectively. Additionally, a check of the contents of /selinux/policyvers returns '19'. Running 'checkpolicy', 'checkpolicy -c 18', & 'checkpolicy -d -c 18' all fail with this error message: checkpolicy: loading policy configuration from policy.conf checkpolicy: unable to open policy.conf running checkpolicy with '-c 19' returns an 'out of range' error message Uninstalling the 'selinux-policy-strict' and 'selinux-policy-strict-sources' rpms on one of the systems removes the /etc/selinux/strict tree from that system but does not change the policy version showed by sestatus, nor the error messages from seinfo and checkpolicy. Any help will be appreciated. Brgds Bob -- rhp.lpt at gmail.com From sds at tycho.nsa.gov Fri Oct 14 18:05:36 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 14 Oct 2005 14:05:36 -0400 Subject: seinfo on default umodified policy.conf reports policy syntax error In-Reply-To: References: Message-ID: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-10-14 at 13:35 +0700, rhp wrote: > Problem Summary: > > Two FC3 systems running permissive-targeted with identical error messages. > > targeted source rpm: selinux-policy-targeted-sources-1.17.30-3.16 > > 'seinfo' run on umodified policy.conf reports syntax error in policy. You understand that SELinux userspace doesn't get updated in older Fedora releases except in response to bug reports, right? So you have an old version of setools that doesn't know about changes in the policy language that have occurred since FC3 was shipped, and you have a policy update that uses some of those new language features. > 'sestatus' shows policy version 19 but policy files are policy.18 Two different pieces of information: - the first is the maximum binary policy format version supported by the kernel you are running (FC3 shipped with a kernel that only supported version 18, but you are running an update kernel that understands a later version as well - but is fully compatible with the older version), - the second is the binary policy format version generated by your checkpolicy, which likely hasn't been updated since FC3 was shipped. > 'checkpolicy' errors out on failure to open policy.conf If you don't specify a path to a policy.conf file, it looks for it in the current directory, so it will naturally fail if you aren't in the policy source directory at that point. > Here is a listing of the installed selinux packages on both systems: > > selinux-policy-targeted-sources-1.17.30-3.16 > selinux-policy-strict-1.19.10-2 > libselinux-1.19.1-8 > selinux-policy-targeted-1.17.30-3.16 > libselinux-devel-1.19.1-8 > selinux-policy-strict-sources-1.19.10-2 > selinux-doc-1.14.1-1 > setools-1.4.1-5 > setools-gui-1.4.1-5 > checkpolicy-1.17.5-1.2 Yes, the userspace tools above are quite old. > When running a test of seinfo against the default installation on both systems > I get this error message: > > 'seinfo /etc/selinux/targeted/src/policy/policy.conf' > > error in the statement ending on line 3675 (token 'typeattribute'): > syntax errorerror(s) encountered while parsing configuration (first > pass, line: 3675) > error reading policy New language statement introduced after FC3 shipped, so the FC3 tools don't understand it. I'd hazard a guess that the update policy was built using the latest toolchain rather than the actual ones on FC3. > Note the Policy Version is listed as 19. That's the highest version supported by your kernel. It retains backward compatibility with older versions though. > However, checking the policy file extents I see they are policy.18: > > ls /etc/selinux/targeted/policy/ > policy.18 > ls /etc/selinux/strict/policy/ > policy.18 That's the version generated by your checkpolicy. > However, checking the contents of the /etc/selinux/targeted/src/policy/VERSION > and /etc/selinux/strict/src/policy/VERSION files > I get 1.17 & 1.19 respectively. That's the release version of the upstream policy tarball from which the policy package was built, not related to the binary policy format version. > Additionally, a check of the contents of /selinux/policyvers returns '19'. Kernel version. > Running 'checkpolicy', 'checkpolicy -c 18', & 'checkpolicy -d -c 18' all > fail with this error message: > > checkpolicy: loading policy configuration from policy.conf > checkpolicy: unable to open policy.conf No policy.conf in your working directory? Specify a path to it otherwise. > running checkpolicy with '-c 19' returns an 'out of range' error message Because you have an old checkpolicy that doesn't support that version. Note: I'm just explaining - I don't maintain the SELinux packages for Fedora in any way, just the upstream SELinux. -- Stephen Smalley National Security Agency From mjs at ces.clemson.edu Fri Oct 14 18:38:07 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Fri, 14 Oct 2005 14:38:07 -0400 (EDT) Subject: acpid needs to talk to d-bus Message-ID: The latest Network Manager does some useful things across a suspend/resume cycle, but it relies on a dbus-send signal from the /etc/acpi/actions/sleep script. My script fails to deliver that signal when invoked from acpid in enforcing mode, but it works fine from the command line or in permissive mode. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dwalsh at redhat.com Fri Oct 14 18:52:21 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 14 Oct 2005 14:52:21 -0400 Subject: acpid needs to talk to d-bus In-Reply-To: References: Message-ID: <434FFE65.3030702@redhat.com> Matthew Saltzman wrote: > The latest Network Manager does some useful things across a > suspend/resume cycle, but it relies on a dbus-send signal from the > /etc/acpi/actions/sleep script. > > My script fails to deliver that signal when invoked from acpid in > enforcing mode, but it works fine from the command line or in > permissive mode. > What avc messages are you seeing? Dan -- From mjs at ces.clemson.edu Fri Oct 14 19:32:42 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Fri, 14 Oct 2005 15:32:42 -0400 (EDT) Subject: acpid needs to talk to d-bus In-Reply-To: <434FFE65.3030702@redhat.com> References: <434FFE65.3030702@redhat.com> Message-ID: On Fri, 14 Oct 2005, Daniel J Walsh wrote: > Matthew Saltzman wrote: >> The latest Network Manager does some useful things across a suspend/resume >> cycle, but it relies on a dbus-send signal from the /etc/acpi/actions/sleep >> script. >> >> My script fails to deliver that signal when invoked from acpid in enforcing >> mode, but it works fine from the command line or in permissive mode. >> > What avc messages are you seeing? Now that you mention it, it looks like ifdown (called from NetworkManager?) is the problem: type=AVC msg=audit(1129317799.800:18): avc: denied { execute } for pid=3421 comm="ifdown" name="functions" dev=dm-0 ino=16571 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1129317799.800:18): arch=40000003 syscall=33 success=yes exit=0 a0=864dff8 a1=1 a2=864dff8 a3=864b098 items=1 pid=3421 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifdown" exe="/bin/bash" type=CWD msg=audit(1129317799.800:18): cwd="/" type=PATH msg=audit(1129317799.800:18): item=0 name="/etc/init.d/functions" flags=401 inode=16571 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1129317799.804:19): avc: denied { execute } for pid=3424 comm="ifdown" name="consoletype" dev=dm-0 ino=622670 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=AVC msg=audit(1129317799.804:19): avc: denied { execute_no_trans } for pid=3424 comm="ifdown" name="consoletype" dev=dm-0 ino=622670 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=AVC msg=audit(1129317799.804:19): avc: denied { read } for pid=3424 comm="ifdown" name="consoletype" dev=dm-0 ino=622670 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:consoletype_exec_t:s0 tclass=file type=SYSCALL msg=audit(1129317799.804:19): arch=40000003 syscall=11 success=yes exit=0 a0=8651a18 a1=8651a60 a2=8651580 a3=0 items=2 pid=3424 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="consoletype" exe="/sbin/consoletype" type=AVC_PATH msg=audit(1129317799.804:19): path="/sbin/consoletype" type=AVC_PATH msg=audit(1129317799.804:19): path="/sbin/consoletype" type=CWD msg=audit(1129317799.804:19): cwd="/" type=PATH msg=audit(1129317799.804:19): item=0 name="/sbin/consoletype" flags=101 inode=622670 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1129317799.804:19): item=1 flags=101 inode=819233 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1129317799.844:20): avc: denied { execute_no_trans } for pid=3421 comm="ifdown" name="ifdown-ppp" dev=dm-0 ino=20434 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1129317799.844:20): arch=40000003 syscall=11 success=yes exit=0 a0=864ece0 a1=864e660 a2=864e2c0 a3=0 items=3 pid=3421 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifdown-ppp" exe="/bin/bash" type=AVC_PATH msg=audit(1129317799.844:20): path="/etc/sysconfig/network-scripts/ifdown-ppp" type=CWD msg=audit(1129317799.844:20): cwd="/etc/sysconfig/network-scripts" type=PATH msg=audit(1129317799.844:20): item=0 name="/etc/sysconfig/network-scripts/ifdown-ppp" flags=101 inode=20434 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1129317799.844:20): item=1 flags=101 inode=753755 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1129317799.844:20): item=2 flags=101 inode=819233 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1129317799.888:21): avc: denied { ioctl } for pid=3421 comm="ifdown-ppp" name="ifdown-ppp" dev=dm-0 ino=20434 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file type=SYSCALL msg=audit(1129317799.888:21): arch=40000003 syscall=54 success=no exit=-25 a0=3 a1=5401 a2=bf97d068 a3=bf97d0a8 items=0 pid=3421 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifdown-ppp" exe="/bin/bash" type=AVC_PATH msg=audit(1129317799.888:21): path="/etc/sysconfig/network-scripts/ifdown-ppp" The relevant section of the script is: /usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager --type=method_call /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.sleep sync echo -n "mem" > /sys/power/state /usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager --type=method_call /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.wake > > Dan > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From sds at tycho.nsa.gov Fri Oct 14 18:22:12 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 14 Oct 2005 14:22:12 -0400 Subject: seinfo on default umodified policy.conf reports policy syntax error In-Reply-To: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> References: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1129314132.3729.42.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-10-14 at 14:05 -0400, Stephen Smalley wrote: > You understand that SELinux userspace doesn't get updated in older > Fedora releases except in response to bug reports, right? So you have > an old version of setools that doesn't know about changes in the policy > language that have occurred since FC3 was shipped, and you have a policy > update that uses some of those new language features. FC3 is almost at its end of life anyway, right (end of the year, I suppose, if it is supposed to track the FC5 test2 release)? FC4 was released last June - might want to migrate to it. -- Stephen Smalley National Security Agency From jam at zoidtechnologies.com Sun Oct 16 15:31:16 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Sun, 16 Oct 2005 11:31:16 -0400 Subject: need updated policy for postfix and /etc/aliases.db Message-ID: <1129476676.18446.64.camel@eros.zoidtechnologies.com> Greetings! I have the following in audit.log: type=AVC msg=audit(1129476522.717:3618): avc: denied { lock } for pid=20074 comm="smtpd" name="aliases.db" dev=dm-0 ino=3015628 scontext=root:system_r:postfix_smtpd_t tcontext=root:object_r:etc_t tclass=file type=SYSCALL msg=audit(1129476522.717:3618): arch=40000003 syscall=143 success=yes exit=0 a0=c a1=1 a2=809a4cc a3=1 items=0 pid=20074 auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 fsgid=89 comm="smtpd" exe="/usr/libexec/postfix/smtpd" type=AVC_PATH msg=audit(1129476522.717:3618): path="/etc/aliases.db" Looks like there needs to be a policy update. Regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2 -------------- 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 ejtr at layer3.co.uk Mon Oct 17 10:51:35 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 17 Oct 2005 11:51:35 +0100 Subject: Evolution: OpenOffice / Firefox integration problems Message-ID: <1129546295.9522.19.camel@topaz.bugfinder.co.uk> I've noted before that Evolution has some some problems launching OpenOffice with SELinux enforcement in place. After some further experimentation with different policy settings, and also different sequences of opening and closing OpenOffice from GNOME and/or Evolution, some more findings. I've also found a similar issue relating to Firefox launching from Evolution. As mentioned before, I still need various extra permissions on /var/spool so as to be able to read Unix mail spools from Evolution: allow user_evolution_t var_spool_t:dir { search }; allow user_evolution_t mail_spool_t:dir { read getattr search }; allow user_evolution_t mail_spool_t:file { read getattr write }; I still need an extra execmem permission so as to be able to launch OpenOffice from Evolution's user_evolution_t domain: allow user_evolution_t self:process { execmem }; So as to avoid extra permissions on the user_t domain, I add a transition to the user_evolution_t domain for the Unix socket in /tmp/OSL_PIPE_500_SingleOfficeIPC_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx type_transition user_evolution_t tmp_t:sock_file user_tmp_t; The transition ensures that OpenOffice in user_t and from user_evolution_t create the socket in the same user_tmp_t domain. We add extra permissions so as to allow OpenOffice opened from Evolution, (Evo/OO), to write/delete/create the socket: allow user_evolution_t { user_tmp_t }:sock_file { getattr write unlink create }; We add an "optional" permission for OpenOffice opened from GNOME, ( raw/OO ), to be able to connect to the socket created by Evo/OO. allow user_t user_evolution_t:unix_stream_socket { connectto }; For completeness, it should be noted that the policy ALREADY contains the following permission: allow user_evolution_t user_t:unix_stream_socket { connectto }; i.e. "connect backwards". Without ALL of the extra permissions in the user_evolution_t domain, Evo/OO fails to launch. It is apparent from the logs that it does fire up, but once it spots the "broken" socket permissions, it shuts down again. With the combination of these extra permission in place, we find the following behaviour. If I launch Evo/OO with no copy of raw/OO already running, the Evo/OO process runs in the user_evolution_t domain. It first of all tries to write to the socket - which still exists in /tmp courtesy of the last invocation of raw/OO not 'cleaning up'. Probably because of catching an EPIPE or similar signal, it finds no-one listening on the socket, and proceeds to unlink/create a fresh socket. Just for luck, it then writes to it. If I then launch raw/OO with the Evo/OO already running, a new user_t swriter.bin process launches. Once running, it then appears to write to the existing user_evolution_t socket. As best I can judge, it then "pumps" the raw/OO document through the socket, whereupon it is visible in a 2nd Window running under the Evo/OO instance. Once the "pumping" has finished, the raw/OO process closes. This leaves the raw/OO document open inside the Evo/OO process. This leads to a significant problem. The 'raw/OO' document is now marked as "read-only", because if you've opened a user_home_t file, Evolution has no write permissions to the original file. The user "experience" is thus confused by a window which was apparently opened with sufficient permissions to edit the file being swapped for a window which has no such permissions. Conversely, if I launch Evo/OO with raw/OO already running, Evo/OO "connects back" to raw/OO via the existing socket and pumps the Evo/OO attachment into the raw/OO user_t process. At which point, of course, the Evo/OO user_evolution_t process closes, leaving the attachment open inside a process with "elevated" user_t permissions. If this permission: allow user_t user_evolution_t:unix_stream_socket { connectto }; is removed from the mix, then when launching raw/OO after Evo/OO is already open, it finds that it can't connect to the current socket and the document opens in a user_t window/process, with the original attachment open in a user_evolution_t window/process. If raw/OO is closed before Evo/OO, raw/OO still has sufficient permissions on the socket to confuse the Evo/OO instance, and Evo/OO fails to shut down cleanly, requiring a "Force Quit" dialog box. Having seen all of this behaviour, a number of potential corrective measures occur to me, some of which are OpenOffice rewrites, and some of which are SELinux policy changes. 1. If OpenOffice were recoded to gracefully allow for a situation where it had no rights to open/write/delete the Unix domain socket, the Evo/OO process/window could launch without error, and display the attachment with user_evolution_t permissions. This would allow two processes - one in user_t and one in user_evolution_t to run side by side, and would avoid the need for any extra user_evolution_t permissions diluting the strength of the policy. 2. OpenOffice should probably be corrected to remove the socket upon shutdown rather than rely on system reboot or tmpwatch to do the job. 3. From what I can see, I assume that the socket name is constructed from my Unix login id, and hence is unique to each login on the system. If OO were more SELinux aware it would construct the name based on login.SELinux-domain so that multiple attachment windows could share a user_evolution_t process, whilst a different socket allowed different documents to share a user_t process. This would probably be more difficult to code than 1. 4. The attachment is temporarily saved in ~/.evolution/cache/tmp/xxxxxx, and hence is created in the user_evolution_home_t domain. When Evo/OO launches, it would appear to have write permissions to the temporary copy. This feels wrong to me. Surely the "attachment viewer" process should only have read permissions on the original attachment. Sadly, this seems to require the creation of some sort of user_evolution_viewer_t domain for Evo/OO to run inside. A positive side-effect of this would be that the domain's networking permissions could be cut back as compared to user_evolution_t; a viewer domain would surely never need rights to speak IMAP/POP3 for instance. 5. The user_evolution_t domain appears to already have this set of permissions into the user_t domain: allow user_evolution_t user_t:unix_stream_socket connectto; allow user_evolution_t user_t:unix_stream_socket { read write }; The corresponding permissions in the other direction: allow user_t user_evolution_t:unix_stream_socket connectto; allow user_t user_evolution_t:unix_stream_socket { read write }; don't exist in the default policy. The former seems to be a side-effect of the ice_connect macros used by gnome_application macro. I can see there are some FIXMEs scattered in the ice_macros policy, so I presume a more specific ice domain fix is in hand. Having surmised what was happening with OpenOffice inside Evolution, I've had a look at what happens with Firefox opening a URL from Evolution, and Evince opening a PDF attachment from Evolution. With Evince, the operation is much cleaner. A separate user_evolution_t Evince process is launched irrespective of whether a user_t Evince process already exists. There is still the issue of the original attachment being read/write to the user_evolution_t Evince process, of course. With Firefox, a new window is created if a user_mozilla_t Firefox process already exists, but "of course", the window is shared with the single user_mozilla_t firefox.bin process. If no Firefox process already exists, the Evolution silently fails to open the URL. The policy appears to already allow for Evolution to launch Firefox courtesy of the mail_client_domain macro, so this appears to be an actual bug in the policy somewhere. FWIW, the firefox scripts detect whether another process exists, and launch "mozilla-xremote-client" instead if it does and firefox-bin if it doesn't. Following the trail of error messages that I can find, it seems that the failure relates to an inability to find various shared libraries, which in turn points to a missing LD_LIBRARY_PATH. By symlinking various mozilla libraries into /usr/lib, I can work round most of the errors, but this is not a proper fix. /usr/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory Searching for the launch path for firefox, we find that /usr/bin/firefox is a script which launches other scripts and binaries in /usr/lib/firefox and /usr/lib/mozilla... The gotcha which caught my eye was that the script /usr/bin/mozilla has a mozilla_exec_t label, whilst /usr/bin/firefox is labelled bin_t. Eventually /usr/bin/firefox calls /usr/lib/firefox-1.0.7/firefox-bin which is marked mozilla_exec_t. I therefore reasoned that the LD_LIBRARY_PATH setting was lost in the domain transition from /usr/bin/firefox running in user_evolution_t to /usr/lib/firefox-1.0.7/firefox-bin running in user_mozilla_t. By relabelling /usr/bin/firefox as mozilla_exec_t, I can now launch firefox from Evolution under all circumstances. This means that the PATH setup in /usr/bin/firefox is preserved as no domain transition takes place when invoking firefox-bin - it occurs when Evolution calls /usr/bin/firefox instead. This may not be the best fix, but given that the /usr/bin/mozilla script has a mozilla_exec_t label, it seems reasonable to me. -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From dwalsh at redhat.com Mon Oct 17 15:29:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 11:29:09 -0400 Subject: need updated policy for postfix and /etc/aliases.db In-Reply-To: <1129476676.18446.64.camel@eros.zoidtechnologies.com> References: <1129476676.18446.64.camel@eros.zoidtechnologies.com> Message-ID: <4353C345.2090300@redhat.com> Jeff MacDonald wrote: > Greetings! > > I have the following in audit.log: > > type=AVC msg=audit(1129476522.717:3618): avc: denied { lock } for > pid=20074 comm="smtpd" name="aliases.db" dev=dm-0 ino=3015628 > scontext=root:system_r:postfix_smtpd_t tcontext=root:object_r:etc_t > tclass=file > type=SYSCALL msg=audit(1129476522.717:3618): arch=40000003 syscall=143 > success=yes exit=0 a0=c a1=1 a2=809a4cc a3=1 items=0 pid=20074 > auid=4294967295 uid=89 gid=89 euid=89 suid=89 fsuid=89 egid=89 sgid=89 > fsgid=89 comm="smtpd" exe="/usr/libexec/postfix/smtpd" > type=AVC_PATH msg=audit(1129476522.717:3618): path="/etc/aliases.db" > > Looks like there needs to be a policy update. > > restorecon /etc/aliases.db The file has the wrong security context on it. Any idea how this file was created? > Regards, > J > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From jam at zoidtechnologies.com Mon Oct 17 15:31:27 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Mon, 17 Oct 2005 11:31:27 -0400 Subject: need updated policy for postfix and /etc/aliases.db In-Reply-To: <4353C345.2090300@redhat.com> References: <1129476676.18446.64.camel@eros.zoidtechnologies.com> <4353C345.2090300@redhat.com> Message-ID: <1129563088.18446.68.camel@eros.zoidtechnologies.com> On Mon, 2005-10-17 at 11:29 -0400, Daniel J Walsh wrote: > > > > Looks like there needs to be a policy update. > > > > > restorecon /etc/aliases.db > > The file has the wrong security context on it. > > Any idea how this file was created? using "postalias" as root, afaik. Regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2 -------------- 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 dwalsh at redhat.com Mon Oct 17 15:37:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 11:37:43 -0400 Subject: Evolution - /var/spool and OpenOffice launching In-Reply-To: <1129304472.9139.18.camel@topaz.bugfinder.co.uk> References: <1129295102.5186.26.camel@topaz.bugfinder.co.uk> <1129304472.9139.18.camel@topaz.bugfinder.co.uk> Message-ID: <4353C547.9090406@redhat.com> Ted Rule wrote: > After some more trawling through the policy for dontaudit references, I > found that I needed to add the following: > > allow user_t { user_tmp_t tmp_t}:sock_file { getattr }; > allow user_evolution_t { user_tmp_t tmp_t}:sock_file { getattr }; > > in addition to my existing patch granting { create write unlink } > permissions to get OO to launch from Evo. > > As mentioned before, it seems that OO launched from user_t creates the > socket as user_tmp_t, whereas when launched from user_evolution_t, OO > creates the socket as tmp_t. Hence there is possibly still some tidyup > to do to the evolution policy to make sure the socket is always created > user_tmp_t? > > Now that I can launch OO from Evolution, another little problem has > become apparent. If I launch OO from Evo, then launch OO natively from > user_t, then close the native OO instance, I find that the > user_evolution_t OO instance can't be closed cleanly. The process list > before trying to close either shows two different copies of swriter.bin > in user_t and user_evolution_t domains, but of course the sock_file > appears to be shared by both instances with the same filename. Some more > experimentation may reveal how to tweak SELinux to allow for a clean > close of both instances, but I would imagine this is at best a fudge. > > > > On Fri, 2005-10-14 at 14:05 +0100, Ted Rule wrote: > >> I have a couple of problems with Evolution/OpenOffice running on >> FC4/strict with policy: >> >> selinux-policy-strict-sources-1.27.1-2.3 >> >> The first, relatively simple, issue is that the user_evolution_t policy >> doesn't seem to have provision for reading /var/spool/mail. I have >> sendmail setup to forward root mail to my local non-root account, and >> then Evolution setup to read the ensuing Unix mail spool locally in >> addition to my remote IMAP/POP3 accounts. >> >> The extra var_spool_t and mail_spool_t policy listed below seems to do >> the trick, though obviously a more complete solution would require >> proper "macro-ising" to take account of staff_evolution_t and so on. >> >> As far as I can tell, there isn't a boolean switch to allow for this. >> >> >> The second, slightly more intractable problem is that of >> OpenOffice/Evolution integration. >> >> I have the allow_execmem boolean enabled to allow for a plain launch of >> OpenOffice, but I find that an additional execmem policy - see below - >> is needed to allow for the launch of OO from within Evolution's >> "attachment view dialog" as it now has its own user_evolution_t domain >> which seems to ignore the allow_execmem boolean. >> >> The execmem policy is still not sufficient to allow me to launch OO from >> Evolution. I've added some extra policy to cope with denial messages >> that I've seen for this socket file >> >> /tmp/OSL_PIPE_500_SingleOfficeIPC_2df8e6ac565346ee4ccc8ac992ddaa83 >> >> which OO creates, but this is still not enough to make OO fire up. >> >> The socket created by OO appears to get left behind once OO has >> finished, which makes me suspect that part of the problem is that the >> socket has a different file_context when created from user_t as opposed >> to user_evolution_t. >> >> With my current patched policy, I get no further SELinux denial >> messages, so debugging the problem has become trickier. Presumably there >> is a dontaudit policy somewhere suppressing the error message I'm >> interested in, but I haven't tracked it down yet. >> >> Any suggestions, folks? >> >> >> Current patches to strict policy: >> >> ================================================================= >> >> >> cat /etc/selinux/strict/src/policy/domains/program/localpolicy.te >> # Miscellaneous Local SELinux policy not >> # covered by other .te configuration >> ... >> >> ############################################################## >> # Patch to allow Evolution to read home mail spools >> # Seemingly still required as not included in default policy >> allow user_evolution_t var_spool_t:dir { search }; >> allow user_evolution_t mail_spool_t:dir { read getattr search }; >> allow user_evolution_t mail_spool_t:file { read getattr write }; >> >> ... >> >> ############################################################# >> # Patch to allow Evolution to launch OpenOffice.... >> allow user_evolution_t self:process { execmem }; >> auditallow user_evolution_t self:process { execmem }; >> >> ############################################################# >> # Patch to allow OpenOffice to write to a temporary socket.... >> allow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; >> auditallow user_t { user_tmp_t tmp_t}:sock_file { create write unlink }; >> >> ... >> >> # Patches to allow OpenOffice to write to a temporary socket....from >> Evolution >> allow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write >> unlink }; >> auditallow user_evolution_t { user_tmp_t tmp_t}:sock_file { create write >> unlink }; >> >> >> > > Ted, You are coming to the point where Usability and Security crash. One of the problems with using Strict policy to protect applications like Firefox and Thunderbird/Evolution. Is users want the application to run as it always did but prevent it from doing evil things. In my opinion you need to define a very strict way of running Firefox/Thunderbird/Evolution or you run them in the default user context. If you want them to be able to run Open Office, RPM, or any other application that is associated with a file type, the policy for Firefox and Thunderbird quickly expands to the policy for user_t. So you gain no protection. Now if you define a security policy that says Firefox can only read html content and can only download to ~/My Downloads or /tmp. We can start to lock the app down. Similarly we can lock down your mail clients. But if you do not have the authority to lock down these apps you might as well run them as user_t (Disable Trans). -- From dwalsh at redhat.com Mon Oct 17 15:38:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 11:38:53 -0400 Subject: need updated policy for postfix and /etc/aliases.db In-Reply-To: <1129563088.18446.68.camel@eros.zoidtechnologies.com> References: <1129476676.18446.64.camel@eros.zoidtechnologies.com> <4353C345.2090300@redhat.com> <1129563088.18446.68.camel@eros.zoidtechnologies.com> Message-ID: <4353C58D.4020609@redhat.com> Jeff MacDonald wrote: > On Mon, 2005-10-17 at 11:29 -0400, Daniel J Walsh wrote: > >>> Looks like there needs to be a policy update. >>> >>> >>> >> restorecon /etc/aliases.db >> >> The file has the wrong security context on it. >> >> Any idea how this file was created? >> > > using "postalias" as root, afaik. > > Regards, > J > Are you running FC4? -- From jam at zoidtechnologies.com Mon Oct 17 15:47:32 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Mon, 17 Oct 2005 11:47:32 -0400 Subject: need updated policy for postfix and /etc/aliases.db In-Reply-To: <4353C58D.4020609@redhat.com> References: <1129476676.18446.64.camel@eros.zoidtechnologies.com> <4353C345.2090300@redhat.com> <1129563088.18446.68.camel@eros.zoidtechnologies.com> <4353C58D.4020609@redhat.com> Message-ID: <1129564052.18446.70.camel@eros.zoidtechnologies.com> On Mon, 2005-10-17 at 11:38 -0400, Daniel J Walsh wrote: > Are you running FC4? > yes. all patches applied. regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2 -------------- 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 khamenya at gmail.com Sun Oct 16 15:18:46 2005 From: khamenya at gmail.com (Valery Khamenya) Date: Sun, 16 Oct 2005 17:18:46 +0200 Subject: FC4, SELinux, virtual hosts, upload web content Message-ID: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> Dear Daniel and all, I am trying to enable upload for all my virtual hosts placed in /var/www . The goal is to allow users upload their content via ftp/sftp/scp . First I tried vsftpd as a basis for upload, but got problem: httpd_sys_content_t is needed by apache and user_home_t is needed by chrooted vsftpd access. Togeter httpd_sys_content_t and user_home_t probably might be combined by editing SELinux targeted polices, but i'd better deny to do it myself. Then I tried scp. The similar problem appeared. Q: What is the Right Way to organize upload of web content to the virtual hosts with enabled SELinux? here I imply that ideology of FC4 and SELinux targeted policy should probably allow private user to host few virtual hosts with upload function, but without diving in jungle of policy develoment :-) Any good links and hints are highly appreciated! P.S. Please Cc to me, and sorry if missed something in maillist. -- Valery A.Khamenya From jam at zoidtechnologies.com Mon Oct 17 16:08:50 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Mon, 17 Oct 2005 12:08:50 -0400 Subject: fc4 procmail audit.log entries Message-ID: <1129565330.18446.75.camel@eros.zoidtechnologies.com> Greetings, I'm running procmail and spamassassin on a fully patched FC4 box. I have the following procmail related entries in audit.log: type=AVC msg=audit(1129564863.023:3868): avc: denied { search } for pid=5450 comm="procmail" name="tmp" dev=dm-0 ino=262145 scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=SYSCALL msg=audit(1129564863.023:3868): arch=40000003 syscall=196 success=no exit=-2 a0=93f8eb0 a1=bfc64dac a2=8b7ff4 a3=93f8ec1 items=1 pid=5450 auid=4294967295 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 comm="procmail" exe="/usr/bin/procmail" type=CWD msg=audit(1129564863.023:3868): cwd="/home/jam" type=PATH msg=audit(1129564863.023:3868): item=0 name="/tmp/_KVB +8q8UDB.eros.zoidtechnolo" flags=310 type=AVC msg=audit(1129564863.023:3869): avc: denied { write } for pid=5450 comm="procmail" name="tmp" dev=dm-0 ino=262145 scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=AVC msg=audit(1129564863.023:3869): avc: denied { add_name } for pid=5450 comm="procmail" name="_KVB+8q8UDB.eros.zoidtechnolo" scontext=root:system_r:postfix_local_t tcontext=system_u:object_r:tmp_t tclass=dir type=SYSCALL msg=audit(1129564863.023:3869): arch=40000003 syscall=5 success=yes exit=5 a0=93f8eb0 a1=80c1 a2=124 a3=80c1 items=1 pid=5450 auid=4294967295 uid=500 gid=501 euid=500 suid=500 fsuid=500 egid=501 sgid=501 fsgid=501 comm="procmail" exe="/usr/bin/procmail" Regards, J -- Jeff MacDonald Zoid Technologies GPG Fingerprint: 0831 879E B6B4 C4CC D3C9 419F B12D E3CE B927 04B2 -------------- 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 dwalsh at redhat.com Mon Oct 17 19:12:02 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 15:12:02 -0400 Subject: FC4, SELinux, virtual hosts, upload web content In-Reply-To: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> Message-ID: <4353F782.7000603@redhat.com> Valery Khamenya wrote: > Dear Daniel and all, > > I am trying to enable upload for all my virtual hosts placed in /var/www . > > The goal is to allow users upload their content via ftp/sftp/scp . > > First I tried vsftpd as a basis for upload, but got problem: > httpd_sys_content_t is needed by apache and user_home_t is needed by > chrooted vsftpd access. Togeter httpd_sys_content_t and user_home_t > probably might be combined by editing SELinux targeted polices, but > i'd better deny to do it myself. > > Then I tried scp. The similar problem appeared. > > Q: What is the Right Way to organize upload of web content to the > virtual hosts with enabled SELinux? > > here I imply that ideology of FC4 and SELinux targeted policy should > probably allow private user to host few virtual hosts with upload > function, but without diving in jungle of policy develoment :-) > > Any good links and hints are highly appreciated! > > P.S. Please Cc to me, and sorry if missed something in maillist. > -- > Valery A.Khamenya > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Try public_content_rw_t? -- From dwalsh at redhat.com Mon Oct 17 20:30:25 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 16:30:25 -0400 Subject: FC4, SELinux, virtual hosts, upload web content In-Reply-To: <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> Message-ID: <435409E1.1000107@redhat.com> Valery Khamenya wrote: >> Try public_content_rw_t? >> > > now tried. Nothing works after applying public_content_rw_t now. > Neither ftp, nor scp nor even web. > > you need to turn on the correct booleans to allow it to work. setsebool -P allow_ftpd_anon_write=1 > Let me know please if i could bring some reasonable logs. > > Thank you in advance for any further help, > best regards, > Valery. > > P.S. below goes the ... > # getsebool -a > NetworkManager_disable_trans --> inactive > allow_execmem --> active > allow_execmod --> active > allow_execstack --> active > allow_ftpd_anon_write --> inactive > allow_gssd_read_tmp --> active > allow_httpd_anon_write --> inactive > allow_httpd_sys_script_anon_write --> inactive > allow_kerberos --> active > allow_rsync_anon_write --> inactive > allow_saslauthd_read_shadow --> inactive > allow_smbd_anon_write --> inactive > allow_write_xshm --> inactive > allow_ypbind --> inactive > apmd_disable_trans --> inactive > arpwatch_disable_trans --> inactive > auditd_disable_trans --> inactive > bluetooth_disable_trans --> inactive > canna_disable_trans --> inactive > cardmgr_disable_trans --> inactive > comsat_disable_trans --> inactive > cupsd_config_disable_trans --> inactive > cupsd_disable_trans --> inactive > cupsd_lpd_disable_trans --> inactive > cvs_disable_trans --> inactive > cyrus_disable_trans --> inactive > dbskkd_disable_trans --> inactive > dhcpc_disable_trans --> inactive > dhcpd_disable_trans --> inactive > dovecot_disable_trans --> inactive > fingerd_disable_trans --> inactive > ftp_home_dir --> active > ftpd_disable_trans --> active > ftpd_is_daemon --> active > gssd_disable_trans --> inactive > hald_disable_trans --> inactive > hotplug_disable_trans --> inactive > howl_disable_trans --> inactive > hplip_disable_trans --> inactive > httpd_builtin_scripting --> active > httpd_can_network_connect --> inactive > httpd_disable_trans --> inactive > httpd_enable_cgi --> active > httpd_enable_homedirs --> active > httpd_ssi_exec --> active > httpd_suexec_disable_trans --> inactive > httpd_tty_comm --> inactive > httpd_unified --> active > inetd_child_disable_trans --> inactive > inetd_disable_trans --> inactive > innd_disable_trans --> inactive > kadmind_disable_trans --> inactive > klogd_disable_trans --> inactive > krb5kdc_disable_trans --> inactive > ktalkd_disable_trans --> inactive > lpd_disable_trans --> inactive > mysqld_disable_trans --> inactive > named_disable_trans --> inactive > named_write_master_zones --> inactive > nfs_export_all_ro --> active > nfs_export_all_rw --> active > nfsd_disable_trans --> inactive > nmbd_disable_trans --> inactive > nscd_disable_trans --> inactive > ntpd_disable_trans --> inactive > pegasus_disable_trans --> inactive > portmap_disable_trans --> inactive > postgresql_disable_trans --> inactive > pppd_can_insmod --> inactive > pppd_disable_trans --> inactive > pppd_for_user --> inactive > pptp_disable_trans --> inactive > privoxy_disable_trans --> inactive > ptal_disable_trans --> inactive > radiusd_disable_trans --> inactive > radvd_disable_trans --> inactive > read_default_t --> active > rlogind_disable_trans --> inactive > rpcd_disable_trans --> inactive > rsync_disable_trans --> inactive > samba_enable_home_dirs --> inactive > saslauthd_disable_trans --> inactive > slapd_disable_trans --> inactive > smbd_disable_trans --> inactive > snmpd_disable_trans --> inactive > squid_connect_any --> inactive > squid_disable_trans --> inactive > stunnel_disable_trans --> inactive > stunnel_is_daemon --> inactive > syslogd_disable_trans --> inactive > system_dbusd_disable_trans --> inactive > telnetd_disable_trans --> inactive > tftpd_disable_trans --> active > udev_disable_trans --> inactive > use_nfs_home_dirs --> inactive > use_samba_home_dirs --> inactive > uucpd_disable_trans --> inactive > winbind_disable_trans --> inactive > ypbind_disable_trans --> inactive > ypserv_disable_trans --> inactive > zebra_disable_trans --> inactive > > -- > Valery A.Khamenya > -- From khamenya at gmail.com Mon Oct 17 19:56:19 2005 From: khamenya at gmail.com (Valery Khamenya) Date: Mon, 17 Oct 2005 21:56:19 +0200 Subject: FC4, SELinux, virtual hosts, upload web content In-Reply-To: <4353F782.7000603@redhat.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> Message-ID: <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> > Try public_content_rw_t? now tried. Nothing works after applying public_content_rw_t now. Neither ftp, nor scp nor even web. Let me know please if i could bring some reasonable logs. Thank you in advance for any further help, best regards, Valery. P.S. below goes the ... # getsebool -a NetworkManager_disable_trans --> inactive allow_execmem --> active allow_execmod --> active allow_execstack --> active allow_ftpd_anon_write --> inactive allow_gssd_read_tmp --> active allow_httpd_anon_write --> inactive allow_httpd_sys_script_anon_write --> inactive allow_kerberos --> active allow_rsync_anon_write --> inactive allow_saslauthd_read_shadow --> inactive allow_smbd_anon_write --> inactive allow_write_xshm --> inactive allow_ypbind --> inactive apmd_disable_trans --> inactive arpwatch_disable_trans --> inactive auditd_disable_trans --> inactive bluetooth_disable_trans --> inactive canna_disable_trans --> inactive cardmgr_disable_trans --> inactive comsat_disable_trans --> inactive cupsd_config_disable_trans --> inactive cupsd_disable_trans --> inactive cupsd_lpd_disable_trans --> inactive cvs_disable_trans --> inactive cyrus_disable_trans --> inactive dbskkd_disable_trans --> inactive dhcpc_disable_trans --> inactive dhcpd_disable_trans --> inactive dovecot_disable_trans --> inactive fingerd_disable_trans --> inactive ftp_home_dir --> active ftpd_disable_trans --> active ftpd_is_daemon --> active gssd_disable_trans --> inactive hald_disable_trans --> inactive hotplug_disable_trans --> inactive howl_disable_trans --> inactive hplip_disable_trans --> inactive httpd_builtin_scripting --> active httpd_can_network_connect --> inactive httpd_disable_trans --> inactive httpd_enable_cgi --> active httpd_enable_homedirs --> active httpd_ssi_exec --> active httpd_suexec_disable_trans --> inactive httpd_tty_comm --> inactive httpd_unified --> active inetd_child_disable_trans --> inactive inetd_disable_trans --> inactive innd_disable_trans --> inactive kadmind_disable_trans --> inactive klogd_disable_trans --> inactive krb5kdc_disable_trans --> inactive ktalkd_disable_trans --> inactive lpd_disable_trans --> inactive mysqld_disable_trans --> inactive named_disable_trans --> inactive named_write_master_zones --> inactive nfs_export_all_ro --> active nfs_export_all_rw --> active nfsd_disable_trans --> inactive nmbd_disable_trans --> inactive nscd_disable_trans --> inactive ntpd_disable_trans --> inactive pegasus_disable_trans --> inactive portmap_disable_trans --> inactive postgresql_disable_trans --> inactive pppd_can_insmod --> inactive pppd_disable_trans --> inactive pppd_for_user --> inactive pptp_disable_trans --> inactive privoxy_disable_trans --> inactive ptal_disable_trans --> inactive radiusd_disable_trans --> inactive radvd_disable_trans --> inactive read_default_t --> active rlogind_disable_trans --> inactive rpcd_disable_trans --> inactive rsync_disable_trans --> inactive samba_enable_home_dirs --> inactive saslauthd_disable_trans --> inactive slapd_disable_trans --> inactive smbd_disable_trans --> inactive snmpd_disable_trans --> inactive squid_connect_any --> inactive squid_disable_trans --> inactive stunnel_disable_trans --> inactive stunnel_is_daemon --> inactive syslogd_disable_trans --> inactive system_dbusd_disable_trans --> inactive telnetd_disable_trans --> inactive tftpd_disable_trans --> active udev_disable_trans --> inactive use_nfs_home_dirs --> inactive use_samba_home_dirs --> inactive uucpd_disable_trans --> inactive winbind_disable_trans --> inactive ypbind_disable_trans --> inactive ypserv_disable_trans --> inactive zebra_disable_trans --> inactive -- Valery A.Khamenya From khamenya at gmail.com Mon Oct 17 21:16:18 2005 From: khamenya at gmail.com (Valery Khamenya) Date: Mon, 17 Oct 2005 23:16:18 +0200 Subject: FC4, SELinux, virtual hosts, upload web content In-Reply-To: <435409E1.1000107@redhat.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> Message-ID: <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> > you need to turn on the correct booleans to allow it to work. > setsebool -P allow_ftpd_anon_write=1 sounds like anonymous are allowed now by selinux... First funny thing that access was not annymous, so why it was disabled before allow_ftpd_anon_write was changed? Secondly, public_content_rw_t still disallows the apache to access web pages. And if I bring httpd_sys_content_t back then apache is OK and vsftpd doesn't work :) Well, either ftp or apache. But not together now. -- Valery A.Khamenya From dwalsh at redhat.com Mon Oct 17 23:51:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 19:51:53 -0400 Subject: FC4, SELinux, virtual hosts, upload web content In-Reply-To: <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> Message-ID: <43543919.6090105@redhat.com> Valery Khamenya wrote: >> you need to turn on the correct booleans to allow it to work. >> setsebool -P allow_ftpd_anon_write=1 >> > > sounds like anonymous are allowed now by selinux... > > First funny thing that access was not annymous, so why it was disabled > before allow_ftpd_anon_write was changed? > > Secondly, public_content_rw_t still disallows the apache to access web > pages. And if I bring httpd_sys_content_t back then apache is OK and > vsftpd doesn't work :) > > Well, either ftp or apache. But not together now. > > -- > Valery A.Khamenya > You need to set this boolean for each domain that needs the write capability. (httpd, rsync, smbd, ftpd) setsebool -P allow_httpd_anon_write=1 man ftpd_selinux man httpd_selinux ... Should describe the usage -- From mjs at ces.clemson.edu Tue Oct 18 03:30:50 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 17 Oct 2005 23:30:50 -0400 (EDT) Subject: acpid needs to talk to d-bus In-Reply-To: References: <434FFE65.3030702@redhat.com> Message-ID: On Fri, 14 Oct 2005, Matthew Saltzman wrote: > On Fri, 14 Oct 2005, Daniel J Walsh wrote: > >> Matthew Saltzman wrote: >>> The latest Network Manager does some useful things across a suspend/resume >>> cycle, but it relies on a dbus-send signal from the >>> /etc/acpi/actions/sleep script. >>> >>> My script fails to deliver that signal when invoked from acpid in >>> enforcing mode, but it works fine from the command line or in permissive >>> mode. >>> >> What avc messages are you seeing? > > Now that you mention it, it looks like ifdown (called from NetworkManager?) > is the problem: Is this fix in the latest update or Rawhide yet? I'm currently using selinux-policy-targeted-1.27.1-13 from devel. The 1.27.1-17 version in Rawhide requires a new policycoreutils, which seems to require a bunch of other things. Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From jeremy at ardley.org Tue Oct 18 03:50:41 2005 From: jeremy at ardley.org (Jeremy Ardley) Date: Tue, 18 Oct 2005 11:50:41 +0800 Subject: Site Customize? In-Reply-To: <43543919.6090105@redhat.com> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> <43543919.6090105@redhat.com> Message-ID: <43547111.8090300@ardley.org> Hi, I want to customise my site with additional file contexts and rules. Where is the correct place to create the new files contexts so they are specific to my site and not erased by future releases? How do I get them included in the Make? I assume there is some mechanism like domains/misc/local.te but for contexts From paul at city-fan.org Tue Oct 18 07:02:55 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 18 Oct 2005 08:02:55 +0100 Subject: Site Customize? In-Reply-To: <43547111.8090300@ardley.org> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> <43543919.6090105@redhat.com> <43547111.8090300@ardley.org> Message-ID: <1129618975.3668.90.camel@laurel.intra.city-fan.org> On Tue, 2005-10-18 at 11:50 +0800, Jeremy Ardley wrote: > Hi, > > I want to customise my site with additional file contexts and rules. > > Where is the correct place to create the new files contexts so they are > specific to my site and not erased by future releases? How do I get them > included in the Make? > > I assume there is some mechanism like domains/misc/local.te but for contexts Try file_contexts/misc/local.fc Paul. -- Paul Howarth From rhp.lpt at gmail.com Tue Oct 18 07:14:50 2005 From: rhp.lpt at gmail.com (rhp) Date: Tue, 18 Oct 2005 14:14:50 +0700 Subject: seinfo on default umodified policy.conf reports policy syntax error In-Reply-To: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> References: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> Message-ID: 18-oct-05 Hello Stephen: Thank's for the information, it certainly explained my problem. I've upgraded setools and the other elements in the selinux tree as far as I can go on my FC3 system w/o installing glibc-2.3.90.14, (e.g. the latest version of setools, requires 'lib.so.6(GLIBC_2.4)' which it seems first appears in that version of glibc). I've currently got these installed: checkpolicy-1.23.1-1 libselinux-1.23.10-2 libselinux-devel-1.23.10-2 libsepol-1.5.10-1.1 policycoreutils-1.23.10-2 selinux-doc-1.14.1-1 selinux-policy-targeted-sources-1.17.30-3.16 selinux-policy-targeted-1.17.30-3.16 setools-2.1.1-2 setools-gui-2.1.1-2 I'll deal with the glibc issue when I can upgrade to FC4 or FC5. However, it will be awhile as I am not in the States and only have a 38.8k dialup line here. 'seinfo' is working so I hope the remainder or the tools are also and that I can proceed with my persual of SELinux. BTW: 'rpmfind.net' lists glibc-2.3.90.14 as being part of the FC5 tree, is that the tree you are presently working with for development ? Again, many thanks for your help. Brgds Bob On 10/15/05, Stephen Smalley wrote: > On Fri, 2005-10-14 at 13:35 +0700, rhp wrote: > > Problem Summary: > > > > Two FC3 systems running permissive-targeted with identical error messages. > > > > targeted source rpm: selinux-policy-targeted-sources-1.17.30-3.16 > > > > 'seinfo' run on umodified policy.conf reports syntax error in policy. > > You understand that SELinux userspace doesn't get updated in older > Fedora releases except in response to bug reports, right? So you have > an old version of setools that doesn't know about changes in the policy > language that have occurred since FC3 was shipped, and you have a policy > update that uses some of those new language features. > > > 'sestatus' shows policy version 19 but policy files are policy.18 > > Two different pieces of information: > - the first is the maximum binary policy format version supported by the > kernel you are running (FC3 shipped with a kernel that only supported > version 18, but you are running an update kernel that understands a > later version as well - but is fully compatible with the older version), > - the second is the binary policy format version generated by your > checkpolicy, which likely hasn't been updated since FC3 was shipped. > > > 'checkpolicy' errors out on failure to open policy.conf > > If you don't specify a path to a policy.conf file, it looks for it in > the current directory, so it will naturally fail if you aren't in the > policy source directory at that point. > > > Here is a listing of the installed selinux packages on both systems: > > > > selinux-policy-targeted-sources-1.17.30-3.16 > > selinux-policy-strict-1.19.10-2 > > libselinux-1.19.1-8 > > selinux-policy-targeted-1.17.30-3.16 > > libselinux-devel-1.19.1-8 > > selinux-policy-strict-sources-1.19.10-2 > > selinux-doc-1.14.1-1 > > setools-1.4.1-5 > > setools-gui-1.4.1-5 > > checkpolicy-1.17.5-1.2 > > Yes, the userspace tools above are quite old. > > > When running a test of seinfo against the default installation on both systems > > I get this error message: > > > > 'seinfo /etc/selinux/targeted/src/policy/policy.conf' > > > > error in the statement ending on line 3675 (token 'typeattribute'): > > syntax errorerror(s) encountered while parsing configuration (first > > pass, line: 3675) > > error reading policy > > New language statement introduced after FC3 shipped, so the FC3 tools > don't understand it. I'd hazard a guess that the update policy was > built using the latest toolchain rather than the actual ones on FC3. > > > Note the Policy Version is listed as 19. > > That's the highest version supported by your kernel. It retains > backward compatibility with older versions though. > > > However, checking the policy file extents I see they are policy.18: > > > > ls /etc/selinux/targeted/policy/ > > policy.18 > > ls /etc/selinux/strict/policy/ > > policy.18 > > That's the version generated by your checkpolicy. > > > However, checking the contents of the /etc/selinux/targeted/src/policy/VERSION > > and /etc/selinux/strict/src/policy/VERSION files > > I get 1.17 & 1.19 respectively. > > That's the release version of the upstream policy tarball from which the > policy package was built, not related to the binary policy format > version. > > > Additionally, a check of the contents of /selinux/policyvers returns '19'. > > Kernel version. > > > Running 'checkpolicy', 'checkpolicy -c 18', & 'checkpolicy -d -c 18' all > > fail with this error message: > > > > checkpolicy: loading policy configuration from policy.conf > > checkpolicy: unable to open policy.conf > > No policy.conf in your working directory? Specify a path to it > otherwise. > > > running checkpolicy with '-c 19' returns an 'out of range' error message > > Because you have an old checkpolicy that doesn't support that version. > > Note: I'm just explaining - I don't maintain the SELinux packages for > Fedora in any way, just the upstream SELinux. > > -- > Stephen Smalley > National Security Agency > > -- rhp.lpt at gmail.com From work at janburroughs.com Tue Oct 18 11:36:27 2005 From: work at janburroughs.com (work at janburroughs.com) Date: Tue, 18 Oct 2005 07:36:27 -0400 (EDT) Subject: Cron Security Problem Message-ID: <1317.12.217.75.254.1129635387.squirrel@tiia.net> Does anyone know how to resolve this cron error? Oct 18 06:41:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/popmail) Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/loadmysql) Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE (/etc/cron.d/pop-perl) Oct 18 07:01:02 la1 crond[16105]: (root) CMD (run-parts /etc/cron.hourly) From sds at tycho.nsa.gov Tue Oct 18 12:06:09 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 18 Oct 2005 08:06:09 -0400 Subject: Site Customize? In-Reply-To: <43547111.8090300@ardley.org> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> <43543919.6090105@redhat.com> <43547111.8090300@ardley.org> Message-ID: <1129637169.2375.10.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-18 at 11:50 +0800, Jeremy Ardley wrote: > Hi, > > I want to customise my site with additional file contexts and rules. > > Where is the correct place to create the new files contexts so they are > specific to my site and not erased by future releases? How do I get them > included in the Make? > > I assume there is some mechanism like domains/misc/local.te but for contexts /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts.local where $SELINUXTYPE is defined in your /etc/selinux/config (default is targeted). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Oct 18 12:12:06 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 18 Oct 2005 08:12:06 -0400 Subject: Site Customize? In-Reply-To: <1129618975.3668.90.camel@laurel.intra.city-fan.org> References: <84fecab0510160818n75f68252r7ca4d762a7bfe3df@mail.gmail.com> <4353F782.7000603@redhat.com> <84fecab0510171256h6301a0er1f480fee04b1d57b@mail.gmail.com> <435409E1.1000107@redhat.com> <84fecab0510171416s7aa83feeo501141f609c0af@mail.gmail.com> <43543919.6090105@redhat.com> <43547111.8090300@ardley.org> <1129618975.3668.90.camel@laurel.intra.city-fan.org> Message-ID: <1129637526.2375.17.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-18 at 08:02 +0100, Paul Howarth wrote: > On Tue, 2005-10-18 at 11:50 +0800, Jeremy Ardley wrote: > > Hi, > > > > I want to customise my site with additional file contexts and rules. > > > > Where is the correct place to create the new files contexts so they are > > specific to my site and not erased by future releases? How do I get them > > included in the Make? > > > > I assume there is some mechanism like domains/misc/local.te but for contexts > > Try file_contexts/misc/local.fc That would work as well, but requires the policy sources and rebuilding the policy. Better to create a /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts.local file, which is consulted at runtime by the matchpathcon(3) libselinux function used by setfiles, restorecon, etc. And in the future (FC5), you can build your own policy module and module package and link it into the distro-provided policy without disturbing the distro-provided policy at all. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Oct 18 12:19:40 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 18 Oct 2005 08:19:40 -0400 Subject: seinfo on default umodified policy.conf reports policy syntax error In-Reply-To: References: <1129313136.3729.34.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1129637980.2375.25.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-18 at 14:14 +0700, rhp wrote: > 18-oct-05 > > Hello Stephen: > > Thank's for the information, it certainly explained my problem. > > I've upgraded setools and the other elements in the selinux tree as > far as I can go on my FC3 system w/o installing glibc-2.3.90.14, (e.g. > the latest version of setools, requires 'lib.so.6(GLIBC_2.4)' which it > seems first appears in that version of glibc). You could alternatively just build the latest from source on your own system so that they don't pick up a dependency on the newer glibc, either grabbing the rawhide SRPMS or the upstream source tarballs (setools from tresys.com, the core SELinux userland from the sourceforge CVS tree). But if what you have is working, then you may not want to risk moving to the bleeding edge ;) > 'seinfo' is working so I hope the remainder or the tools are also and > that I can proceed with my persual of SELinux. > > BTW: 'rpmfind.net' lists glibc-2.3.90.14 as being part of the FC5 > tree, is that the tree you are presently working with for development > ? Yes, we are working off the development tree aka rawhide which will become FC5. The rough schedule is over at http://fedora.redhat.com/participate/schedule/ -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Oct 18 12:51:46 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 18 Oct 2005 08:51:46 -0400 Subject: acpid needs to talk to d-bus In-Reply-To: References: <434FFE65.3030702@redhat.com> Message-ID: <4354EFE2.30500@redhat.com> Matthew Saltzman wrote: > On Fri, 14 Oct 2005, Matthew Saltzman wrote: > >> On Fri, 14 Oct 2005, Daniel J Walsh wrote: >> >>> Matthew Saltzman wrote: >>>> The latest Network Manager does some useful things across a >>>> suspend/resume cycle, but it relies on a dbus-send signal from the >>>> /etc/acpi/actions/sleep script. >>>> >>>> My script fails to deliver that signal when invoked from acpid in >>>> enforcing mode, but it works fine from the command line or in >>>> permissive mode. >>>> >>> What avc messages are you seeing? >> >> Now that you mention it, it looks like ifdown (called from >> NetworkManager?) is the problem: > > Is this fix in the latest update or Rawhide yet? I'm currently using > selinux-policy-targeted-1.27.1-13 from devel. The 1.27.1-17 version > in Rawhide requires a new policycoreutils, which seems to require a > bunch of other things. > > Thanks. > On FC4 you should be using 1.27.1-2.7 which pretty much matches 1.27.2-17 Dan -- From mjs at ces.clemson.edu Tue Oct 18 14:42:43 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Tue, 18 Oct 2005 10:42:43 -0400 (EDT) Subject: acpid needs to talk to d-bus In-Reply-To: <4354EFE2.30500@redhat.com> References: <434FFE65.3030702@redhat.com> <4354EFE2.30500@redhat.com> Message-ID: On Tue, 18 Oct 2005, Daniel J Walsh wrote: > Matthew Saltzman wrote: >> On Fri, 14 Oct 2005, Matthew Saltzman wrote: >> >>> On Fri, 14 Oct 2005, Daniel J Walsh wrote: >>> >>>> Matthew Saltzman wrote: >>>>> The latest Network Manager does some useful things across a >>>>> suspend/resume cycle, but it relies on a dbus-send signal from the >>>>> /etc/acpi/actions/sleep script. >>>>> >>>>> My script fails to deliver that signal when invoked from acpid in >>>>> enforcing mode, but it works fine from the command line or in permissive >>>>> mode. >>>>> >>>> What avc messages are you seeing? >>> >>> Now that you mention it, it looks like ifdown (called from >>> NetworkManager?) is the problem: >> >> Is this fix in the latest update or Rawhide yet? I'm currently using >> selinux-policy-targeted-1.27.1-13 from devel. The 1.27.1-17 version in >> Rawhide requires a new policycoreutils, which seems to require a bunch of >> other things. >> >> Thanks. >> > On FC4 you should be using > 1.27.1-2.7 which pretty much matches 1.27.2-17 Thanks. I presume that will be in updates-testing shortly? The latest I can find is 1.27.1-2.6. > > Dan > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From ad+lists at uni-x.org Tue Oct 18 21:57:38 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Tue, 18 Oct 2005 23:57:38 +0200 Subject: Cron Security Problem In-Reply-To: <1317.12.217.75.254.1129635387.squirrel@tiia.net> References: <1317.12.217.75.254.1129635387.squirrel@tiia.net> Message-ID: <1129672658.5836.30.camel@serendipity.dogma.lan> Am Di, den 18.10.2005 schrieb work at janburroughs.com um 13:36: > Does anyone know how to resolve this cron error? Wrong list. > Oct 18 06:41:01 la1 crond[4847]: (*system*) BAD FILE MODE > (/etc/cron.d/popmail) > Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE > (/etc/cron.d/loadmysql) > Oct 18 06:42:01 la1 crond[4847]: (*system*) BAD FILE MODE > (/etc/cron.d/pop-perl) > Oct 18 07:01:02 la1 crond[16105]: (root) CMD (run-parts /etc/cron.hourly) Don't put executable script files into /etc/cron.d/. Alexander -- Alexander Dalloz | Enger, Germany | GPG http://pgp.mit.edu 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora Core 2 GNU/Linux on Athlon with kernel 2.6.11-1.35_FC2smp Serendipity 23:56:37 up 5:30, 16 users, 0.82, 0.88, 0.86 -------------- 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 fenn at stanford.edu Wed Oct 19 08:05:02 2005 From: fenn at stanford.edu (Tim Fenn) Date: Wed, 19 Oct 2005 01:05:02 -0700 Subject: mailman cgi-bin denied search Message-ID: <20051019080502.GA804@stanford.edu> I recently installed mailman on my FC3 box (using the redhat based RPMs), and it seems to be working just fine, except for the numerous avc messages it cranks out whenever I run one of the cgi scripts associated with mailman (e.g. via the web interface): Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied { search } for pid=18761 comm="listinfo" name="run" dev=sda1 ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ u:object_r:var_run_t tclass=dir I have selinux-policy-targeted-1.17.30-3.16, and # getsebool httpd_enable_cgi httpd_enable_cgi --> active # getsebool httpd_enable_homedirs httpd_enable_homedirs --> active # getsebool httpd_ssi_exec httpd_ssi_exec --> active # getsebool httpd_builtin_scripting httpd_builtin_scripting --> active # getsebool httpd_unified httpd_unified --> active set, is there something I'm missing? Thanks for any help, Tim From dwalsh at redhat.com Wed Oct 19 13:57:07 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Oct 2005 09:57:07 -0400 Subject: mailman cgi-bin denied search In-Reply-To: <20051019080502.GA804@stanford.edu> References: <20051019080502.GA804@stanford.edu> Message-ID: <435650B3.7020809@redhat.com> Tim Fenn wrote: > I recently installed mailman on my FC3 box (using the redhat based > RPMs), and it seems to be working just fine, except for the numerous > avc messages it cranks out whenever I run one of the cgi scripts > associated with mailman (e.g. via the web interface): > > Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied > { search } for pid=18761 comm="listinfo" name="run" dev=sda1 > ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ > u:object_r:var_run_t tclass=dir > > Why would mailman listinfo be searching /var/log directory? > I have selinux-policy-targeted-1.17.30-3.16, and > > # getsebool httpd_enable_cgi > httpd_enable_cgi --> active > # getsebool httpd_enable_homedirs > httpd_enable_homedirs --> active > # getsebool httpd_ssi_exec > httpd_ssi_exec --> active > # getsebool httpd_builtin_scripting > httpd_builtin_scripting --> active > # getsebool httpd_unified > httpd_unified --> active > > set, is there something I'm missing? > > Thanks for any help, > Tim > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From fenn at stanford.edu Wed Oct 19 20:49:47 2005 From: fenn at stanford.edu (Tim Fenn) Date: Wed, 19 Oct 2005 13:49:47 -0700 Subject: mailman cgi-bin denied search In-Reply-To: <435650B3.7020809@redhat.com> References: <20051019080502.GA804@stanford.edu> <435650B3.7020809@redhat.com> Message-ID: <20051019204947.GC6466@stanford.edu> On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: > Tim Fenn wrote: > >I recently installed mailman on my FC3 box (using the redhat based > >RPMs), and it seems to be working just fine, except for the numerous > >avc messages it cranks out whenever I run one of the cgi scripts > >associated with mailman (e.g. via the web interface): > > > >Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied > >{ search } for pid=18761 comm="listinfo" name="run" dev=sda1 > >ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ > >u:object_r:var_run_t tclass=dir > > > > Why would mailman listinfo be searching /var/log directory? > Well, I get the same errors with mailmanctl: ./mailmanctl status yields no output, and the following errors: Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts ino=5 scontext=root:system_r:mailman_mail_t tcontext=root:object_r:devpts_t tclass=chr_file Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 ino=1294372 scontext=root:system_r:mailman_mail_t tcontext=system_u:object_r:var_run_t tclass=dir Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied { setgid } for pid=20837 comm="mailmanctl" capability=6 scontext=root:system_r:mailman_mail_t tcontext=root:system_r:mailman_mail_t tclass=capability However, if I comment out: from Mailman.Logging.Syslog import syslog in the mailmanctl script, all is well: # ./mailmanctl status mailman (pid 17677) is running... and no error messages. I would assume the same is true with the cgi-bin scripts, such as listinfo. Should I file a bugzilla report? Regards, Tim From wilburn at lanl.gov Wed Oct 19 21:56:06 2005 From: wilburn at lanl.gov (W. Scott wilburn) Date: Wed, 19 Oct 2005 15:56:06 -0600 Subject: Preserving Context with tar Message-ID: <20051019215606.GE4717@wilburn.lanl.gov> Sorry to be asking such a simple question. Is it possible to preserve file contexts using tar? I would have thought -p would do this, but it appears no, atleast on RHEL4 and FC4. The reason to do this is a use tar to install modified config files on new machines. Having to relabel after doing this is somewhat slow. Perhaps there is a better solution? Thanks, Scott Wilburn From dwalsh at redhat.com Thu Oct 20 02:31:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Oct 2005 22:31:36 -0400 Subject: mailman cgi-bin denied search In-Reply-To: <20051019204947.GC6466@stanford.edu> References: <20051019080502.GA804@stanford.edu> <435650B3.7020809@redhat.com> <20051019204947.GC6466@stanford.edu> Message-ID: <43570188.5060201@redhat.com> Tim Fenn wrote: > On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: > >> Tim Fenn wrote: >> >>> I recently installed mailman on my FC3 box (using the redhat based >>> RPMs), and it seems to be working just fine, except for the numerous >>> avc messages it cranks out whenever I run one of the cgi scripts >>> associated with mailman (e.g. via the web interface): >>> >>> Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>> { search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>> ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>> u:object_r:var_run_t tclass=dir >>> >>> >> Why would mailman listinfo be searching /var/log directory? >> >> > > Well, I get the same errors with mailmanctl: > > ./mailmanctl status > > yields no output, and the following errors: > Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied > { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts > ino=5 scontext=root:system_r:mailman_mail_t > tcontext=root:object_r:devpts_t tclass=chr_file > Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied > { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 > ino=1294372 scontext=root:system_r:mailman_mail_t > tcontext=system_u:object_r:var_run_t tclass=dir > Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied > { setgid } for pid=20837 comm="mailmanctl" capability=6 > scontext=root:system_r:mailman_mail_t > tcontext=root:system_r:mailman_mail_t tclass=capability > > However, if I comment out: > > from Mailman.Logging.Syslog import syslog > > in the mailmanctl script, all is well: > > # ./mailmanctl status > mailman (pid 17677) is running... > > and no error messages. I would assume the same is true with the > cgi-bin scripts, such as listinfo. Should I file a bugzilla report? > > Regards, > Tim > Yes. submit a bug. Although generating these in FC4 would be far more interesting. Also do these AVC messages cause problems or are they just being reported. No output from the script is fixed in FC4. -- From dwalsh at redhat.com Thu Oct 20 02:32:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 19 Oct 2005 22:32:13 -0400 Subject: Preserving Context with tar In-Reply-To: <20051019215606.GE4717@wilburn.lanl.gov> References: <20051019215606.GE4717@wilburn.lanl.gov> Message-ID: <435701AD.5030308@redhat.com> W. Scott wilburn wrote: > Sorry to be asking such a simple question. Is it possible to preserve > file contexts using tar? I would have thought -p would do this, but > it appears no, atleast on RHEL4 and FC4. > > The reason to do this is a use tar to install modified config files on > new machines. Having to relabel after doing this is somewhat slow. > Perhaps there is a better solution? > > Thanks, > Have you looked at star? > Scott Wilburn > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From fenn at stanford.edu Thu Oct 20 06:10:21 2005 From: fenn at stanford.edu (Tim Fenn) Date: Wed, 19 Oct 2005 23:10:21 -0700 Subject: mailman cgi-bin denied search In-Reply-To: <43570188.5060201@redhat.com> References: <20051019080502.GA804@stanford.edu> <435650B3.7020809@redhat.com> <20051019204947.GC6466@stanford.edu> <43570188.5060201@redhat.com> Message-ID: <20051020061020.GA26133@stanford.edu> On Wed, Oct 19, 2005 at 10:31:36PM -0400, Daniel J Walsh wrote: > Tim Fenn wrote: > >On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: > > > >>Tim Fenn wrote: > >> > >>>I recently installed mailman on my FC3 box (using the redhat based > >>>RPMs), and it seems to be working just fine, except for the numerous > >>>avc messages it cranks out whenever I run one of the cgi scripts > >>>associated with mailman (e.g. via the web interface): > >>> > >>>Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied > >>>{ search } for pid=18761 comm="listinfo" name="run" dev=sda1 > >>>ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ > >>>u:object_r:var_run_t tclass=dir > >>> > >>> > >>Why would mailman listinfo be searching /var/log directory? > >> > >> > > > >Well, I get the same errors with mailmanctl: > > > >./mailmanctl status > > > >yields no output, and the following errors: > >Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied > >{ read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts > >ino=5 scontext=root:system_r:mailman_mail_t > >tcontext=root:object_r:devpts_t tclass=chr_file > >Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied > >{ search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 > >ino=1294372 scontext=root:system_r:mailman_mail_t > >tcontext=system_u:object_r:var_run_t tclass=dir > >Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied > >{ setgid } for pid=20837 comm="mailmanctl" capability=6 > >scontext=root:system_r:mailman_mail_t > >tcontext=root:system_r:mailman_mail_t tclass=capability > > > >However, if I comment out: > > > >from Mailman.Logging.Syslog import syslog > > > >in the mailmanctl script, all is well: > > > ># ./mailmanctl status > >mailman (pid 17677) is running... > > > >and no error messages. I would assume the same is true with the > >cgi-bin scripts, such as listinfo. Should I file a bugzilla report? > > > >Regards, > >Tim > > > Yes. submit a bug. Although generating these in FC4 would be far more > interesting. Also do these AVC messages cause problems or are they just > being reported. No output from the script is fixed in FC4. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171265 I tested mailman on a FC4 machine, no problems. Seemed to work as expected - no errors. The AVC messages don't prevent mailman from working - I can make lists and so forth (although some scripts, like mailmanctl, don't work), but I haven't done extensive testing... Hope this helps, Tim From sds at tycho.nsa.gov Thu Oct 20 11:57:11 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 20 Oct 2005 07:57:11 -0400 Subject: Preserving Context with tar In-Reply-To: <435701AD.5030308@redhat.com> References: <20051019215606.GE4717@wilburn.lanl.gov> <435701AD.5030308@redhat.com> Message-ID: <1129809431.2375.319.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-10-19 at 22:32 -0400, Daniel J Walsh wrote: > W. Scott wilburn wrote: > > Sorry to be asking such a simple question. Is it possible to preserve > > file contexts using tar? I would have thought -p would do this, but > > it appears no, atleast on RHEL4 and FC4. > > > > The reason to do this is a use tar to install modified config files on > > new machines. Having to relabel after doing this is somewhat slow. > > Perhaps there is a better solution? > > > > Thanks, > > > Have you looked at star? Usage is: # create an archive including xattrs star -xattr -H=exustar -c -f foo.tar # extract the archive, preserving any xattrs in it star -x -f foo.tar rsync also has support for xattr preservation (-X, --xattrs), at least in FC4. An option for GNU tar might be to selectively apply restorecon to the files you are extracting if they are being extracted to the same path on the destination machine as on the source machine and both machines have the same policy, e.g.: tar xvf foo.tar | xargs /sbin/restorecon -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Oct 20 16:01:30 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Oct 2005 12:01:30 -0400 Subject: Preserving Context with tar In-Reply-To: <1129809431.2375.319.camel@moss-spartans.epoch.ncsc.mil> References: <20051019215606.GE4717@wilburn.lanl.gov> <435701AD.5030308@redhat.com> <1129809431.2375.319.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4357BF5A.4000906@redhat.com> Stephen Smalley wrote: > On Wed, 2005-10-19 at 22:32 -0400, Daniel J Walsh wrote: > >> W. Scott wilburn wrote: >> >>> Sorry to be asking such a simple question. Is it possible to preserve >>> file contexts using tar? I would have thought -p would do this, but >>> it appears no, atleast on RHEL4 and FC4. >>> >>> The reason to do this is a use tar to install modified config files on >>> new machines. Having to relabel after doing this is somewhat slow. >>> Perhaps there is a better solution? >>> >>> Thanks, >>> >>> >> Have you looked at star? >> > > Usage is: > # create an archive including xattrs > star -xattr -H=exustar -c -f foo.tar > # extract the archive, preserving any xattrs in it > star -x -f foo.tar > > rsync also has support for xattr preservation (-X, --xattrs), at least > in FC4. > > An option for GNU tar might be to selectively apply restorecon to the > files you are extracting if they are being extracted to the same path on > the destination machine as on the source machine and both machines have > the same policy, e.g.: > tar xvf foo.tar | xargs /sbin/restorecon > > tar xvf foo.tar | /sbin/restorecon -f - Would probably be better -- From dravet at hotmail.com Thu Oct 20 21:19:21 2005 From: dravet at hotmail.com (Jason Dravet) Date: Thu, 20 Oct 2005 16:19:21 -0500 Subject: alot of selinux messages after todays rawhide update Message-ID: After updating my system to todays rawhide I see alot selinux related messages. I am running selinux-policy-targeted-1.27.1-21. I see these messages during boot and shutdown. I did a touch /autorelabel and reboot to see if things got better but they remained the same. The first and third messages (hwclock and fsck) have me concerned the most. Here are the messages: Oct 20 15:52:47 pcjason kernel: audit(1129823524.869:2): avc: denied { use } for pid=417 comm="hwclock" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:hwclock_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:50 pcjason kernel: audit(1129841541.911:3): avc: denied { read } for pid=1164 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841544.332:4): avc: denied { use } for pid=1204 comm="fsck" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841544.660:5): avc: denied { read } for pid=1214 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841544.948:6): avc: denied { read } for pid=1215 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841546.084:7): avc: denied { read } for pid=1257 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841546.456:8): avc: denied { read } for pid=1262 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841546.772:9): avc: denied { use } for pid=1263 comm="swapon" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841551.160:10): avc: denied { read } for pid=1439 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.228:11): avc: denied { read } for pid=1441 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.256:12): avc: denied { read } for pid=1443 comm="iwconfig" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.320:13): avc: denied { read } for pid=1445 comm="ethtool" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.360:14): avc: denied { read } for pid=1448 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.388:15): avc: denied { use } for pid=1449 comm="arping" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841551.392:16): avc: denied { read } for pid=1450 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.424:17): avc: denied { use } for pid=1452 comm="arping" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841551.436:18): avc: denied { read } for pid=1456 comm="ethtool" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.444:19): avc: denied { read } for pid=1458 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.584:20): avc: denied { read } for pid=1470 comm="ifconfig" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.816:21): avc: denied { read } for pid=1508 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.828:22): avc: denied { read } for pid=1511 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.844:23): avc: denied { read } for pid=1514 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.856:24): avc: denied { read } for pid=1516 comm="iwconfig" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.868:25): avc: denied { read } for pid=1518 comm="ethtool" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.884:26): avc: denied { read } for pid=1521 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841551.892:27): avc: denied { use } for pid=1522 comm="arping" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841553.480:28): avc: denied { use } for pid=1523 comm="arping" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:51 pcjason kernel: audit(1129841555.920:29): avc: denied { read } for pid=1524 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841555.932:30): avc: denied { read } for pid=1526 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:51 pcjason kernel: audit(1129841555.936:31): avc: denied { use } for pid=1527 comm="arping" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:netutils_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:52 pcjason kernel: audit(1129841555.960:32): avc: denied { read } for pid=1532 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:52 pcjason kernel: audit(1129841555.968:33): avc: denied { read } for pid=1533 comm="ethtool" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:52 pcjason kernel: audit(1129841555.976:34): avc: denied { read } for pid=1535 comm="ip" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:52 pcjason kernel: audit(1129841556.048:35): avc: denied { read } for pid=1546 comm="ifconfig" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Oct 20 15:52:52 pcjason kernel: audit(1129841556.308:36): avc: denied { use } for pid=1563 comm="syslogd" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:52 pcjason kernel: audit(1129841556.444:37): avc: denied { use } for pid=1566 comm="klogd" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:52 pcjason kernel: audit(1129841556.748:38): avc: denied { use } for pid=1583 comm="portmap" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:portmap_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Oct 20 15:52:52 pcjason kernel: audit(1129841557.492:39): avc: denied { use } for pid=1592 comm="auditd" name="VolGroup00-LogVol01" dev=tmpfs ino=760 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd Thanks, Jason From jayendren at hivsa.com Fri Oct 21 10:10:46 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Fri, 21 Oct 2005 12:10:46 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <20051020160014.31DF97407D@hormel.redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> Message-ID: <4358BEA6.3010602@hivsa.com> Greetings fellow travellers. Could someone please help me with the following errors: *audit(1129788324.500:0): avc: denied { execute } for pid=3105 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.501:0): avc: denied { execute } for pid=3106 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.507:0): avc: denied { execute } for pid=3107 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.510:0): avc: denied { execute } for pid=3108 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.514:0): avc: denied { execute } for pid=3109 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.517:0): avc: denied { execute } for pid=3110 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.521:0): avc: denied { execute } for pid=3111 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.522:0): avc: denied { execute } for pid=3112 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.528:0): avc: denied { execute } for pid=3113 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file audit(1129788324.529:0): avc: denied { execute } for pid=3114 exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t t context=root:object_r:usr_t tclass=file* These errors are from dmesg, and occured after compiling and installing squidclam from source. Here is the output of selinuxconf: [*root at shiva jay]# selinuxconfig selinux state="enforcing" policypath="/etc/selinux/targeted" default_type_path="/etc/selinux/targeted/contexts/default_type" default_context_path="/etc/selinux/targeted/contexts/default_contexts" default_failsafe_context_path="/etc/selinux/targeted/contexts/failsafe_context" binary_policy_path="/etc/selinux/targeted/policy/policy" user_contexts_path="/etc/selinux/targeted/contexts/users/" contexts_path="/etc/selinux/targeted/contexts"* Output of uname -a: *[root at shiva jay]# uname -a Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 i686 i386 GNU/Linux* Any help would be greatly appreciated. God bless. fedora-selinux-list-request at redhat.com wrote: >Send fedora-selinux-list mailing list submissions to > fedora-selinux-list at redhat.com > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/fedora-selinux-list >or, via email, send a message with subject or body 'help' to > fedora-selinux-list-request at redhat.com > >You can reach the person managing the list at > fedora-selinux-list-owner at redhat.com > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of fedora-selinux-list digest..." > > >Today's Topics: > > 1. Re: mailman cgi-bin denied search (Tim Fenn) > 2. Preserving Context with tar (W. Scott wilburn) > 3. Re: mailman cgi-bin denied search (Daniel J Walsh) > 4. Re: Preserving Context with tar (Daniel J Walsh) > 5. Re: mailman cgi-bin denied search (Tim Fenn) > 6. Re: Preserving Context with tar (Stephen Smalley) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Wed, 19 Oct 2005 13:49:47 -0700 >From: Tim Fenn >Subject: Re: mailman cgi-bin denied search >To: Daniel J Walsh >Cc: fedora-selinux-list at redhat.com >Message-ID: <20051019204947.GC6466 at stanford.edu> >Content-Type: text/plain; charset=us-ascii > >On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: > > >>Tim Fenn wrote: >> >> >>>I recently installed mailman on my FC3 box (using the redhat based >>>RPMs), and it seems to be working just fine, except for the numerous >>>avc messages it cranks out whenever I run one of the cgi scripts >>>associated with mailman (e.g. via the web interface): >>> >>>Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>>{ search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>u:object_r:var_run_t tclass=dir >>> >>> >>> >>Why would mailman listinfo be searching /var/log directory? >> >> >> > >Well, I get the same errors with mailmanctl: > >./mailmanctl status > >yields no output, and the following errors: >Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >{ read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >ino=5 scontext=root:system_r:mailman_mail_t >tcontext=root:object_r:devpts_t tclass=chr_file >Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >{ search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >ino=1294372 scontext=root:system_r:mailman_mail_t >tcontext=system_u:object_r:var_run_t tclass=dir >Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >{ setgid } for pid=20837 comm="mailmanctl" capability=6 >scontext=root:system_r:mailman_mail_t >tcontext=root:system_r:mailman_mail_t tclass=capability > >However, if I comment out: > >from Mailman.Logging.Syslog import syslog > >in the mailmanctl script, all is well: > ># ./mailmanctl status >mailman (pid 17677) is running... > >and no error messages. I would assume the same is true with the >cgi-bin scripts, such as listinfo. Should I file a bugzilla report? > >Regards, >Tim > > > >------------------------------ > >Message: 2 >Date: Wed, 19 Oct 2005 15:56:06 -0600 >From: "W. Scott wilburn" >Subject: Preserving Context with tar >To: fedora-selinux-list at redhat.com >Message-ID: <20051019215606.GE4717 at wilburn.lanl.gov> >Content-Type: text/plain; charset=us-ascii > >Sorry to be asking such a simple question. Is it possible to preserve >file contexts using tar? I would have thought -p would do this, but >it appears no, atleast on RHEL4 and FC4. > >The reason to do this is a use tar to install modified config files on >new machines. Having to relabel after doing this is somewhat slow. >Perhaps there is a better solution? > >Thanks, >Scott Wilburn > > > >------------------------------ > >Message: 3 >Date: Wed, 19 Oct 2005 22:31:36 -0400 >From: Daniel J Walsh >Subject: Re: mailman cgi-bin denied search >To: Daniel J Walsh , fedora-selinux-list at redhat.com >Message-ID: <43570188.5060201 at redhat.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Tim Fenn wrote: > > >>On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: >> >> >> >>>Tim Fenn wrote: >>> >>> >>> >>>>I recently installed mailman on my FC3 box (using the redhat based >>>>RPMs), and it seems to be working just fine, except for the numerous >>>>avc messages it cranks out whenever I run one of the cgi scripts >>>>associated with mailman (e.g. via the web interface): >>>> >>>>Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>>>{ search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>>ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>>u:object_r:var_run_t tclass=dir >>>> >>>> >>>> >>>> >>>Why would mailman listinfo be searching /var/log directory? >>> >>> >>> >>> >>Well, I get the same errors with mailmanctl: >> >>./mailmanctl status >> >>yields no output, and the following errors: >>Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >>{ read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >>ino=5 scontext=root:system_r:mailman_mail_t >>tcontext=root:object_r:devpts_t tclass=chr_file >>Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >>{ search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >>ino=1294372 scontext=root:system_r:mailman_mail_t >>tcontext=system_u:object_r:var_run_t tclass=dir >>Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >>{ setgid } for pid=20837 comm="mailmanctl" capability=6 >>scontext=root:system_r:mailman_mail_t >>tcontext=root:system_r:mailman_mail_t tclass=capability >> >>However, if I comment out: >> >>from Mailman.Logging.Syslog import syslog >> >>in the mailmanctl script, all is well: >> >># ./mailmanctl status >>mailman (pid 17677) is running... >> >>and no error messages. I would assume the same is true with the >>cgi-bin scripts, such as listinfo. Should I file a bugzilla report? >> >>Regards, >>Tim >> >> >> >Yes. submit a bug. Although generating these in FC4 would be far more >interesting. Also do these AVC messages cause problems or are they just >being reported. No output from the script is fixed in FC4. > > > > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Fri Oct 21 11:56:34 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 21 Oct 2005 07:56:34 -0400 Subject: alot of selinux messages after todays rawhide update In-Reply-To: References: Message-ID: <1129895794.2375.546.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-10-20 at 16:19 -0500, Jason Dravet wrote: > After updating my system to todays rawhide I see alot selinux related > messages. I am running selinux-policy-targeted-1.27.1-21. I see these > messages during boot and shutdown. I did a touch /autorelabel and reboot to > see if things got better but they remained the same. The first and third > messages (hwclock and fsck) have me concerned the most. Here are the > messages: > > Oct 20 15:52:47 pcjason kernel: audit(1129823524.869:2): avc: denied { use > } for pid=417 comm="hwclock" name="VolGroup00-LogVol01" dev=tmpfs ino=760 > scontext=system_u:system_r:hwclock_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > > Oct 20 15:52:50 pcjason kernel: audit(1129841541.911:3): avc: denied { > read } for pid=1164 comm="restorecon" name="VolGroup00-LogVol01" dev=tmpfs > ino=760 scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file This means that the kernel (or early userspace prior to initial policy load) is leaking a descriptor to that device to all descendants. SELinux is then correctly denying access to the descriptor and device and closing it on each domain transition. Someone needs to track down the offending entity that is leaking the descriptor and fix it. In the absence of SELinux, this kind of bug would likely never be noticed (unless some program tried using the inherited descriptor for some reason). -- Stephen Smalley National Security Agency From csellers at tresys.com Fri Oct 21 13:07:25 2005 From: csellers at tresys.com (Chad Sellers) Date: Fri, 21 Oct 2005 09:07:25 -0400 Subject: [RFC} sectioned package format Message-ID: Currently, module package files store policy modules and their corresponding file_contexts in a format that is not extensible. Eventually, we would like to be able to add other components to the package (e.g. default_contexts), or modify the package file format. This was discussed on fedora-selinux-list a few days ago. To accomplish this, we are proposing the following simple module package file format. Policy Package Header The package begins with the package header. This contains the following fields: uint32_t magic_number; uint32_t package_file_version; uint32_t num_sections; uint32_t section_offset; ... uint32_t is a 4-byte datum stored in little-endian format. magic_number identifies the file as a module package, and has a value of 0xf97c668f. package_file_version identifies the version of the package file, and this first version will be 1. num_sections gives the total number of sections in this file, which is also the number of section_offset entries that follow. section_offset identifies the offset in bytes from the beginning of the file to the beginning of the section. These sections are always listed in sequence, so the length of a given section is the difference between its offset and the following offset, except the final section which ends with the end of the file. Sections Sections are generic areas for data from the package perspective. They are identified by a magic number at the beginning of the section, just as current policy modules begin with a magic number. We will add a magic number to the top of the file_contexts section as well to identify it. Different kinds of sections can be added later simply by assigning them a new magic number. Please let us know what you think of this format, and if you see any problems with it. Thanks, Chad Sellers ---------------------- Chad Sellers Tresys Technology, LLC csellers at tresys.com (410)290-1411 x117 http://www.tresys.com From dravet at hotmail.com Fri Oct 21 13:41:18 2005 From: dravet at hotmail.com (Jason Dravet) Date: Fri, 21 Oct 2005 08:41:18 -0500 Subject: alot of selinux messages after todays rawhide update In-Reply-To: <1129895794.2375.546.camel@moss-spartans.epoch.ncsc.mil> Message-ID: >From: Stephen Smalley >To: Jason Dravet >CC: James Morris , fedora-selinux-list at redhat.com >Subject: Re: alot of selinux messages after todays rawhide update >Date: Fri, 21 Oct 2005 07:56:34 -0400 > >On Thu, 2005-10-20 at 16:19 -0500, Jason Dravet wrote: > > After updating my system to todays rawhide I see alot selinux related > > messages. I am running selinux-policy-targeted-1.27.1-21. I see these > > messages during boot and shutdown. I did a touch /autorelabel and >reboot to > > see if things got better but they remained the same. The first and >third > > messages (hwclock and fsck) have me concerned the most. Here are the > > messages: > > > > Oct 20 15:52:47 pcjason kernel: audit(1129823524.869:2): avc: denied { >use > > } for pid=417 comm="hwclock" name="VolGroup00-LogVol01" dev=tmpfs >ino=760 > > scontext=system_u:system_r:hwclock_t:s0 > > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > > > > Oct 20 15:52:50 pcjason kernel: audit(1129841541.911:3): avc: denied { > > read } for pid=1164 comm="restorecon" name="VolGroup00-LogVol01" >dev=tmpfs > > ino=760 scontext=system_u:system_r:restorecon_t:s0 > > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > >This means that the kernel (or early userspace prior to initial policy >load) is leaking a descriptor to that device to all descendants. >SELinux is then correctly denying access to the descriptor and device >and closing it on each domain transition. Someone needs to track down >the offending entity that is leaking the descriptor and fix it. In the >absence of SELinux, this kind of bug would likely never be noticed >(unless some program tried using the inherited descriptor for some >reason). > >-- >Stephen Smalley >National Security Agency > Thank you for the information. It was informative. How do you suggest one track down the offending process? Please keep in mind I am not a kernel programmer, but I would like to help if I can. Should I open a bugzilla entry? If so what package should these messages be reported too? Thanks, Jason Dravet From sds at tycho.nsa.gov Fri Oct 21 14:06:22 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 21 Oct 2005 10:06:22 -0400 Subject: alot of selinux messages after todays rawhide update In-Reply-To: References: Message-ID: <1129903582.27663.10.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-10-21 at 08:41 -0500, Jason Dravet wrote: > Thank you for the information. It was informative. How do you suggest one > track down the offending process? Please keep in mind I am not a kernel > programmer, but I would like to help if I can. Should I open a bugzilla > entry? If so what package should these messages be reported too? You could add a comment to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165912 with your audit messages, kernel info, etc. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Oct 21 16:43:38 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 21 Oct 2005 12:43:38 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <4358BEA6.3010602@hivsa.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> Message-ID: <43591ABA.3070207@redhat.com> Jayendren Anand Maduray wrote: > Greetings fellow travellers. > I would start by trying something like chcon -t bin_t *`which squidclamav` Btw where does squidclamav reside? * > > Could someone please help me with the following errors: > > *audit(1129788324.500:0): avc: denied { execute } for pid=3105 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.501:0): avc: denied { execute } for pid=3106 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.507:0): avc: denied { execute } for pid=3107 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.510:0): avc: denied { execute } for pid=3108 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.514:0): avc: denied { execute } for pid=3109 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.517:0): avc: denied { execute } for pid=3110 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.521:0): avc: denied { execute } for pid=3111 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.522:0): avc: denied { execute } for pid=3112 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.528:0): avc: denied { execute } for pid=3113 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file > audit(1129788324.529:0): avc: denied { execute } for pid=3114 > exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 > scontext=user_u:system_r:squid_t t > context=root:object_r:usr_t tclass=file* > > > These errors are from dmesg, and occured after compiling and > installing squidclam from source. > > Here is the output of selinuxconf: > > [*root at shiva jay]# selinuxconfig > selinux state="enforcing" > policypath="/etc/selinux/targeted" > default_type_path="/etc/selinux/targeted/contexts/default_type" > default_context_path="/etc/selinux/targeted/contexts/default_contexts" > default_failsafe_context_path="/etc/selinux/targeted/contexts/failsafe_context" > binary_policy_path="/etc/selinux/targeted/policy/policy" > user_contexts_path="/etc/selinux/targeted/contexts/users/" > contexts_path="/etc/selinux/targeted/contexts"* > > Output of uname -a: > *[root at shiva jay]# uname -a > Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 > i686 i386 GNU/Linux* > > Any help would be greatly appreciated. > > God bless. > > > fedora-selinux-list-request at redhat.com wrote: >> Send fedora-selinux-list mailing list submissions to >> fedora-selinux-list at redhat.com >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> or, via email, send a message with subject or body 'help' to >> fedora-selinux-list-request at redhat.com >> >> You can reach the person managing the list at >> fedora-selinux-list-owner at redhat.com >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of fedora-selinux-list digest..." >> >> >> Today's Topics: >> >> 1. Re: mailman cgi-bin denied search (Tim Fenn) >> 2. Preserving Context with tar (W. Scott wilburn) >> 3. Re: mailman cgi-bin denied search (Daniel J Walsh) >> 4. Re: Preserving Context with tar (Daniel J Walsh) >> 5. Re: mailman cgi-bin denied search (Tim Fenn) >> 6. Re: Preserving Context with tar (Stephen Smalley) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 19 Oct 2005 13:49:47 -0700 >> From: Tim Fenn >> Subject: Re: mailman cgi-bin denied search >> To: Daniel J Walsh >> Cc: fedora-selinux-list at redhat.com >> Message-ID: <20051019204947.GC6466 at stanford.edu> >> Content-Type: text/plain; charset=us-ascii >> >> On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: >> >>> Tim Fenn wrote: >>> >>>> I recently installed mailman on my FC3 box (using the redhat based >>>> RPMs), and it seems to be working just fine, except for the numerous >>>> avc messages it cranks out whenever I run one of the cgi scripts >>>> associated with mailman (e.g. via the web interface): >>>> >>>> Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>>> { search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>> ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>> u:object_r:var_run_t tclass=dir >>>> >>>> >>> Why would mailman listinfo be searching /var/log directory? >>> >>> >> >> Well, I get the same errors with mailmanctl: >> >> ./mailmanctl status >> >> yields no output, and the following errors: >> Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >> { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >> ino=5 scontext=root:system_r:mailman_mail_t >> tcontext=root:object_r:devpts_t tclass=chr_file >> Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >> { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >> ino=1294372 scontext=root:system_r:mailman_mail_t >> tcontext=system_u:object_r:var_run_t tclass=dir >> Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >> { setgid } for pid=20837 comm="mailmanctl" capability=6 >> scontext=root:system_r:mailman_mail_t >> tcontext=root:system_r:mailman_mail_t tclass=capability >> >> However, if I comment out: >> >> from Mailman.Logging.Syslog import syslog >> >> in the mailmanctl script, all is well: >> >> # ./mailmanctl status >> mailman (pid 17677) is running... >> >> and no error messages. I would assume the same is true with the >> cgi-bin scripts, such as listinfo. Should I file a bugzilla report? >> >> Regards, >> Tim >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 19 Oct 2005 15:56:06 -0600 >> From: "W. Scott wilburn" >> Subject: Preserving Context with tar >> To: fedora-selinux-list at redhat.com >> Message-ID: <20051019215606.GE4717 at wilburn.lanl.gov> >> Content-Type: text/plain; charset=us-ascii >> >> Sorry to be asking such a simple question. Is it possible to preserve >> file contexts using tar? I would have thought -p would do this, but >> it appears no, atleast on RHEL4 and FC4. >> >> The reason to do this is a use tar to install modified config files on >> new machines. Having to relabel after doing this is somewhat slow. >> Perhaps there is a better solution? >> >> Thanks, >> Scott Wilburn >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 19 Oct 2005 22:31:36 -0400 >> From: Daniel J Walsh >> Subject: Re: mailman cgi-bin denied search >> To: Daniel J Walsh , fedora-selinux-list at redhat.com >> Message-ID: <43570188.5060201 at redhat.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Tim Fenn wrote: >> >>> On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: >>> >>> >>>> Tim Fenn wrote: >>>> >>>> >>>>> I recently installed mailman on my FC3 box (using the redhat based >>>>> RPMs), and it seems to be working just fine, except for the numerous >>>>> avc messages it cranks out whenever I run one of the cgi scripts >>>>> associated with mailman (e.g. via the web interface): >>>>> >>>>> Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>>>> { search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>>> ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>>> u:object_r:var_run_t tclass=dir >>>>> >>>>> >>>>> >>>> Why would mailman listinfo be searching /var/log directory? >>>> >>>> >>>> >>> Well, I get the same errors with mailmanctl: >>> >>> ./mailmanctl status >>> >>> yields no output, and the following errors: >>> Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >>> { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >>> ino=5 scontext=root:system_r:mailman_mail_t >>> tcontext=root:object_r:devpts_t tclass=chr_file >>> Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >>> { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >>> ino=1294372 scontext=root:system_r:mailman_mail_t >>> tcontext=system_u:object_r:var_run_t tclass=dir >>> Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >>> { setgid } for pid=20837 comm="mailmanctl" capability=6 >>> scontext=root:system_r:mailman_mail_t >>> tcontext=root:system_r:mailman_mail_t tclass=capability >>> >>> However, if I comment out: >>> >>> from Mailman.Logging.Syslog import syslog >>> >>> in the mailmanctl script, all is well: >>> >>> # ./mailmanctl status >>> mailman (pid 17677) is running... >>> >>> and no error messages. I would assume the same is true with the >>> cgi-bin scripts, such as listinfo. Should I file a bugzilla report? >>> >>> Regards, >>> Tim >>> >>> >> Yes. submit a bug. Although generating these in FC4 would be far more >> interesting. Also do these AVC messages cause problems or are they just >> being reported. No output from the script is fixed in FC4. >> >> >> >> > > -- > Jayendren Anand Maduray > Microsoft Certified Professional > Network Plus > IT Administrator > > Perinatal HIV Research Unit > Old Potch Road > Chris Hani Baragwanath Hospital > Soweto > South Africa > > Tel: +27 11 989 9776 > Tel: +27 11 989 9999 > Fax: +27 11 938 3973 > Cel: 082 22 774 94 > > Alternate email address: jayendren at mweb.co.za > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dravet at hotmail.com Fri Oct 21 18:53:00 2005 From: dravet at hotmail.com (Jason Dravet) Date: Fri, 21 Oct 2005 13:53:00 -0500 Subject: alot of selinux messages after todays rawhide update In-Reply-To: <1129903582.27663.10.camel@moss-spartans.epoch.ncsc.mil> Message-ID: >From: Stephen Smalley >To: Jason Dravet >CC: jmorris at namei.org, fedora-selinux-list at redhat.com >Subject: Re: alot of selinux messages after todays rawhide update >Date: Fri, 21 Oct 2005 10:06:22 -0400 > >On Fri, 2005-10-21 at 08:41 -0500, Jason Dravet wrote: > > Thank you for the information. It was informative. How do you suggest >one > > track down the offending process? Please keep in mind I am not a kernel > > programmer, but I would like to help if I can. Should I open a bugzilla > > entry? If so what package should these messages be reported too? > >You could add a comment to >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165912 >with your audit messages, kernel info, etc. > >-- >Stephen Smalley >National Security Agency > Thank you, I did add a comment and the audit messages. Thanks again, Jason From mjs at ces.clemson.edu Sat Oct 22 17:14:01 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sat, 22 Oct 2005 13:14:01 -0400 (EDT) Subject: Still issues with SElinux, NetworkManager, and ACPI suspend Message-ID: Recent versions of NetworkManager use dbus signals to control actions related to suspend/resume (among others). In enforcing mode, using selinux-policy-targeted-1.27.1-2.7. The suspend script runs without error when executed from the command line, but produces these errors when invoked by pressing the suspend key. On suspend, /var/log/debug reports: Oct 22 12:59:14 vincent52 dbus: Can't send to audit system: USER_AVC pid=2180 uid=81 loginuid=-1 message=avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.NetworkManager member=sleep dest=org.freedesktop.NetworkManager spid=31524 tpid=2239 scontext=system_u:system_r:apmd_t tcontext=system_u:system_r:NetworkManager_t tclass=dbus On resume, /var/log/debug reports: Oct 22 12:59:39 vincent52 dbus: Can't send to audit system: USER_AVC pid=2180 uid=81 loginuid=-1 message=avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.NetworkManager member=wake dest=org.freedesktop.NetworkManager spid=31542 tpid=2239 scontext=system_u:system_r:apmd_t tcontext=system_u:system_r:NetworkManager_t tclass=dbus No messages appear in /var/log/audit/audit.log. The relevant section of the suspend script is: /usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager \ --type=method_call /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.sleep sync echo -n "mem" > /sys/power/state /usr/bin/dbus-send --system --dest=org.freedesktop.NetworkManager \ --type=method_call /org/freedesktop/NetworkManager \ org.freedesktop.NetworkManager.wake Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From mjs at ces.clemson.edu Sat Oct 22 17:18:26 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Sat, 22 Oct 2005 13:18:26 -0400 (EDT) Subject: Rotate audit log? Message-ID: Is there a reason not to include /var/log/audit/audit.log in the logrotate regime? If not, what would need to go in a logrotate script to get selinux to start a new log file? Thanks. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From goeran at uddeborg.se Sat Oct 22 19:25:07 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Sat, 22 Oct 2005 21:25:07 +0200 Subject: Exporting NTFS filesystems over NFS Message-ID: <17242.37395.490964.418390@freddi.uddeborg.se> The policy apparently does not allow exporting an NTFS filesystem over NFS. I can't see any obvious reason for this choice, but maybe there is something I miss. Is this intentional, or is it a mistake? Or in other words, should I bugzilla or only figure out how to change it for myself? The error message I get trying to export an NTFS fileystem is included below. (If I go into permissive mode everything works as expected.) type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir type=SYSCALL msg=audit(1130008471.475:403): arch=40000003 syscall=196 success=no exit=-13 a0=ffffb80b a1=ffffb76c a2=f7fc2ff4 a3=8052712 items=1 pid=9034 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="exportfs" exe="/usr/sbin/exportfs" type=AVC_PATH msg=audit(1130008471.475:403): path="/mnt/remote/teddi" type=CWD msg=audit(1130008471.475:403): cwd="/etc/selinux/strict/contexts/users" type=PATH msg=audit(1130008471.475:403): item=0 name="/mnt/remote/teddi" flags=0 inode=5 dev=08:01 mode=040555 ouid=0 ogid=0 rdev=00:00 From tdiehl at rogueind.com Sun Oct 23 18:51:57 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 23 Oct 2005 14:51:57 -0400 (EDT) Subject: AVC message problem Message-ID: Hi all, Since upgrading to EL4-U2 I am getting the following avc messages in my logs: Oct 23 14:46:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus Can someone tell me how to go about fixing this, short of turning off selinux? (pocono pts13) # rpm -qa | grep selinux libselinux-1.19.1-7 libselinux-1.19.1-7 selinux-policy-targeted-1.17.30-2.110 libselinux-devel-1.19.1-7 (pocono pts13) # rpm -qa dbus dbus-0.22-12.EL.5 (pocono pts13) # uname -r 2.6.9-22.ELsmp (pocono pts13) # I get hundreds of these a day. I have tried relabeling but no change. The system arch is x86_64 Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From jayendren at hivsa.com Mon Oct 24 06:24:31 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Mon, 24 Oct 2005 08:24:31 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <43591ABA.3070207@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> Message-ID: <435C7E1F.8060009@hivsa.com> Thank for your response, i really appreciate it. Squid clam binary is located in: /usr/local/squidclamav/bin I isssue: [root at shiva jay]# chcon -t bin_t *`which /usr/local/squidclamav/bin/` and get error: /usr/bin/which: no in (/usr/local/squidclamav/bin) Then i try: chcon -t bin_t *`/usr/local/squidclamav/bin/squidclamav` SquidClamav running as UID 0: writing logs to stderr Mon Oct 24 08:23:18 2005:Reading Patterns from config /usr/local/squidclamav/etc/squidclamav.conf Mon Oct 24 08:23:18 2005:SquidClamav (PID 4550) started Does the original error mean the SELinux has not been configured to allow squidclamav? Last nite i ran a touch /.autorelabel which relabelled my system, still the same problem. I have disabled SELinux support for squid, so at least squid is working now. God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> Greetings fellow travellers. >> > I would start by trying something like > chcon -t bin_t *`which squidclamav` > Btw where does squidclamav reside? > > * > >> >> Could someone please help me with the following errors: >> >> *audit(1129788324.500:0): avc: denied { execute } for pid=3105 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.501:0): avc: denied { execute } for pid=3106 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.507:0): avc: denied { execute } for pid=3107 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.510:0): avc: denied { execute } for pid=3108 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.514:0): avc: denied { execute } for pid=3109 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.517:0): avc: denied { execute } for pid=3110 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.521:0): avc: denied { execute } for pid=3111 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.522:0): avc: denied { execute } for pid=3112 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.528:0): avc: denied { execute } for pid=3113 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file >> audit(1129788324.529:0): avc: denied { execute } for pid=3114 >> exe=/usr/sbin/squid name=squidclamav dev=hda8 ino=185872 >> scontext=user_u:system_r:squid_t t >> context=root:object_r:usr_t tclass=file* >> >> >> These errors are from dmesg, and occured after compiling and >> installing squidclam from source. >> >> Here is the output of selinuxconf: >> >> [*root at shiva jay]# selinuxconfig >> selinux state="enforcing" >> policypath="/etc/selinux/targeted" >> default_type_path="/etc/selinux/targeted/contexts/default_type" >> default_context_path="/etc/selinux/targeted/contexts/default_contexts" >> default_failsafe_context_path="/etc/selinux/targeted/contexts/failsafe_context" >> >> binary_policy_path="/etc/selinux/targeted/policy/policy" >> user_contexts_path="/etc/selinux/targeted/contexts/users/" >> contexts_path="/etc/selinux/targeted/contexts"* >> >> Output of uname -a: >> *[root at shiva jay]# uname -a >> Linux shiva 2.6.9-1.667smp #1 SMP Tue Nov 2 14:59:52 EST 2004 i686 >> i686 i386 GNU/Linux* >> >> Any help would be greatly appreciated. >> >> God bless. >> >> >> fedora-selinux-list-request at redhat.com wrote: >> >>> Send fedora-selinux-list mailing list submissions to >>> fedora-selinux-list at redhat.com >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> or, via email, send a message with subject or body 'help' to >>> fedora-selinux-list-request at redhat.com >>> >>> You can reach the person managing the list at >>> fedora-selinux-list-owner at redhat.com >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of fedora-selinux-list digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: mailman cgi-bin denied search (Tim Fenn) >>> 2. Preserving Context with tar (W. Scott wilburn) >>> 3. Re: mailman cgi-bin denied search (Daniel J Walsh) >>> 4. Re: Preserving Context with tar (Daniel J Walsh) >>> 5. Re: mailman cgi-bin denied search (Tim Fenn) >>> 6. Re: Preserving Context with tar (Stephen Smalley) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Wed, 19 Oct 2005 13:49:47 -0700 >>> From: Tim Fenn >>> Subject: Re: mailman cgi-bin denied search >>> To: Daniel J Walsh >>> Cc: fedora-selinux-list at redhat.com >>> Message-ID: <20051019204947.GC6466 at stanford.edu> >>> Content-Type: text/plain; charset=us-ascii >>> >>> On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: >>> >>> >>>> Tim Fenn wrote: >>>> >>>> >>>>> I recently installed mailman on my FC3 box (using the redhat based >>>>> RPMs), and it seems to be working just fine, except for the numerous >>>>> avc messages it cranks out whenever I run one of the cgi scripts >>>>> associated with mailman (e.g. via the web interface): >>>>> >>>>> Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: denied >>>>> { search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>>> ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>>> u:object_r:var_run_t tclass=dir >>>>> >>>>> >>>> >>>> Why would mailman listinfo be searching /var/log directory? >>>> >>>> >>> >>> >>> Well, I get the same errors with mailmanctl: >>> >>> ./mailmanctl status >>> >>> yields no output, and the following errors: >>> Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >>> { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >>> ino=5 scontext=root:system_r:mailman_mail_t >>> tcontext=root:object_r:devpts_t tclass=chr_file >>> Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >>> { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >>> ino=1294372 scontext=root:system_r:mailman_mail_t >>> tcontext=system_u:object_r:var_run_t tclass=dir >>> Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >>> { setgid } for pid=20837 comm="mailmanctl" capability=6 >>> scontext=root:system_r:mailman_mail_t >>> tcontext=root:system_r:mailman_mail_t tclass=capability >>> >>> However, if I comment out: >>> >>> from Mailman.Logging.Syslog import syslog >>> >>> in the mailmanctl script, all is well: >>> >>> # ./mailmanctl status >>> mailman (pid 17677) is running... >>> >>> and no error messages. I would assume the same is true with the >>> cgi-bin scripts, such as listinfo. Should I file a bugzilla report? >>> >>> Regards, >>> Tim >>> >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Wed, 19 Oct 2005 15:56:06 -0600 >>> From: "W. Scott wilburn" >>> Subject: Preserving Context with tar >>> To: fedora-selinux-list at redhat.com >>> Message-ID: <20051019215606.GE4717 at wilburn.lanl.gov> >>> Content-Type: text/plain; charset=us-ascii >>> >>> Sorry to be asking such a simple question. Is it possible to >>> preserve file contexts using tar? I would have thought -p would do >>> this, but it appears no, atleast on RHEL4 and FC4. >>> >>> The reason to do this is a use tar to install modified config files >>> on new machines. Having to relabel after doing this is somewhat >>> slow. Perhaps there is a better solution? >>> >>> Thanks, >>> Scott Wilburn >>> >>> >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Wed, 19 Oct 2005 22:31:36 -0400 >>> From: Daniel J Walsh >>> Subject: Re: mailman cgi-bin denied search >>> To: Daniel J Walsh , fedora-selinux-list at redhat.com >>> Message-ID: <43570188.5060201 at redhat.com> >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> >>> Tim Fenn wrote: >>> >>> >>>> On Wed, Oct 19, 2005 at 09:57:07AM -0400, Daniel J Walsh wrote: >>>> >>>> >>>>> Tim Fenn wrote: >>>>> >>>>> >>>>>> I recently installed mailman on my FC3 box (using the redhat based >>>>>> RPMs), and it seems to be working just fine, except for the numerous >>>>>> avc messages it cranks out whenever I run one of the cgi scripts >>>>>> associated with mailman (e.g. via the web interface): >>>>>> >>>>>> Oct 19 00:34:21 agora kernel: audit(1129707261.236:212): avc: >>>>>> denied >>>>>> { search } for pid=18761 comm="listinfo" name="run" dev=sda1 >>>>>> ino=1294372 scontext=root:system_r:mailman_cgi_t tcontext=system_ >>>>>> u:object_r:var_run_t tclass=dir >>>>>> >>>>>> >>>>> >>>>> Why would mailman listinfo be searching /var/log directory? >>>>> >>>>> >>>> >>>> Well, I get the same errors with mailmanctl: >>>> >>>> ./mailmanctl status >>>> >>>> yields no output, and the following errors: >>>> Oct 19 13:22:39 agora kernel: audit(1129753359.647:314): avc: denied >>>> { read write } for pid=20837 comm="mailmanctl" name="3" dev=devpts >>>> ino=5 scontext=root:system_r:mailman_mail_t >>>> tcontext=root:object_r:devpts_t tclass=chr_file >>>> Oct 19 13:22:39 agora kernel: audit(1129753359.694:318): avc: denied >>>> { search } for pid=20837 comm="mailmanctl" name="run" dev=sda1 >>>> ino=1294372 scontext=root:system_r:mailman_mail_t >>>> tcontext=system_u:object_r:var_run_t tclass=dir >>>> Oct 19 13:22:39 agora kernel: audit(1129753359.802:322): avc: denied >>>> { setgid } for pid=20837 comm="mailmanctl" capability=6 >>>> scontext=root:system_r:mailman_mail_t >>>> tcontext=root:system_r:mailman_mail_t tclass=capability >>>> >>>> However, if I comment out: >>>> >>>> from Mailman.Logging.Syslog import syslog >>>> >>>> in the mailmanctl script, all is well: >>>> >>>> # ./mailmanctl status >>>> mailman (pid 17677) is running... >>>> >>>> and no error messages. I would assume the same is true with the >>>> cgi-bin scripts, such as listinfo. Should I file a bugzilla report? >>>> >>>> Regards, >>>> Tim >>>> >>> >>> Yes. submit a bug. Although generating these in FC4 would be far >>> more interesting. Also do these AVC messages cause problems or are >>> they just being reported. No output from the script is fixed in FC4. >>> >>> >>> >>> >> >> >> -- >> Jayendren Anand Maduray >> Microsoft Certified Professional >> Network Plus >> IT Administrator >> >> Perinatal HIV Research Unit >> Old Potch Road >> Chris Hani Baragwanath Hospital >> Soweto >> South Africa >> >> Tel: +27 11 989 9776 >> Tel: +27 11 989 9999 >> Fax: +27 11 938 3973 >> Cel: 082 22 774 94 >> >> Alternate email address: jayendren at mweb.co.za >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From martin at gregorie.org Sun Oct 23 11:16:12 2005 From: martin at gregorie.org (Martin Gregorie) Date: Sun, 23 Oct 2005 12:16:12 +0100 Subject: NTPD vs SELinux question Message-ID: <1130066171.14554.547.camel@cretin.gregorie.lan> I've had to disable SELinux protection on ntpd, which seems a bit drastic, and would like to know if there's a more restrictive approach. I'm using an MSF clock to pick up the Rugby (UK) time signal and a specialised daemon to interrogate the clock. This daemon communicates with ntpd via shared memory and is configured into ntpd as: server 127.127.28.0 #SHM reference clock fudge 127.127.1.0 stratum 2 refid "MSF" Both daemons are running under the same (ntp) user. This worked under Fedora Core 1 without any problems, but under Core 3 during boot the log contained: Oct 17 15:21:14 zoogz radioclkd[4639]: entering daemon mode Oct 17 15:21:14 zoogz radioclkd[4639]: error unable to set real time scheduling Oct 17 15:21:14 zoogz radioclkd[4639]: error unable to lock memory pages Oct 17 16:21:14 zoogz radioclkd: radioclkd startup succeeded Oct 17 16:21:30 zoogz ntpdate[4649]: step time server 192.36.143.150 offset -0.0Oct 17 16:21:30 zoogz ntpd: succeeded Oct 17 16:21:30 zoogz ntpd[4653]: ntpd 4.2.0a at 1.1190-r Fri Aug 26 04:27:20 EDT 2Oct 17 16:21:30 zoogz ntpd: ntpd startup succeeded Oct 17 16:21:30 zoogz ntpd[4653]: precision = 3.000 usec Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface wildcard, 0.0.0.0#123 Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface wildcard, ::#123 Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface lo, 127.0.0.1#123 Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface eth0, 192.168.7.2#123 Oct 17 16:21:30 zoogz ntpd[4653]: kernel time sync status 0040 Oct 17 16:21:30 zoogz kernel: audit(1129562490.239:3): avc: denied { ipc_owner } for pid=4653 comm="ntpd" capability=15 scontext=root:system_r:ntpd_t tcontext=root:system_r:ntpd_t tclass=capability Oct 17 16:21:30 zoogz ntpd[4653]: SHM shmget (unit 0): Permission denied Oct 17 16:21:30 zoogz ntpd[4653]: configuration of 127.127.28.0 failed Oct 17 16:21:30 zoogz ntpd[4653]: frequency initialized 126.404 PPM from /var/liOct 17 16:24:49 zoogz ntpd[4653]: synchronized to 192.36.143.150, stratum 1 I can get the MSF to connect to ntpd if I turn off SELinux protection for ntpd, but this seems a bit drastic and in any case radioclkd is still complaining that it can't turn on realtime scheduling or lock the memory pages. Is there a way to: * allow radioclkd to set realtime scheduling * allow radioclkd to lock memory pages * allow ntpd to execute the shmget() call without turning off SELinux protection for ntpd? What about allowing radioclkd to set realtime scheduling and lock the required memory pages?. I apologise if I've sent this to the wrong list, but it seemed like the best one from the content of the Fedora SELinux documentation and would seen to be a general problem for at least some users who run ntpd. Best regards, Martin Gregorie From dwalsh at redhat.com Mon Oct 24 14:12:19 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 10:12:19 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <435C7E1F.8060009@hivsa.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> Message-ID: <435CEBC3.6070207@redhat.com> Jayendren Anand Maduray wrote: > Thank for your response, i really appreciate it. > > Squid clam binary is located in: > > /usr/local/squidclamav/bin > > > I isssue: > > [root at shiva jay]# chcon -t bin_t *`which /usr/local/squidclamav/bin/` > > and get error: Just enter chcon -t bin_t /usr/local/squidclamav/bin/* But the relabel should have done that for you. ls -lZ /usr/local/squidclamav/bin Should show files marked as bin_t. Now turn on squid (IE change the boolean and restart the service). What AVC messages are you seeing now? Dan No the -- From dwalsh at redhat.com Mon Oct 24 14:46:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 10:46:32 -0400 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <17242.37395.490964.418390@freddi.uddeborg.se> References: <17242.37395.490964.418390@freddi.uddeborg.se> Message-ID: <435CF3C8.6040401@redhat.com> G?ran Uddeborg wrote: > The policy apparently does not allow exporting an NTFS filesystem over > NFS. I can't see any obvious reason for this choice, but maybe there > is something I miss. Is this intentional, or is it a mistake? Or in > other words, should I bugzilla or only figure out how to change it for > myself? > > The error message I get trying to export an NTFS fileystem is included > below. (If I go into permissive mode everything works as expected.) > > type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir > type=SYSCALL msg=audit(1130008471.475:403): arch=40000003 syscall=196 success=no exit=-13 a0=ffffb80b a1=ffffb76c a2=f7fc2ff4 a3=8052712 items=1 pid=9034 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="exportfs" exe="/usr/sbin/exportfs" > type=AVC_PATH msg=audit(1130008471.475:403): path="/mnt/remote/teddi" > type=CWD msg=audit(1130008471.475:403): cwd="/etc/selinux/strict/contexts/users" > type=PATH msg=audit(1130008471.475:403): item=0 name="/mnt/remote/teddi" flags=0 inode=5 dev=08:01 mode=040555 ouid=0 ogid=0 rdev=00:00 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > do you have the nfs booleans turned on? getsebool -a | grep nfs_export nfs_export_all_ro --> active nfs_export_all_rw --> active Dan -- From dwalsh at redhat.com Mon Oct 24 14:50:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 10:50:24 -0400 Subject: AVC message problem In-Reply-To: References: Message-ID: <435CF4B0.4030100@redhat.com> Tom Diehl wrote: > Hi all, > > Since upgrading to EL4-U2 I am getting the following avc messages in my logs: > > Oct 23 14:46:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus > > Can someone tell me how to go about fixing this, short of turning off selinux? > > (pocono pts13) # rpm -qa | grep selinux > libselinux-1.19.1-7 > libselinux-1.19.1-7 > selinux-policy-targeted-1.17.30-2.110 > libselinux-devel-1.19.1-7 > (pocono pts13) # rpm -qa dbus > dbus-0.22-12.EL.5 > (pocono pts13) # uname -r > 2.6.9-22.ELsmp > (pocono pts13) # > > I get hundreds of these a day. I have tried relabeling but no change. > > The system arch is x86_64 > > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Could you try ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/selinux-policy-targeted-* We are moving to deliver an errata release of this policy. -- From dwalsh at redhat.com Mon Oct 24 14:51:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 10:51:53 -0400 Subject: NTPD vs SELinux question In-Reply-To: <1130066171.14554.547.camel@cretin.gregorie.lan> References: <1130066171.14554.547.camel@cretin.gregorie.lan> Message-ID: <435CF509.5070908@redhat.com> Martin Gregorie wrote: > I've had to disable SELinux protection on ntpd, which seems a bit > drastic, and would like to know if there's a more restrictive approach. > > I'm using an MSF clock to pick up the Rugby (UK) time signal and a > specialised daemon to interrogate the clock. This daemon communicates > with ntpd via shared memory and is configured into ntpd as: > > server 127.127.28.0 #SHM reference clock > fudge 127.127.1.0 stratum 2 refid "MSF" > Both daemons are running under the same (ntp) user. This worked under Fedora Core 1 without any problems, but under Core 3 during boot the log contained: > > Oct 17 15:21:14 zoogz radioclkd[4639]: entering daemon mode > Oct 17 15:21:14 zoogz radioclkd[4639]: error unable to set real time > scheduling > Oct 17 15:21:14 zoogz radioclkd[4639]: error unable to lock memory pages > Oct 17 16:21:14 zoogz radioclkd: radioclkd startup succeeded > Oct 17 16:21:30 zoogz ntpdate[4649]: step time server 192.36.143.150 > offset -0.0Oct 17 16:21:30 zoogz ntpd: succeeded > Oct 17 16:21:30 zoogz ntpd[4653]: ntpd 4.2.0a at 1.1190-r Fri Aug 26 > 04:27:20 EDT 2Oct 17 16:21:30 zoogz ntpd: ntpd startup succeeded > Oct 17 16:21:30 zoogz ntpd[4653]: precision = 3.000 usec > Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface wildcard, > 0.0.0.0#123 > Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface wildcard, > ::#123 > Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface lo, > 127.0.0.1#123 > Oct 17 16:21:30 zoogz ntpd[4653]: Listening on interface eth0, > 192.168.7.2#123 > Oct 17 16:21:30 zoogz ntpd[4653]: kernel time sync status 0040 > Oct 17 16:21:30 zoogz kernel: audit(1129562490.239:3): avc: denied { > ipc_owner } for pid=4653 comm="ntpd" capability=15 > scontext=root:system_r:ntpd_t tcontext=root:system_r:ntpd_t > tclass=capability > Oct 17 16:21:30 zoogz ntpd[4653]: SHM shmget (unit 0): Permission denied > Oct 17 16:21:30 zoogz ntpd[4653]: configuration of 127.127.28.0 failed > Oct 17 16:21:30 zoogz ntpd[4653]: frequency initialized 126.404 PPM from > /var/liOct 17 16:24:49 zoogz ntpd[4653]: synchronized to 192.36.143.150, > stratum 1 > > I can get the MSF to connect to ntpd if I turn off SELinux protection > for ntpd, but this seems a bit drastic and in any case radioclkd is > still complaining that it can't turn on realtime scheduling or lock the > memory pages. > > Is there a way to: > * allow radioclkd to set realtime scheduling > * allow radioclkd to lock memory pages > * allow ntpd to execute the shmget() call > > without turning off SELinux protection for ntpd? What about allowing > radioclkd to set realtime scheduling and lock the required memory > pages?. > > I apologise if I've sent this to the wrong list, but it seemed like the > best one from the content of the Fedora SELinux documentation and would > seen to be a general problem for at least some users who run ntpd. > > Best regards, > Martin Gregorie > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Could you turn off enforcing mode and grab all the AVC Messages that are generated? setenforce 0 -- From tdiehl at rogueind.com Mon Oct 24 15:09:42 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Mon, 24 Oct 2005 11:09:42 -0400 (EDT) Subject: AVC message problem In-Reply-To: <435CF4B0.4030100@redhat.com> References: <435CF4B0.4030100@redhat.com> Message-ID: On Mon, 24 Oct 2005, Daniel J Walsh wrote: > Tom Diehl wrote: > > Hi all, > > > > Since upgrading to EL4-U2 I am getting the following avc messages in my logs: > > > > Oct 23 14:46:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus > > > > Can someone tell me how to go about fixing this, short of turning off selinux? > > > > (pocono pts13) # rpm -qa | grep selinux > > libselinux-1.19.1-7 > > libselinux-1.19.1-7 > > selinux-policy-targeted-1.17.30-2.110 > > libselinux-devel-1.19.1-7 > > (pocono pts13) # rpm -qa dbus > > dbus-0.22-12.EL.5 > > (pocono pts13) # uname -r > > 2.6.9-22.ELsmp > > (pocono pts13) # > > > > I get hundreds of these a day. I have tried relabeling but no change. > > > > The system arch is x86_64 > > > Could you try Yep > > ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/selinux-policy-targeted-* > > We are moving to deliver an errata release of this policy. I did the following: (pocono pts18) # rpm -Fvh selinux-policy-targeted-1.17.30-2.117.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy-targeted########################################### [100%] (pocono pts18) # And I got the following in the logs: Oct 24 10:59:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus Oct 24 10:59:31 pocono last message repeated 2 times Oct 24 10:59:35 pocono kernel: security: 3 users, 4 roles, 354 types, 25 bools Oct 24 10:59:35 pocono kernel: security: 55 classes, 21778 rules Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: received policyload notice (seqno=1) Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: 4 AV entries and 4/512 buckets used, longest chain length 1 Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=4252 uid=508 loginuid=-1 message=avc: received policyload notice (seqno=1) Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=4252 uid=508 loginuid=-1 message=avc: 1 AV entries and 1/512 buckets used, longest chain length 1 So far no more avc messages. They were showing up every 5-15 seconds before. It has been approx 5 minutes with no avc messages. Is there anything else I should be looking at? Is there a bug for this? Thank You for the help. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From linux_4ever at yahoo.com Mon Oct 24 15:10:57 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 24 Oct 2005 08:10:57 -0700 (PDT) Subject: Rotate audit log? In-Reply-To: Message-ID: <20051024151057.86630.qmail@web51506.mail.yahoo.com> > Is there a reason not to include /var/log/audit/audit.log in the logrotate > regime? Yes, CAPP has requirements that all audit failures be handled appropriately. This includes an error rotating logs. The audit daemon handles its own log rotation. Hope this helps... -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From selinux at gmail.com Mon Oct 24 15:27:48 2005 From: selinux at gmail.com (Tom London) Date: Mon, 24 Oct 2005 08:27:48 -0700 Subject: dbusd and netlink_selinux_socket ? Message-ID: <4c4ba1530510240827v6fc9e4ffgb16a0063bfa952d4@mail.gmail.com> Running targeted/enforcing, latest rawhide. dbusd on my system seems to be having problems starting: Oct 24 06:48:20 localhost dbus-daemon: Can't send to audit system: USER_AVC pid=2390 uid=0 loginuid=-1 message=avc: can't open netlink socket: 13 (Permission denied) and in audit.log: type=AVC msg=audit(1130161700.864:93): avc: denied { create } for pid=2390 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:system_r:system_dbusd_t:s0 tclass=netlink_selinux_socket type=SYSCALL msg=audit(1130161700.864:93): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bfbaa750 a2=2c2248 a3=19a items=0 pid=2390 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" type=SOCKETCALL msg=audit(1130161700.864:93): nargs=3 a0=10 a1=3 a2=7 dbusd.te seems to want create_socket_perms (or create_netlink_socket_perms) for self:netlink_selinux_socket That right? Something else? tom -- Tom London From mjs at ces.clemson.edu Mon Oct 24 16:12:00 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Mon, 24 Oct 2005 12:12:00 -0400 (EDT) Subject: Rotate audit log? In-Reply-To: <20051024151057.86630.qmail@web51506.mail.yahoo.com> References: <20051024151057.86630.qmail@web51506.mail.yahoo.com> Message-ID: On Mon, 24 Oct 2005, Steve G wrote: > >> Is there a reason not to include /var/log/audit/audit.log in the logrotate >> regime? > > Yes, CAPP has requirements that all audit failures be handled appropriately. > This includes an error rotating logs. The audit daemon handles its own log > rotation. > > Hope this helps... Thanks. The only thing it didn't explain is why I never see rotated audit logs. Since installing FC4, I've only ever seen a single audit.log, now up to almost 8MB. I was going to ask if there is config setting someplace, but I found it and I see that it rotates at 8MB. My confusion was that it never seemed to get rotated with the other logs. > > -Steve > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From rhally at mindspring.com Mon Oct 24 17:17:12 2005 From: rhally at mindspring.com (Richard Hally) Date: Mon, 24 Oct 2005 13:17:12 -0400 Subject: Rotate audit log? In-Reply-To: <20051024151057.86630.qmail@web51506.mail.yahoo.com> References: <20051024151057.86630.qmail@web51506.mail.yahoo.com> Message-ID: <435D1718.50004@mindspring.com> Steve G wrote: >>Is there a reason not to include /var/log/audit/audit.log in the logrotate >>regime? > > > Yes, CAPP has requirements that all audit failures be handled appropriately. > This includes an error rotating logs. The audit daemon handles its own log > rotation. > > Hope this helps... > > -Steve > > > > > __________________________________ > Yahoo! Mail - PC Magazine Editors' Choice 2005 > http://mail.yahoo.com > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Is there something other than the size of the logfile that can be used to cause the rotation? Would an RFE for a command to the deamon to cause a rotation be appropriate? How about something in the config file to tell it "daily" or similar? Thanks Richard Hally From dwalsh at redhat.com Mon Oct 24 18:06:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 14:06:36 -0400 Subject: AVC message problem In-Reply-To: References: <435CF4B0.4030100@redhat.com> Message-ID: <435D22AC.8040308@redhat.com> Tom Diehl wrote: > On Mon, 24 Oct 2005, Daniel J Walsh wrote: > > >> Tom Diehl wrote: >> >>> Hi all, >>> >>> Since upgrading to EL4-U2 I am getting the following avc messages in my logs: >>> >>> Oct 23 14:46:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus >>> >>> Can someone tell me how to go about fixing this, short of turning off selinux? >>> >>> (pocono pts13) # rpm -qa | grep selinux >>> libselinux-1.19.1-7 >>> libselinux-1.19.1-7 >>> selinux-policy-targeted-1.17.30-2.110 >>> libselinux-devel-1.19.1-7 >>> (pocono pts13) # rpm -qa dbus >>> dbus-0.22-12.EL.5 >>> (pocono pts13) # uname -r >>> 2.6.9-22.ELsmp >>> (pocono pts13) # >>> >>> I get hundreds of these a day. I have tried relabeling but no change. >>> >>> The system arch is x86_64 >>> >>> >> Could you try >> > > Yep > > >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u3/selinux-policy-targeted-* >> >> We are moving to deliver an errata release of this policy. >> > > I did the following: > > (pocono pts18) # rpm -Fvh selinux-policy-targeted-1.17.30-2.117.noarch.rpm > Preparing... ########################################### [100%] > 1:selinux-policy-targeted########################################### [100%] > (pocono pts18) # > > And I got the following in the logs: > > Oct 24 10:59:21 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: denied { send_msg } for scontext=user_u:system_r:unconfined_t tcontext=user_u:system_r:initrc_t tclass=dbus > Oct 24 10:59:31 pocono last message repeated 2 times > Oct 24 10:59:35 pocono kernel: security: 3 users, 4 roles, 354 types, 25 bools > Oct 24 10:59:35 pocono kernel: security: 55 classes, 21778 rules > Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: received policyload notice (seqno=1) > Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=3064 uid=81 loginuid=-1 message=avc: 4 AV entries and 4/512 buckets used, longest chain length 1 > Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=4252 uid=508 loginuid=-1 message=avc: received policyload notice (seqno=1) > Oct 24 10:59:35 pocono dbus: Can't send to audit system: USER_AVC pid=4252 uid=508 loginuid=-1 message=avc: 1 AV entries and 1/512 buckets used, longest chain length 1 > > So far no more avc messages. They were showing up every 5-15 seconds > before. It has been approx 5 minutes with no avc messages. > > Is there anything else I should be looking at? > > Nope it should all work now. > Is there a bug for this? > Yes, hopefully we will release this as an errata, It will definitely be in U3. > Thank You for the help. > > Regards, > > Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com > -- From dwalsh at redhat.com Mon Oct 24 18:30:54 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 24 Oct 2005 14:30:54 -0400 Subject: dbusd and netlink_selinux_socket ? In-Reply-To: <4c4ba1530510240827v6fc9e4ffgb16a0063bfa952d4@mail.gmail.com> References: <4c4ba1530510240827v6fc9e4ffgb16a0063bfa952d4@mail.gmail.com> Message-ID: <435D285E.9020905@redhat.com> Tom London wrote: > Running targeted/enforcing, latest rawhide. > > dbusd on my system seems to be having problems starting: > > Oct 24 06:48:20 localhost dbus-daemon: Can't send to audit system: > USER_AVC pid=2390 uid=0 loginuid=-1 message=avc: can't open netlink > socket: 13 (Permission denied) > > and in audit.log: > > type=AVC msg=audit(1130161700.864:93): avc: denied { create } for > pid=2390 comm="dbus-daemon" > scontext=system_u:system_r:system_dbusd_t:s0 > tcontext=system_u:system_r:system_dbusd_t:s0 > tclass=netlink_selinux_socket > type=SYSCALL msg=audit(1130161700.864:93): arch=40000003 syscall=102 > success=no exit=-13 a0=1 a1=bfbaa750 a2=2c2248 a3=19a items=0 pid=2390 > auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" > type=SOCKETCALL msg=audit(1130161700.864:93): nargs=3 a0=10 a1=3 a2=7 > > dbusd.te seems to want create_socket_perms (or > create_netlink_socket_perms) for self:netlink_selinux_socket > > That right? Something else? > > tom > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Try latest policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/selinux-policy* -- From dvelarde at us.ibm.com Mon Oct 24 22:14:18 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Mon, 24 Oct 2005 16:14:18 -0600 Subject: zip unzip - restore xattr patches Message-ID: Below are patches to zip and unzip that will allow administrators to restore extended attributes. I understand star already does this, but this gives administrators another option. Usage: zip Will store extended attributes in the archive file by default unless the existing option: "-X eXclude eXtra file attributes" is used. unzip Will NOT restore extended attributes by default. Will only restore extended attributes if used with the new option: "-E restore extended attributes". The new -E option can only be used in conjunction with the existing: "-X restore UID/GID info" option. Users can still choose to restore only the UID/GID info with the existing '-X' option. Please send me any feedback. Thanks, debora diff -urpN zip-2.3.orig/unix/Makefile zip-2.3/unix/Makefile --- zip-2.3.orig/unix/Makefile 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/unix/Makefile 2005-10-24 15:38:44.000000000 -0500 @@ -59,7 +59,7 @@ OBJN = zipnote.o $(OBJU) OBJC = zipcloak.o $(OBJU) crctab.o crypt_.o ttyio.o OBJS = zipsplit.o $(OBJU) -ZIP_H = zip.h ziperr.h tailor.h unix/osdep.h +ZIP_H = zip.h ziperr.h tailor.h unix/osdep.h unix/xattr.h # suffix rules .SUFFIXES: diff -urpN zip-2.3.orig/unix/unix.c zip-2.3/unix/unix.c --- zip-2.3.orig/unix/unix.c 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/unix/unix.c 2005-10-24 15:38:44.000000000 -0500 @@ -11,6 +11,7 @@ #ifndef UTIL /* the companion #endif is a bit of ways down ... */ #include +#include "xattr.h" #if defined(MINIX) || defined(__mpexl) # ifdef S_IWRITE @@ -40,6 +41,8 @@ # endif #endif /* HAVE_DIRENT_H || _POSIX_VERSION */ +#include + #define PAD 0 #define PATH_END '/' @@ -436,19 +439,80 @@ int set_extra_field(z, z_utim) struct stat s; #endif +char * xa_list; +char * xa_name; +char * xa_value; +ssize_t xa_list_len=0; +ssize_t xa_name_len=0; +ssize_t xa_value_len=0; +int value_len=0; +int largest_value_len=0; +int ext_index=0; +int xa_pairs_found=0; +int value_index=1; +int i=0, j=0; + /* For the full sized UT local field including the UID/GID fields, we * have to stat the file again. */ if (LSSTAT(z->name, &s)) return ZE_OPEN; + #define EB_L_UT_SIZE (EB_HEADSIZE + EB_UT_LEN(2)) #define EB_C_UT_SIZE (EB_HEADSIZE + EB_UT_LEN(1)) #define EB_L_UX2_SIZE (EB_HEADSIZE + EB_UX2_MINLEN) #define EB_C_UX2_SIZE EB_HEADSIZE -#define EF_L_UNIX_SIZE (EB_L_UT_SIZE + EB_L_UX2_SIZE) -#define EF_C_UNIX_SIZE (EB_C_UT_SIZE + EB_C_UX2_SIZE) +#define EB_L_XA_SIZE (EB_HEADSIZE + EB_XA_MINLEN) +#define EB_C_XA_SIZE EB_HEADSIZE - if ((z->extra = (char *)malloc(EF_L_UNIX_SIZE)) == NULL) + /* Get size of xattr name list */ + /* Calling listxattr with NULL and zero returns the size */ + xa_list_len = listxattr(z->name, NULL, 0); + + if (xa_list_len > 0) { + + /* now that we know the size, alloc space for list */ + if ((xa_list = malloc(xa_list_len+1)) == NULL) + return ZE_MEM; + + /* Get the list of xattr names */ + xa_list_len = listxattr(z->name, xa_list, xa_list_len); + if (xa_list_len < 0) + return ZE_XATTR; + xa_name = xa_list; + xa_name_len = xa_list_len; + + /* figure out how many xattr names there are in the list */ + xa_pairs_found=get_xattr_count(xa_list, xa_list_len); + if (xa_pairs_found < 1) + return ZE_XATTR; + + /* Need to figure out the largest value_len before calling malloc */ + /* also need the sum of all value_lens; store it in xa_value_len */ + for (value_index=1; value_index <= xa_pairs_found; value_index++) { + xa_name=get_xattr_name(xa_list, xa_list_len, value_index); + if (xa_name == (char *)NULL) + return ZE_XATTR; + value_len=getxattr(z->name, xa_name, xa_value, 0); + if (value_len < 0) + return ZE_XATTR; + if (value_len > largest_value_len) + largest_value_len = value_len; + xa_value_len=xa_value_len + value_len + 1; + } + if ((xa_value = malloc(largest_value_len+1)) == NULL) + return ZE_MEM; + } + +#define EB_L_XN_SIZE (EB_HEADSIZE + EB_XA_MINLEN + xa_name_len) +#define EB_C_XN_SIZE EB_HEADSIZE +#define EB_L_XV_SIZE (EB_HEADSIZE + EB_XA_MINLEN + xa_value_len) +#define EB_C_XV_SIZE EB_HEADSIZE +#define EF_L_UNIX_SIZE (EB_L_UT_SIZE + EB_L_UX2_SIZE + EB_L_XA_SIZE + EB_L_XN_SIZE + EB_L_XV_SIZE) +#define EF_C_UNIX_SIZE (EB_C_UT_SIZE + EB_C_UX2_SIZE + EB_C_XA_SIZE + EB_C_XN_SIZE + EB_C_XV_SIZE) + + z->ext = EF_L_UNIX_SIZE; + if ((z->extra = (char *)malloc(z->ext)) == NULL) return ZE_MEM; if ((z->cextra = (char *)malloc(EF_C_UNIX_SIZE)) == NULL) return ZE_MEM; @@ -474,7 +538,71 @@ int set_extra_field(z, z_utim) z->extra[18] = (char)(s.st_uid >> 8); z->extra[19] = (char)(s.st_gid); z->extra[20] = (char)(s.st_gid >> 8); - z->ext = EF_L_UNIX_SIZE; + z->extra[21] = 'X'; + z->extra[22] = 'A'; + z->extra[23] = (char) xa_pairs_found; /* Number of xattr attributes*/ + z->extra[24] = 0; + z->extra[25] = 'X'; + z->extra[26] = 'N'; + z->extra[27] = (char) xa_name_len; /* length of xattr name list*/ + z->extra[28] = 0; + + ext_index=29; + + if (xa_list_len > 0) { + +/* Put all the xattr names in extra field */ + for (i=1; i<=xa_pairs_found; i++) { + xa_name=get_xattr_name(xa_list, xa_list_len, i); + if (xa_name == (char *)NULL) + return ZE_XATTR; + xa_name_len=strlen(xa_name); + if (xa_name_len < 1) + return ZE_XATTR; + for (j=0; jextra[ext_index+j]=(char) xa_name[j]; + } + ext_index = ext_index+j; + z->extra[ext_index] = '\0'; + ext_index++; + } + + z->extra[ext_index] = 'X'; + ext_index++; + z->extra[ext_index] = 'V'; + ext_index++; + z->extra[ext_index] = (char) xa_value_len; /* length of xattr value list*/ + ext_index++; + z->extra[ext_index] = 0; + ext_index++; + +/* Put all the xattr values in extra field */ + for (value_index=1; value_index <= xa_pairs_found; value_index++) { + xa_name=get_xattr_name(xa_list, xa_list_len, value_index); + if (xa_name == (char *)NULL) + return ZE_XATTR; + value_len=getxattr(z->name, xa_name, xa_value, 0); + if (value_len < 1) + return ZE_XATTR; + xa_value=memset(xa_value, 0, largest_value_len+1); + if (xa_value == (char *) NULL) + return ZE_MEM; + value_len=getxattr(z->name, xa_name, xa_value, value_len); + if (value_len < 1) + return ZE_XATTR; + + for (j=0; jextra[ext_index+j]=(char) xa_value[j]; + } + ext_index = ext_index+j; + z->extra[ext_index] = '\0'; + ext_index++; + } + + } /* if xa_list_len > 0 */ + + free(xa_list); + free(xa_value); memcpy(z->cextra, z->extra, EB_C_UT_SIZE); z->cextra[EB_LEN] = (char)EB_UT_LEN(1); diff -urpN zip-2.3.orig/unix/xattr.h zip-2.3/unix/xattr.h --- zip-2.3.orig/unix/xattr.h 1969-12-31 18:00:00.000000000 -0600 +++ zip-2.3/unix/xattr.h 2005-10-24 15:42:43.000000000 -0500 @@ -0,0 +1,67 @@ +/* + Copyright (C) 2005 IBM Corporation + Copyright (c) 1990-1999 Info-ZIP. All rights reserved. + + See the accompanying file LICENSE, version 1999-Oct-05 or later + (the contents of which are also included in zip.h) for terms of use. + If, for some reason, both of these files are missing, the Info-ZIP license + also may be found at: ftp://ftp.cdrom.com/pub/infozip/license.html +*/ + + +int get_xattr_count(char * xa_list, int xa_list_size) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns the number of name pairs found */ +/* If list passed in is NULL or list size is less than 1 + function returns 0 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1)) + return 0; + + while (i < xa_list_size) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; + p++; + } + } + return p; +} + +char * get_xattr_name(char * xa_list, int xa_list_size, int pair) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns a pointer to the specified name pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char * tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} diff -urpN zip-2.3.orig/zip.c zip-2.3/zip.c --- zip-2.3.orig/zip.c 2005-10-10 14:11:49.000000000 -0500 +++ zip-2.3/zip.c 2005-10-24 15:38:44.000000000 -0500 @@ -980,7 +980,7 @@ char **argv; /* command line zp_tz_is_valid = VALID_TIMEZONE(p); #if (defined(AMIGA) || defined(DOS)) if (!zp_tz_is_valid) - extra_fields = 0; /* disable storing "UT" time stamps and xatter info*/ + extra_fields = 0; /* disable storing "UT" time stamps */ #endif /* AMIGA || DOS */ #endif /* IZ_CHECK_TZ && USE_EF_UT_TIME */ diff -urpN zip-2.3.orig/ziperr.h zip-2.3/ziperr.h --- zip-2.3.orig/ziperr.h 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/ziperr.h 2005-10-24 15:38:44.000000000 -0500 @@ -31,8 +31,9 @@ #define ZE_CREAT 15 /* couldn't open to write */ #define ZE_PARMS 16 /* bad command line */ #define ZE_OPEN 18 /* could not open a specified file to read */ +#define ZE_XATTR 19 /* xattr error occurred */ -#define ZE_MAXERR 18 /* the highest error number */ +#define ZE_MAXERR 19 /* the highest error number */ /* Macro to determine whether to call perror() or not */ #define PERR(e) (e==ZE_READ||e==ZE_WRITE||e==ZE_CREAT||e==ZE_TEMP||e==ZE_OPEN) @@ -58,6 +59,7 @@ char *errors[ZE_MAXERR] = { /* 16 */ "Invalid command arguments", /* 17 */ "", /* 18 */ "File not found or no read permission" +/* 19 */ "Extended attributes failure" # ifdef AZTEC_C , /* extremely lame compiler bug workaround */ # endif diff -urpN zip-2.3.orig/zip.h zip-2.3/zip.h --- zip-2.3.orig/zip.h 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h 2005-10-24 15:38:44.000000000 -0500 @@ -171,6 +171,9 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -199,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN zip-2.3.orig/zip.h.4gb zip-2.3/zip.h.4gb --- zip-2.3.orig/zip.h.4gb 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h.4gb 2005-10-24 15:38:44.000000000 -0500 @@ -171,6 +171,9 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -199,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN zip-2.3.orig/zip.h.zip zip-2.3/zip.h.zip --- zip-2.3.orig/zip.h.zip 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h.zip 2005-10-24 15:38:44.000000000 -0500 @@ -170,6 +170,10 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ + /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -198,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN unzip-5.51.orig/extract.c unzip-5.51/extract.c --- unzip-5.51.orig/extract.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/extract.c 2005-10-24 16:09:09.000000000 -0500 @@ -1908,6 +1908,9 @@ static int TestExtraField(__G__ ef, ef_l case EF_ASIUNIX: case EF_IZVMS: case EF_IZUNIX: + case EF_XATTR: + case EF_XA_NAME: + case EF_XA_VALUE: case EF_VMCMS: case EF_MVS: case EF_SPARK: diff -urpN unzip-5.51.orig/fileio.c unzip-5.51/fileio.c --- unzip-5.51.orig/fileio.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/fileio.c 2005-10-24 16:09:09.000000000 -0500 @@ -1833,6 +1833,9 @@ int check_for_newer(__G__ filename) /* #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif #ifdef AOS_VS long dyy, dmm, ddd, dhh, dmin, dss; @@ -1902,7 +1905,11 @@ int check_for_newer(__G__ filename) /* G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.lrec.extra_field_length, 0, +#ifdef USE_EF_XATTR + G.lrec.last_mod_dos_datetime, &z_utime, NULL, &z_xattr) +#else G.lrec.last_mod_dos_datetime, &z_utime, NULL) +#endif & EB_UT_FL_MTIME)) { TTrace((stderr, "check_for_newer: using Unix extra field mtime\n")); diff -urpN unzip-5.51.orig/list.c unzip-5.51/list.c --- unzip-5.51.orig/list.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/list.c 2005-10-24 16:09:09.000000000 -0500 @@ -104,6 +104,9 @@ int list_files(__G) /* return PK-type iztimes z_utime; struct tm *t; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif unsigned yr, mo, dy, hh, mm; ulg csiz; unsigned long long tot_csize=0, tot_ucsize=0; @@ -268,7 +271,12 @@ int list_files(__G) /* return PK-type G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0, Mac */ @@ -509,6 +517,9 @@ int get_time_stamp(__G__ last_modtime, n #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + iztimes z_xattr; +#endif min_info info; @@ -594,7 +605,12 @@ int get_time_stamp(__G__ last_modtime, n G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { if (*last_modtime < z_utime.mtime) diff -urpN unzip-5.51.orig/Makefile unzip-5.51/Makefile --- unzip-5.51.orig/Makefile 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/Makefile 2005-10-24 16:09:09.000000000 -0500 @@ -81,14 +81,14 @@ CRC32 = crc32 OSDEP_H = # object files -OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O +OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O xattr$O OBJS2 = extract$O fileio$O globals$O inflate$O list$O match$O OBJS3 = process$O ttyio$O unreduce$O unshrink$O zipinfo$O OBJS = $(OBJS1) $(OBJS2) $(OBJS3) $M$O LOBJS = $(OBJS) OBJSDLL = $(OBJS:.o=.pic.o) api.pic.o OBJX = unzipsfx$O $(CRC32)$O crctab_$O crypt_$O extract_$O fileio_$O \ - globals_$O inflate_$O match_$O process_$O ttyio_$O $M_$O + globals_$O inflate_$O match_$O process_$O ttyio_$O xattr_$O $M_$O LOBJX = $(OBJX) OBJF = funzip$O $(CRC32)$O cryptf$O globalsf$O inflatef$O ttyiof$O #OBJS_OS2 = $(OBJS1:.o=.obj) $(OBJS2:.o=.obj) os2.obj @@ -300,6 +300,7 @@ ttyio$O: ttyio.c $(UNZIP_H) zip.h crypt. unreduce$O: unreduce.c $(UNZIP_H) unshrink$O: unshrink.c $(UNZIP_H) unzip$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h +xattr$O: xattr.c $(UNZIP_H) zipinfo$O: zipinfo.c $(UNZIP_H) unzipsfx$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h # unzipsfx only @@ -342,6 +343,11 @@ match_$O: match.c $(UNZIP_H) # unzips $(CC) -c $(CF) -DSFX match_.c $(RM) match_.c +xattr_$O: xattr.c $(UNZIP_H) # unzipsfx only + -$(CP) xattr.c xattr_.c + $(CC) -c $(CF) -DSFX xattr_.c + $(RM) xattr_.c + process_$O: process.c $(UNZIP_H) # unzipsfx only -$(CP) process.c process_.c $(CC) -c $(CF) -DSFX process_.c diff -urpN unzip-5.51.orig/process.c unzip-5.51/process.c --- unzip-5.51.orig/process.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/process.c 2005-10-24 16:09:09.000000000 -0500 @@ -1300,15 +1300,22 @@ int process_local_file_hdr(__G) /* re /*******************************/ /* Function ef_scan_for_izux() */ /*******************************/ - +#ifdef USE_EF_XATTR +unsigned ef_scan_for_izux(ef_buf, ef_len, ef_is_c, dos_mdatetime, + z_utim, z_uidgid, z_xattr) +#else unsigned ef_scan_for_izux(ef_buf, ef_len, ef_is_c, dos_mdatetime, z_utim, z_uidgid) +#endif ZCONST uch *ef_buf; /* buffer containing extra field */ unsigned ef_len; /* total length of extra field */ int ef_is_c; /* flag indicating "is central extra field" */ ulg dos_mdatetime; /* last_mod_file_date_time in DOS format */ iztimes *z_utim; /* return storage: atime, mtime, ctime */ ush *z_uidgid; /* return storage: uid and gid */ +#ifdef USE_EF_XATTR + izxattr *z_xattr; /* return storage: xattr names, values, lens, count */ +#endif { unsigned flags = 0; unsigned eb_id; @@ -1342,6 +1349,12 @@ unsigned ef_scan_for_izux(ef_buf, ef_len if (ef_len == 0 || ef_buf == NULL || (z_utim == 0 && z_uidgid == NULL)) return 0; +#ifdef USE_EF_XATTR + if (z_xattr == NULL) + return 0; + z_xattr->count=0; +#endif + TTrace((stderr,"\nef_scan_for_izux: scanning extra field of length %u\n", ef_len)); @@ -1358,6 +1371,56 @@ unsigned ef_scan_for_izux(ef_buf, ef_len } switch (eb_id) { +#ifdef USE_EF_XATTR + case EF_XATTR: + z_xattr->count=eb_len; + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + eb_id = makeword(EB_ID + ef_buf); + } else { + break; + } + case EF_XA_NAME: + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + if ((z_xattr->xa_name=malloc(ef_len)) == (char *)NULL) { + Info(slide, 0x401, ((char *)slide, + LoadFarString(CannotAllocateBuffers))); + return 0; + } + z_xattr->xa_name_len=copy_xattr(ef_buf, z_xattr->xa_name, z_xattr->count); + if (z_xattr->xa_name_len < 0) { + TTrace((stderr, + " XATTR name error; ignore e.f.!\n")); + break; /* stop scanning this field */ + } + ef_buf += z_xattr->xa_name_len; + ef_len -= z_xattr->xa_name_len; + } else { + break; + } + case EF_XA_VALUE: + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + if ((z_xattr->xa_value=malloc(ef_len)) == (char *)NULL) { + Info(slide, 0x401, ((char *)slide, + LoadFarString(CannotAllocateBuffers))); + return 0; + } + z_xattr->xa_value_len=copy_xattr(ef_buf, z_xattr->xa_value, z_xattr->count); + if (z_xattr->xa_value_len <= 0) { + TTrace((stderr, + " XATTR value error; ignore e.f.!\n")); + break; /* stop scanning this field */ + } + ef_buf += z_xattr->xa_value_len; + ef_len -= z_xattr->xa_value_len; + } + break; +#endif case EF_TIME: flags &= ~0x0ff; /* ignore previous IZUNIX or EF_TIME fields */ have_new_type_eb = TRUE; diff -urpN unzip-5.51.orig/unix/Makefile unzip-5.51/unix/Makefile --- unzip-5.51.orig/unix/Makefile 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/Makefile 2005-10-24 16:09:09.000000000 -0500 @@ -81,14 +81,14 @@ CRC32 = crc32 OSDEP_H = # object files -OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O +OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O xattr$O OBJS2 = extract$O fileio$O globals$O inflate$O list$O match$O OBJS3 = process$O ttyio$O unreduce$O unshrink$O zipinfo$O OBJS = $(OBJS1) $(OBJS2) $(OBJS3) $M$O LOBJS = $(OBJS) OBJSDLL = $(OBJS:.o=.pic.o) api.pic.o OBJX = unzipsfx$O $(CRC32)$O crctab_$O crypt_$O extract_$O fileio_$O \ - globals_$O inflate_$O match_$O process_$O ttyio_$O $M_$O + globals_$O inflate_$O match_$O process_$O ttyio_$O xattr_$O $M_$O LOBJX = $(OBJX) OBJF = funzip$O $(CRC32)$O cryptf$O globalsf$O inflatef$O ttyiof$O #OBJS_OS2 = $(OBJS1:.o=.obj) $(OBJS2:.o=.obj) os2.obj @@ -300,6 +300,7 @@ ttyio$O: ttyio.c $(UNZIP_H) zip.h crypt. unreduce$O: unreduce.c $(UNZIP_H) unshrink$O: unshrink.c $(UNZIP_H) unzip$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h +xattr$O: xattr.c $(UNZIP_H) zipinfo$O: zipinfo.c $(UNZIP_H) unzipsfx$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h # unzipsfx only @@ -342,6 +343,11 @@ match_$O: match.c $(UNZIP_H) # unzips $(CC) -c $(CF) -DSFX match_.c $(RM) match_.c +xattr_$O: xattr.c $(UNZIP_H) # unzipsfx only + -$(CP) xattr.c xattr_.c + $(CC) -c $(CF) -DSFX xattr_.c + $(RM) xattr_.c + process_$O: process.c $(UNZIP_H) # unzipsfx only -$(CP) process.c process_.c $(CC) -c $(CF) -DSFX process_.c diff -urpN unzip-5.51.orig/unix/unix.c unzip-5.51/unix/unix.c --- unzip-5.51.orig/unix/unix.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/unix.c 2005-10-24 16:09:09.000000000 -0500 @@ -83,6 +83,7 @@ typedef struct uxdirattr { /* struc int have_uidgid; /* flag */ ush uidgid[2]; char fnbuf[1]; /* buffer stub for directory name */ + izxattr z_xattr; /* struct for xattr names and values */ } uxdirattr; #define UxAtt(d) ((uxdirattr *)d) /* typecast shortcut */ #endif /* SET_DIR_ATTRIB */ @@ -932,12 +933,13 @@ int mkdir(path, mode) #if (!defined(MTS) || defined(SET_DIR_ATTRIB)) -static int get_extattribs OF((__GPRO__ iztimes *pzt, ush z_uidgid[2])); +static int get_extattribs OF((__GPRO__ iztimes *pzt, ush z_uidgid[2], izxattr *pzxattr)); -static int get_extattribs(__G__ pzt, z_uidgid) +static int get_extattribs(__G__ pzt, z_uidgid, pzxattr) __GDEF iztimes *pzt; ush z_uidgid[2]; + izxattr *pzxattr; { /*--------------------------------------------------------------------------- Convert from MSDOS-format local time and date to Unix-format 32-bit GMT @@ -957,7 +959,13 @@ static int get_extattribs(__G__ pzt, z_u #else pzt, #endif - z_uidgid) : 0); + z_uidgid, +#ifdef USE_EF_XATTR + pzxattr) : 0); +#else + NULL) : 0); +#endif + if (eb_izux_flg & EB_UT_FL_MTIME) { TTrace((stderr, "\nget_extattribs: Unix e.f. modif. time = %ld\n", pzt->mtime)); @@ -1000,7 +1008,14 @@ void close_outfile(__G) /* GRR: chang ztimbuf t2; /* modtime, actime */ } zt; ush z_uidgid[2]; + izxattr z_xattr; int have_uidgid_flg; + int rc=0; + char *name; + char *value; + int i; + int value_len; + int largest_value_len=0; fchmod(fileno(G.outfile), 0400); @@ -1090,7 +1105,7 @@ void close_outfile(__G) /* GRR: chang } #endif - have_uidgid_flg = get_extattribs(__G__ &(zt.t3), z_uidgid); + have_uidgid_flg = get_extattribs(__G__ &(zt.t3), z_uidgid, &z_xattr); /* if -X option was specified and we have UID/GID info, restore it */ if (have_uidgid_flg) { @@ -1108,6 +1123,54 @@ void close_outfile(__G) /* GRR: chang } } +#ifdef USE_EF_XATTR +/* if -E option was specified attempt to restore extended attribute info */ + if (uO.E_flag && (!have_uidgid_flg)) { + Info(slide, 0x201, ((char *)slide, + " (warning) unable to restore extended attributes for %s\n", FnFilter1(G.filename))); + } + if (uO.E_flag && have_uidgid_flg) { + /* Restore extended attributes info */ + if (z_xattr.count > 0) { + /* Need to figure out the largest value_len before calling malloc */ + for (i=1; i<=z_xattr.count; i++) { + name = get_xattr_name(z_xattr.xa_name, z_xattr.xa_name_len, i); + value_len=getxattr(z_xattr.xa_name, name, value, 0); + if (value_len > largest_value_len) + largest_value_len = value_len; + } + if ((value = malloc(largest_value_len+1)) == (char *)NULL) { + Info(slide, 0x201, ((char *)slide, + "warning: xattr (%s) failed: no mem\n", + FnFilter1(G.filename))); + return; + } else { + /* Set all xattr name and value pairs */ + for (i=1; i<=z_xattr.count; i++) { + name = get_xattr_name(z_xattr.xa_name, z_xattr.xa_name_len, i); + if (name == (char *) NULL) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + value = get_xattr_value(z_xattr.xa_value, z_xattr.xa_value_len, i); + if (value == (char *) NULL) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + rc = setxattr(G.filename, name, value, strlen(value), 0); + if (rc != 0) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + } + } + } else { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + } +#endif + /* set the file's access and modification times */ if (utime(G.filename, &(zt.t2))) { #ifdef AOS_VS @@ -1160,7 +1223,7 @@ int defer_dir_attribs(__G__ pd) d_entry->perms = G.pInfo->file_attr; d_entry->have_uidgid = get_extattribs(__G__ &(d_entry->u.t3), - d_entry->uidgid); + d_entry->uidgid, &(d_entry->z_xattr)); return PK_OK; } /* end function defer_dir_attribs() */ diff -urpN unzip-5.51.orig/unix/unxcfg.h unzip-5.51/unix/unxcfg.h --- unzip-5.51.orig/unix/unxcfg.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/unxcfg.h 2005-10-24 16:09:09.000000000 -0500 @@ -122,6 +122,8 @@ #endif #define RESTORE_UIDGID +#define USE_EF_XATTR + /* Static variables that we have to add to Uz_Globs: */ #define SYSTEM_SPECIFIC_GLOBALS \ int created_dir, renamed_fullpath;\ diff -urpN unzip-5.51.orig/unzip.c unzip-5.51/unzip.c --- unzip-5.51.orig/unzip.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzip.c 2005-10-24 16:09:09.000000000 -0500 @@ -143,6 +143,8 @@ static ZCONST char Far InvalidOptionsMsg -fn or any combination of -c, -l, -p, -t, -u and -v options invalid\n"; static ZCONST char Far IgnoreOOptionMsg[] = "caution: both -n and -o specified; ignoring -o\n"; +static ZCONST char Far InvalidEModifierMsg[] = "error:\ + -E modifier cannot be used without -X modifier\n"; /* usage() strings */ #ifndef SFX @@ -238,12 +240,30 @@ M pipe through \"more\" pager #else /* !VMS */ #ifdef BEO_UNX static ZCONST char Far local2[] = " -X restore UID/GID info"; +#ifdef USE_EF_XATTR +#ifdef MORE + static ZCONST char Far local3[] = " \ +-E restore extended attributes -M pipe through \"more\" pager\n"; +#else /* !MORE */ + static ZCONST char Far local3[] = " \ +-E restore extended attributes\n"; +#endif +#else /* !USE_EF_XATTR */ +#ifdef MORE + static ZCONST char Far local3[] = "\ + -M pipe through \"more\" pager\n"; +#else /* !MORE */ + static ZCONST char Far local3[] = "\n"; +#endif +#endif +/* #ifdef MORE static ZCONST char Far local3[] = "\ -M pipe through \"more\" pager\n"; #else static ZCONST char Far local3[] = "\n"; #endif +*/ #else /* !BEO_UNX */ #ifdef TANDEM static ZCONST char Far local2[] = "\ @@ -1222,6 +1242,15 @@ int uz_opts(__G__ pargc, pargv) } break; #endif /* MACOS */ +#ifdef UNIX + case ('E'): /* -E [UNIX] restore extended attributes */ + if( negative ) { + uO.E_flag = FALSE, negative = 0; + } else { + uO.E_flag = TRUE; + } + break; +#endif /* MACOS */ case ('f'): /* "freshen" (extract only newer files) */ if (negative) uO.fflag = uO.uflag = FALSE, negative = 0; @@ -1521,6 +1550,13 @@ opts_done: /* yes, very ugly...but only Info(slide, 0x401, ((char *)slide, LoadFarString(InvalidOptionsMsg))); error = TRUE; } +#ifdef UNIX + if (uO.E_flag && (!uO.X_flag)) + { + Info(slide, 0x401, ((char *)slide, LoadFarString(InvalidEModifierMsg))); + error = TRUE; + } +#endif if (uO.aflag > 2) uO.aflag = 2; #ifdef VMS diff -urpN unzip-5.51.orig/unzip.h unzip-5.51/unzip.h --- unzip-5.51.orig/unzip.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzip.h 2005-10-24 16:09:09.000000000 -0500 @@ -438,6 +438,9 @@ typedef struct _UzpOpts { #ifdef MACOS int E_flag; /* -E: [MacOS] show Mac extra field during restoring */ #endif +#ifdef UNIX + int E_flag; /* -E: [Unix] restore extended attributes */ +#endif int fflag; /* -f: "freshen" (extract only newer files) */ #if (defined(RISCOS) || defined(ACORN_FTYPE_NFS)) int acorn_nfs_ext; /* -F: RISC OS types & NFS filetype extensions */ @@ -571,6 +574,7 @@ typedef struct central_directory_file_he #define PK_FIND 11 /* no files found */ #define PK_DISK 50 /* disk full */ #define PK_EOF 51 /* unexpected EOF */ +#define PK_XATTR 52 /* extended attributes error */ #define IZ_CTRLC 80 /* user hit ^C to terminate */ #define IZ_UNSUP 81 /* no files found: all unsup. compr/encrypt. */ diff -urpN unzip-5.51.orig/unzpriv.h unzip-5.51/unzpriv.h --- unzip-5.51.orig/unzpriv.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzpriv.h 2005-10-24 16:09:09.000000000 -0500 @@ -1433,6 +1433,9 @@ #define EF_THEOSO 0x4854 /* old Theos port */ #define EF_MD5 0x4b46 /* Fred Kantor's MD5 ("FK") */ #define EF_ASIUNIX 0x756e /* ASi's Unix ("nu") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ #define EB_HEADSIZE 4 /* length of extra field block header */ #define EB_ID 0 /* offset of block ID in header */ @@ -1459,6 +1462,8 @@ #define EB_UT_FL_ATIME (1 << 1) /* atime present */ #define EB_UT_FL_CTIME (1 << 2) /* ctime present */ +#define EB_XA_MINLEN 4 /* minimal XA size */ + #define EB_FLGS_OFFS 4 /* offset of flags area in generic compressed extra field blocks (BEOS, MAC, and others) */ #define EB_OS2_HLEN 4 /* size of OS2/ACL compressed data header */ @@ -1576,6 +1581,14 @@ typedef struct iztimes { time_t ctime; /* used for creation time; NOT same as st_ctime */ } iztimes; +typedef struct izxattr { + char *xa_name; /* xattr names list */ + char *xa_value; /* xattr values list */ + ssize_t xa_name_len; /* size of xa_names list */ + ssize_t xa_value_len; /* size of xa_value list */ + int count; /* number of xattr name and value pairs */ +} izxattr; + #ifdef SET_DIR_ATTRIB typedef struct direntry { /* head of system-specific struct holding */ struct direntry *next; /* defered directory attributes info */ @@ -1812,7 +1825,12 @@ int get_cdir_ent OF((__G int process_local_file_hdr OF((__GPRO)); unsigned ef_scan_for_izux OF((ZCONST uch *ef_buf, unsigned ef_len, int ef_is_c, ulg dos_mdatetime, +#ifdef USE_EF_XATTR + iztimes *z_utim, ush *z_uidgid, + izxattr *z_xattr)); +#else iztimes *z_utim, ush *z_uidgid)); +#endif #if (defined(RISCOS) || defined(ACORN_FTYPE_NFS)) zvoid *getRISCOSexfield OF((ZCONST uch *ef_buf, unsigned ef_len)); #endif @@ -1850,6 +1868,15 @@ void fnprint OF((__G #endif /* !SFX */ /*--------------------------------------------------------------------------- + Functions in xattr.c: + ---------------------------------------------------------------------------*/ + +int get_xattr_count(char *xa_list, int xa_list_size); +char * get_xattr_name(char *xa_list, int xa_list_size, int pair); +char * get_xattr_value(char *xa_list, int xa_list_size, int pair); +int copy_xattr(char *xa_list, char *new_list, int pair); + +/*--------------------------------------------------------------------------- Functions in fileio.c: ---------------------------------------------------------------------------*/ diff -urpN unzip-5.51.orig/xattr.c unzip-5.51/xattr.c --- unzip-5.51.orig/xattr.c 1969-12-31 18:00:00.000000000 -0600 +++ unzip-5.51/xattr.c 2005-10-24 16:12:01.000000000 -0500 @@ -0,0 +1,127 @@ +/* +*/ +/* xattr.c + * + * Author: Debora Velarde + * Created: Sept 14, 2005 + */ + + +#define __XATTR_C /* identifies this source module */ +#define UNZIP_INTERNAL +#include "unzip.h" + +int get_xattr_count(char *xa_list, int xa_list_size) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns the number of name pairs found */ +/* If list passed in is NULL or list size is less than 1 + function retunrs 0 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1)) + return 0; + + + while (i < xa_list_size) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + return p; +} + +char * get_xattr_name(char *xa_list, int xa_list_size, int pair) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns a pointer to the specified name pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char *tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} + +char * get_xattr_value(char *xa_list, int xa_list_size, int pair) +{ +/* A file can have any number of xattr name and value pairs */ +/* This function returns a pointer to the specified value pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char *tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} + +int copy_xattr(char *xa_list, char *new_list, int pair) +{ +/* A file can have any number of xattr name and value pairs */ +/* This function copies all the names or value from xa_list to new_list */ +/* This function returns the size of new_list */ +/* If either list being copied or new list is NULL, then retunrs -1 */ +/* If pair is less than 1 returns -1 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (new_list == (char *) NULL) || (pair < 1) ) + return -1; + + while ( p < pair ) { + new_list[i] = xa_list[i]; + if ( xa_list[i] == '\0') { + p++; + } + i++; + } + + return i; +} diff -urpN unzip-5.51.orig/zipinfo.c unzip-5.51/zipinfo.c --- unzip-5.51.orig/zipinfo.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/zipinfo.c 2005-10-24 16:09:09.000000000 -0500 @@ -330,6 +330,8 @@ static ZCONST char Far efMD5[] = "Fred K static ZCONST char Far efASiUnix[] = "ASi Unix"; static ZCONST char Far efTandem[] = "Tandem NSK"; static ZCONST char Far efTheos[] = "Theos"; +static ZCONST char Far efXAname[] = "xattr name"; +static ZCONST char Far efXAvalue[] = "xattr value"; static ZCONST char Far efUnknown[] = "unknown"; static ZCONST char Far OS2EAs[] = ".\n\ @@ -935,6 +937,9 @@ static int zi_long(__G__ pEndprev) /* #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif int error, error_in_archive=PK_COOL; unsigned hostnum, hostver, extnum, extver, methnum, xattr; char workspace[12], attribs[22]; @@ -1076,7 +1081,12 @@ static int zi_long(__G__ pEndprev) /* G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0 or Macintosh */ @@ -1422,6 +1432,12 @@ static int zi_long(__G__ pEndprev) /* #endif ef_fieldname = efTheos; break; + case EF_XA_NAME: + ef_fieldname = efXAname; + break; + case EF_XA_VALUE: + ef_fieldname = efXAvalue; + break; default: ef_fieldname = efUnknown; break; @@ -1755,6 +1771,9 @@ static int zi_short(__G) /* return PK- iztimes z_utime; time_t *z_modtim; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif int k, error, error_in_archive=PK_COOL; unsigned hostnum, hostver, methnum, xattr; char *p, workspace[12], attribs[16]; @@ -2053,7 +2072,12 @@ static int zi_short(__G) /* return PK- G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME) ? &z_utime.mtime : NULL; TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0 or Macintosh */ From jayendren at hivsa.com Tue Oct 25 08:29:19 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Tue, 25 Oct 2005 10:29:19 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <435CEBC3.6070207@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> Message-ID: <435DECDF.20906@hivsa.com> Thanks for you help, again! Here is the output: [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* You have mail in /var/spool/mail/jay [root at shiva jay]# [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin -rwxr-xr-x root root system_u:object_r:bin_t squidclamav I will reboot, and check the system as it starts up. Currently, i use system-config-securitylevel to re-enable squid. Which file can i edit to do this from the command line? God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> Thank for your response, i really appreciate it. >> >> Squid clam binary is located in: >> >> /usr/local/squidclamav/bin >> >> >> I isssue: >> >> [root at shiva jay]# chcon -t bin_t *`which /usr/local/squidclamav/bin/` >> >> and get error: > > Just enter > > chcon -t bin_t /usr/local/squidclamav/bin/* > > But the relabel should have done that for you. > > ls -lZ /usr/local/squidclamav/bin > > Should show files marked as bin_t. Now turn on squid (IE change the > boolean and restart the service). > > What AVC messages are you seeing now? > > Dan > > > No the > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From goeran at uddeborg.se Tue Oct 25 09:38:48 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Tue, 25 Oct 2005 11:38:48 +0200 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <435CF3C8.6040401@redhat.com> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> Message-ID: <17245.64808.230382.630915@freddi.uddeborg.se> Daniel J Walsh writes: > do you have the nfs booleans turned on? Yes I do: freddi$ getsebool -a | grep nfs_export nfs_export_all_ro --> active nfs_export_all_rw --> active freddi$ And I CAN export another filesystem from the same machine. A regular ext3 filesystem. So NFS as such is working fine. It is only this filesystem I have problems with. I ASSUMED it was because it is an NTFS filesystem, with an dosfs_t type. From linux_4ever at yahoo.com Tue Oct 25 13:18:27 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 25 Oct 2005 06:18:27 -0700 (PDT) Subject: Rotate audit log? In-Reply-To: <435D1718.50004@mindspring.com> Message-ID: <20051025131827.4900.qmail@web51502.mail.yahoo.com> >Is there something other than the size of the logfile that can be used >to cause the rotation? Not at this point. Would you need this to archive files or to reduce disk space consumption? I'm curious about what problem this would alleviate. >Would an RFE for a command to the deamon to cause a rotation be appropriate? Not necessarily. Just tell me why you want this and I might be able to put it in. -Steve __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From dwalsh at redhat.com Tue Oct 25 14:55:34 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Oct 2005 10:55:34 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <435DECDF.20906@hivsa.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> Message-ID: <435E4766.5010902@redhat.com> Jayendren Anand Maduray wrote: > Thanks for you help, again! > > Here is the output: > > [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* > You have mail in /var/spool/mail/jay > [root at shiva jay]# > [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin > -rwxr-xr-x root root system_u:object_r:bin_t > squidclamav > > > I will reboot, and check the system as it starts up. > > Currently, i use system-config-securitylevel to re-enable squid. > > Which file can i edit to do this from the command line? setsebool and getsebool are command line tools for manipulating booleans setsebool -P squid_disable_trans=1 Enables SELinux enforcement and writes this to the defaults file /etc/selinux/SELINUXTYPE/booleans.local -- From dwalsh at redhat.com Tue Oct 25 16:00:24 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Oct 2005 12:00:24 -0400 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <17245.64808.230382.630915@freddi.uddeborg.se> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> Message-ID: <435E5698.2050004@redhat.com> G?ran Uddeborg wrote: > Daniel J Walsh writes: > >> do you have the nfs booleans turned on? >> > > Yes I do: > > freddi$ getsebool -a | grep nfs_export > nfs_export_all_ro --> active > nfs_export_all_rw --> active > freddi$ > > And I CAN export another filesystem from the same machine. A regular > ext3 filesystem. So NFS as such is working fine. It is only this > filesystem I have problems with. I ASSUMED it was because it is an > NTFS filesystem, with an dosfs_t type. > Ok what version of policy are you running. Running this through audit2why says that it should be allowed? Dan -- From goeran at uddeborg.se Tue Oct 25 17:10:38 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Tue, 25 Oct 2005 19:10:38 +0200 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <435E5698.2050004@redhat.com> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> <435E5698.2050004@redhat.com> Message-ID: <17246.26382.836602.117516@freddi.uddeborg.se> Daniel J Walsh writes: > Ok what version of policy are you running. selinux-policy-targeted-1.27.1-2.6 selinux-policy-targeted-sources-1.27.1-2.6 > Running this through audit2why says that it should be allowed? I hadn't discovered audit2why before! Handy! When I try it, it says freddi$ audit2why < ntfs-audit type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input. Running audit2allow (of course) gives "allow nfsd_t dosfs_t:dir getattr". So I tried grep 'nfsd_t.*dosfs_t.*getattr' /etc/selinux/targeted/src/policy/policy.conf and it gave me nothing. From Jack.Allen at McKesson.com Tue Oct 25 17:48:59 2005 From: Jack.Allen at McKesson.com (Allen, Jack) Date: Tue, 25 Oct 2005 13:48:59 -0400 Subject: New prompt at login time Message-ID: I have posted this on the redhat-list and the pam-list an no one responded. So I am trying here. Hopefully someone will have something to say that will help. I ran up2date yesterday (now a few days ago) and have my system completely up to date. I rebooted this morning (now a few days ago) and now when I login via telnet, yes that is just plain old telnet, not ssh, I get the following: ======== Red Hat Enterprise Linux AS release 4 (Nahant Update 2) Kernel 2.6.9-22.ELsmp on an i686 login: jca Password: Your default context is user_u:system_r:unconfined_t. Do you want to choose a different one? [n] ======== I just entered a CR and thought this would be a one time things. But it is not. While the prompt was being displayed I did a who and it does not show me logged in yet. I did a ps -ef | grep log and see a login process with the host name and -p option. So it appears the prompt is coming from the login program or its calls to some PAM routine. Does anybody know where this is controlled so I can set a default and not be prompted each time? Also exactly what is this controlling? If I do id, it shows context=user_u:system_r:unconfined_t Some things I have been able to find out and more questions. I did man -k context and discovered the get_default_context routine. Doing man get_default_context tells me about get_default_context_list get_ordered_context_list queries the SE Linux policy database in the kernel and some configuration files to determine an ordered list of contexts that may be used for login sessions. The list must be freed with freeconary. The possible roles and domains will be read from /etc/security/default_contexts and .default_contexts in the home directory of the user in question. My question now is what is the format of the files listed above? manual_user_enter_context allows the user to manually enter a context as a fallback if a list of authorized contexts could not be obtained. Caller must free via freecon. So I assume this is why I am getting prompted. I found default_contexts in /etc/selinux/targeted/contexts and it contains: system_r:unconfined_t system_r:unconfined_t I also found that if I removed the multiple option for pam_selinux.so, in remote located in /etc/pam.d, I do not get the prompt. So is this the correct place to correct this? That is the next time I run up2date and there is an update to remote is it going to get replaced and I will have to remove it again? Or is there another place that controls this that would be better to change. Thanks: Jack Allen -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Tue Oct 25 20:29:39 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Oct 2005 16:29:39 -0400 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <17246.26382.836602.117516@freddi.uddeborg.se> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> <435E5698.2050004@redhat.com> <17246.26382.836602.117516@freddi.uddeborg.se> Message-ID: <435E95B3.4000902@redhat.com> G?ran Uddeborg wrote: > Daniel J Walsh writes: > >> Ok what version of policy are you running. >> > > selinux-policy-targeted-1.27.1-2.6 > selinux-policy-targeted-sources-1.27.1-2.6 > > >> Running this through audit2why says that it should be allowed? >> > > I hadn't discovered audit2why before! Handy! > > When I try it, it says > > freddi$ audit2why < ntfs-audit > type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir > Was caused by: > Missing or disabled TE allow rule. > Allow rules may exist but be disabled by boolean settings; check boolean settings. > You can see the necessary allow rules by running audit2allow with this audit message as input. > > Running audit2allow (of course) gives "allow nfsd_t dosfs_t:dir getattr". > So I tried > > grep 'nfsd_t.*dosfs_t.*getattr' /etc/selinux/targeted/src/policy/policy.conf > > and it gave me nothing. > It is getting it via an attribute of dosfs_t On policy-1.27.1-2.10 I get ... grep nfs.*noexattr policy.conf allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr lock search ioctl }; allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr lock search ioctl }; grep dosfs.*noexattr policy.conf type dosfs_t, fs_type, noexattrfile, sysadmfile; -- From dwalsh at redhat.com Tue Oct 25 20:31:30 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Oct 2005 16:31:30 -0400 Subject: New prompt at login time In-Reply-To: References: Message-ID: <435E9622.4050706@redhat.com> Allen, Jack wrote: > > I have posted this on the redhat-list and the pam-list an no > one responded. So I am trying here. Hopefully someone will have > something to say that will help. > > I ran up2date yesterday (now a few days ago) and have my > system completely up to > date. I rebooted this morning (now a few days ago) and now when I > login via telnet, yes that > is just plain old telnet, not ssh, I get the following: > Remove multiple for pam_selinux in /etc/pam.d/* > > > ======== > Red Hat Enterprise Linux AS release 4 (Nahant Update 2) > Kernel 2.6.9-22.ELsmp on an i686 > login: jca > Password: > Your default context is user_u:system_r:unconfined_t. > Do you want to choose a different one? [n] > ======== > I just entered a CR and thought this would be a one time things. But it > is not. While the prompt was being displayed I did a who and it does not > show me logged in yet. I did a ps -ef | grep log and see a login process > with the host name and -p option. So it appears the prompt is coming > from the login program or its calls to some PAM routine. > Does anybody know where this is controlled so I can set a > default and not be prompted each time? > Also exactly what is this controlling? > If I do id, it shows context=user_u:system_r:unconfined_t > Some things I have been able to find out and more questions. > I did man -k context and discovered the get_default_context routine. Doing > man get_default_context tells me about get_default_context_list > get_ordered_context_list queries the SE Linux policy database in the > kernel and some configuration files to determine an ordered list of > contexts that may be used for login sessions. The list must be freed > with freeconary. The possible roles and domains will be read from > /etc/security/default_contexts and .default_contexts in the home > directory of the user in question. > My question now is what is the format of the files listed above? > manual_user_enter_context allows the user to manually enter a context > as a fallback if a list of authorized contexts could not be obtained. > Caller must free via freecon. > So I assume this is why I am getting prompted. > I found default_contexts in /etc/selinux/targeted/contexts and it > contains: > system_r:unconfined_t system_r:unconfined_t > I also found that if I removed the multiple option for pam_selinux.so, > in remote located in /etc/pam.d, I do not get the prompt. So is this > the correct place to correct this? That is the next time I run up2date > and there is an update to remote is it going to get replaced and I > will have to remove it again? Or is there another place that controls > this that would be better to change. > > Thanks: > Jack Allen > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From jayendren at hivsa.com Wed Oct 26 06:55:16 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Wed, 26 Oct 2005 08:55:16 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <435E4766.5010902@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> Message-ID: <435F2854.9020709@hivsa.com> wow! thanks. SELinux rocks, still got a lot to learn though.... God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> Thanks for you help, again! >> >> Here is the output: >> >> [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* >> You have mail in /var/spool/mail/jay >> [root at shiva jay]# >> [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin >> -rwxr-xr-x root root system_u:object_r:bin_t >> squidclamav >> >> >> I will reboot, and check the system as it starts up. >> >> Currently, i use system-config-securitylevel to re-enable squid. >> >> Which file can i edit to do this from the command line? > > setsebool and getsebool are command line tools for manipulating booleans > > setsebool -P squid_disable_trans=1 > > Enables SELinux enforcement and writes this to the defaults file > > /etc/selinux/SELINUXTYPE/booleans.local > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From goeran at uddeborg.se Wed Oct 26 07:10:38 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Wed, 26 Oct 2005 09:10:38 +0200 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <435E95B3.4000902@redhat.com> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> <435E5698.2050004@redhat.com> <17246.26382.836602.117516@freddi.uddeborg.se> <435E95B3.4000902@redhat.com> Message-ID: <17247.11246.292975.578629@mimmi.uddeborg.se> Daniel J Walsh writes: > It is getting it via an attribute of dosfs_t > allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr > lock search ioctl }; > type dosfs_t, fs_type, noexattrfile, sysadmfile; Hm, right. Looks like it should work then. These allows are guarded by the nfs_export booleans as you mentioned, but they are both active, so that should be ok. Seem like something is broken in my installation after all then. I thought I checked that first, but I'll double check. From smooge at gmail.com Wed Oct 26 15:16:03 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 26 Oct 2005 09:16:03 -0600 Subject: Rotate audit log? In-Reply-To: <20051025131827.4900.qmail@web51502.mail.yahoo.com> References: <435D1718.50004@mindspring.com> <20051025131827.4900.qmail@web51502.mail.yahoo.com> Message-ID: <80d7e4090510260816x5bb06bb9w2f3c7e176413a3ff@mail.gmail.com> On 10/25/05, Steve G wrote: > > >Is there something other than the size of the logfile that can be used > >to cause the rotation? > > Not at this point. Would you need this to archive files or to reduce disk space > consumption? I'm curious about what problem this would alleviate. > The problems I can see are: 1) A set policy of log rotation. One area I know of needs to be able to rotate the logs every 24 hours so that they can be archived on a special media. 2) The audit logs are huge and stick out as a visual eye popper if you are looking in /var/log. The standard training for a sysadmin is to look for files that are largers than a certain size and look through them for problems. 3) Some Incremental backup programs can go wonky on large text files. This shows up a lot on remote backups where the backup is done via a seek through the file to see where the changes are. [some of these programs could use the minimal rsync algorithms..] but they seem to be things that sites with policies have to work around versus getting a fix. -- Stephen J Smoogen. CSIRT/Linux System Administrator From paul at city-fan.org Wed Oct 26 15:21:48 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Oct 2005 16:21:48 +0100 Subject: pptp & pppd_devpts_t Message-ID: <435F9F0C.6080701@city-fan.org> Having rebooted into kernel 2.6.13-1.1532_FC4 at the weekend, I found that I couldn't get a connection to my ISP (using pptp) until I added the following rule: allow pptp_t pppd_devpts_t:chr_file { read write }; I can't figure out what has changed that makes this necessary; pptp was working just fine until the reboot. (the machine had not been rebooted for several weeks so it's not easy to tell which policy or kernel update actually introduced this issue) Any ideas? Paul. From mjs at ces.clemson.edu Wed Oct 26 16:41:25 2005 From: mjs at ces.clemson.edu (Matthew Saltzman) Date: Wed, 26 Oct 2005 12:41:25 -0400 (EDT) Subject: Rotate audit log? In-Reply-To: <80d7e4090510260816x5bb06bb9w2f3c7e176413a3ff@mail.gmail.com> References: <435D1718.50004@mindspring.com> <20051025131827.4900.qmail@web51502.mail.yahoo.com> <80d7e4090510260816x5bb06bb9w2f3c7e176413a3ff@mail.gmail.com> Message-ID: On Wed, 26 Oct 2005, Stephen J. Smoogen wrote: > On 10/25/05, Steve G wrote: >> >>> Is there something other than the size of the logfile that can be used >>> to cause the rotation? >> >> Not at this point. Would you need this to archive files or to reduce disk space >> consumption? I'm curious about what problem this would alleviate. >> > > The problems I can see are: > > 1) A set policy of log rotation. One area I know of needs to be able > to rotate the logs every 24 hours so that they can be archived on a > special media. > 2) The audit logs are huge and stick out as a visual eye popper if you > are looking in /var/log. The standard training for a sysadmin is to > look for files that are largers than a certain size and look through > them for problems. The "principle of least surprise" would seem to dictate that audit log rotation follow the standard policy for logrotate, rotating nightly or weekly. The failure of audit.log to follow that policy is what prompted my question in the first place. > 3) Some Incremental backup programs can go wonky on large text files. > This shows up a lot on remote backups where the backup is done via a > seek through the file to see where the changes are. [some of these > programs could use the minimal rsync algorithms..] but they seem to be > things that sites with policies have to work around versus getting a > fix. > > > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > > > -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dpaul at gmx.net Wed Oct 26 17:34:40 2005 From: dpaul at gmx.net (Daniel Paul) Date: Wed, 26 Oct 2005 19:34:40 +0200 (MEST) Subject: SElinux activation on FC3 to FC4 update Message-ID: <18141.1130348080@www11.gmx.net> Hello, I recently upgraded on of our FC3 boxes to FC3 via the normal update procedure. Despite of the FC3 installation wizard the FC4 wizard didn't ask me if I wanted to activate the SElinux feature. What is the preferred way to activate the SElinux layer on a normal FC4 system? Do I simply install the selinux-policy-targeted package? Thank you in advance, Daniel Paul From paul at city-fan.org Wed Oct 26 18:12:42 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 26 Oct 2005 19:12:42 +0100 Subject: SElinux activation on FC3 to FC4 update In-Reply-To: <18141.1130348080@www11.gmx.net> References: <18141.1130348080@www11.gmx.net> Message-ID: <1130350363.3668.136.camel@laurel.intra.city-fan.org> On Wed, 2005-10-26 at 19:34 +0200, Daniel Paul wrote: > I recently upgraded on of our FC3 boxes to FC3 via the normal update > procedure. Despite of the FC3 installation wizard the FC4 wizard didn't ask > me if I wanted to activate the SElinux feature. What is the preferred way to > activate the SElinux layer on a normal FC4 system? Do I simply install the > selinux-policy-targeted package? Install that and run system-config-securitylevel (which you may also need to install). Paul. -- Paul Howarth From dwalsh at redhat.com Wed Oct 26 18:52:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Oct 2005 14:52:32 -0400 Subject: Red Hat Government Users Conference. Message-ID: <435FD070.10603@redhat.com> FYI: James and I will be speaking on SELinux next week at the Red Hat Government Users Conference in Washington DC. http://www.dlt.com/rhguc/ I will be giving an overview of SELinux talk and a James and I will be running BOF on SELinux. If you are at the conference stop by and say hello. Dan -- From vladimir at acm.org Wed Oct 26 19:23:41 2005 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Wed, 26 Oct 2005 12:23:41 -0700 Subject: SELinux errors: invalid context & inode_doinit_with_dentry: context_to_sid() returned 22 Message-ID: <200510261923.j9QJNfkm007813@bach.leonora.org> I posted this message to the fedora-list mailing list, but I haven't as of yet gotten any answer. Could someone here shed some light on the errors I'm seeing? Thanks. --- Vladimir To: fedora-list at redhat.com Date: Wed, 26 Oct 2005 00:30:15 -0700 Subject: SELinux errors I'm getting lots of errors like: /etc/selinux/targeted/contexts/files/file_contexts: line 1851 has invalid context system_u:object_r:texrel_shlib_t /etc/selinux/targeted/contexts/files/file_contexts.homedirs: line 14 has invalid context user_u:object_r:user_home_dir_t when I run "rpm -V selinux-policy-targeted". (As far as I can tell, every non-null, non-comment line in /etc/..../files/* generates an error.) In my syslog I have thousands of errors like: Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=1145588 Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=266929 which I assume are related. I've tried reinstalling the RPMs selinux-policy-targeted and selinux-policy-targeted-sources, and then booting with selinux=0, running "fixfiles relabel" and then rebooting normally. No change. I've tried googling, but I didn't find anything. Any advice (other than turning SELinux off)? Thanks. --- Vladimir kernel-smp-2.6.13-1.1532_FC4 checkpolicy-1.23.1-1 libselinux-1.26-1 libselinux-devel-1.26-1 policycoreutils-1.27.2-1.2 selinux-doc-1.19.5-1 selinux-policy-strict-1.27.1-2.6 selinux-policy-strict-sources-1.27.1-2.6 selinux-policy-targeted-1.27.1-2.6 selinux-policy-targeted-sources-1.27.1-2.6 setools-2.1.2-1.1 -- Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 From dwalsh at redhat.com Wed Oct 26 19:36:44 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Oct 2005 15:36:44 -0400 Subject: SELinux errors: invalid context & inode_doinit_with_dentry: context_to_sid() returned 22 In-Reply-To: <200510261923.j9QJNfkm007813@bach.leonora.org> References: <200510261923.j9QJNfkm007813@bach.leonora.org> Message-ID: <435FDACC.10302@redhat.com> Vladimir G. Ivanovic wrote: > I posted this message to the fedora-list mailing list, but I haven't > as of yet gotten any answer. Could someone here shed some light on the > errors I'm seeing? > > Thanks. > > --- Vladimir > > To: fedora-list at redhat.com > Date: Wed, 26 Oct 2005 00:30:15 -0700 > Subject: SELinux errors > > I'm getting lots of errors like: > > /etc/selinux/targeted/contexts/files/file_contexts: line 1851 has invalid context system_u:object_r:texrel_shlib_t > /etc/selinux/targeted/contexts/files/file_contexts.homedirs: line 14 has invalid context user_u:object_r:user_home_dir_t > > when I run "rpm -V selinux-policy-targeted". (As far as I can tell, > every non-null, non-comment line in /etc/..../files/* generates an > error.) > > In my syslog I have thousands of errors like: > > Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=1145588 > Oct 26 00:21:16 bach kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:policy_src_t:s0) returned 22 for dev=sda4 ino=266929 > > which I assume are related. > > I've tried reinstalling the RPMs selinux-policy-targeted and > selinux-policy-targeted-sources, and then booting with selinux=0, > running "fixfiles relabel" and then rebooting normally. No change. > > I've tried googling, but I didn't find anything. Any advice (other > than turning SELinux off)? > > Thanks. > > --- Vladimir > > kernel-smp-2.6.13-1.1532_FC4 > > checkpolicy-1.23.1-1 > libselinux-1.26-1 > libselinux-devel-1.26-1 > policycoreutils-1.27.2-1.2 > selinux-doc-1.19.5-1 > selinux-policy-strict-1.27.1-2.6 > selinux-policy-strict-sources-1.27.1-2.6 > selinux-policy-targeted-1.27.1-2.6 > selinux-policy-targeted-sources-1.27.1-2.6 > setools-2.1.2-1.1 > > You have a mismatch of FC4 policy with an FC5 libselinux. Basically you are running in a mode that thinks it should have MCS turned on. You need to revert back to an older libselinux. -- From goeran at uddeborg.se Wed Oct 26 21:05:05 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Wed, 26 Oct 2005 23:05:05 +0200 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <17247.11246.292975.578629@mimmi.uddeborg.se> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> <435E5698.2050004@redhat.com> <17246.26382.836602.117516@freddi.uddeborg.se> <435E95B3.4000902@redhat.com> <17247.11246.292975.578629@mimmi.uddeborg.se> Message-ID: <17247.61313.846723.739318@freddi.uddeborg.se> G?ran Uddeborg writes: > Seem like something is broken in my installation after all then. I > thought I checked that first, but I'll double check. My fault all the time apparently. It works now. I'm not sure exactly what was wrong. But when I forced a regeneration of things it started to work. In the process I did notice one thing worth mentioning. In the postinstall script of selinux-policy-targeted-sources there is a command make -C /etc/selinux/targeted/src/policy -W /etc/selinux/targeted/src/policy/users load > /dev/null 2>&1 1. The -W flag needs the STRING found as a target in the Makefile. The above will have no effect. The desired effect is achieved by "-W users", without the path. 2. Is it really a good idea to throw away standard error? If the command is successful it writes everything to standard out. And if something fails it could be interesting to know about it. Maybe you want me to bugzilla these? From filter at stevenstromer.com Wed Oct 26 21:10:27 2005 From: filter at stevenstromer.com (Steven Stromer) Date: Wed, 26 Oct 2005 17:10:27 -0400 Subject: AWStats In-Reply-To: References: <1127751563.4995.8.camel@host124.murray.rudolphtire.com> Message-ID: Hi, A few weeks ago, I brought up a problem I was having with SELinux and AWStats. I am hoping that someone may be able to help. From my original post: > There exists an option in > the web reporting pages called 'Update Now'. It allows you to update > reports from the web server's logs without performing the log parsing > from the command line. You must change the directive > 'AllowToUpdateStatsFromBrowser' from 0 to 1 in your awstats .conf file > to activate this practical feature. However, I have understand that the > web-based update process needs access to the system's httpd access_log > file (usually in /var/log/httpd). I have changed permissions on this > file to httpd_sys_script_ra_t, but it was not sufficient to make the > update feature work. Also, the awstats.pl file has permissions: -rwxr-xr-x root root system_u:object_r:htpd_sys_script_exec_t awstats.pl I can generate reports from the command line with no problem, but the web based tool returns an error saying that I do not have proper permissions. I found one reference to another user having the same problem. The posting is minimal, but implies that 'touch /.autorelabel && shutdown -r now' fixed the problem. I basically understand what this command is intended to do, but I am concerned that executing it might do more damage to files that I've chcon'ed in the past, than it will fix. Any advise would be much appreciated. Please help! Steven Stromer From linux_4ever at yahoo.com Wed Oct 26 21:28:41 2005 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 26 Oct 2005 14:28:41 -0700 (PDT) Subject: Rotate audit log? In-Reply-To: <80d7e4090510260816x5bb06bb9w2f3c7e176413a3ff@mail.gmail.com> Message-ID: <20051026212841.62245.qmail@web51511.mail.yahoo.com> >1) A set policy of log rotation. One area I know of needs to be able >to rotate the logs every 24 hours so that they can be archived on a >special media. This sounds like a good reason. Consider it done. I'll schedule this feature for something in the 1.1.x development series. Thanks, -Steve __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com From dwalsh at redhat.com Thu Oct 27 02:45:55 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Oct 2005 22:45:55 -0400 Subject: Exporting NTFS filesystems over NFS In-Reply-To: <17247.61313.846723.739318@freddi.uddeborg.se> References: <17242.37395.490964.418390@freddi.uddeborg.se> <435CF3C8.6040401@redhat.com> <17245.64808.230382.630915@freddi.uddeborg.se> <435E5698.2050004@redhat.com> <17246.26382.836602.117516@freddi.uddeborg.se> <435E95B3.4000902@redhat.com> <17247.11246.292975.578629@mimmi.uddeborg.se> <17247.61313.846723.739318@freddi.uddeborg.se> Message-ID: <43603F63.7090609@redhat.com> G?ran Uddeborg wrote: > G?ran Uddeborg writes: > >> Seem like something is broken in my installation after all then. I >> thought I checked that first, but I'll double check. >> > > My fault all the time apparently. It works now. I'm not sure exactly > what was wrong. But when I forced a regeneration of things it started > to work. > > In the process I did notice one thing worth mentioning. In the > postinstall script of selinux-policy-targeted-sources there is a > command > > make -C /etc/selinux/targeted/src/policy -W /etc/selinux/targeted/src/policy/users load > /dev/null 2>&1 > > 1. The -W flag needs the STRING found as a target in the Makefile. > The above will have no effect. The desired effect is achieved by > "-W users", without the path. > > 2. Is it really a good idea to throw away standard error? If the > command is successful it writes everything to standard out. And if > something fails it could be interesting to know about it. > > Maybe you want me to bugzilla these? > No I fixed both. -- From dwalsh at redhat.com Thu Oct 27 02:50:11 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Oct 2005 22:50:11 -0400 Subject: AWStats In-Reply-To: References: <1127751563.4995.8.camel@host124.murray.rudolphtire.com> Message-ID: <43604063.3030000@redhat.com> Steven Stromer wrote: > Hi, > > A few weeks ago, I brought up a problem I was having with SELinux and > AWStats. I am hoping that someone may be able to help. From my > original post: > >> There exists an option in the web reporting pages called 'Update >> Now'. It allows you to update reports from the web server's logs >> without performing the log parsing from the command line. You must >> change the directive 'AllowToUpdateStatsFromBrowser' from 0 to 1 in >> your awstats .conf file to activate this practical feature. However, >> I have understand that the web-based update process needs access to >> the system's httpd access_log file (usually in /var/log/httpd). I >> have changed permissions on this file to httpd_sys_script_ra_t, but >> it was not sufficient to make the update feature work. > > Also, the awstats.pl file has permissions: > -rwxr-xr-x root root system_u:object_r:htpd_sys_script_exec_t awstats.pl > > I can generate reports from the command line with no problem, but the > web based tool returns an error saying that I do not have proper > permissions. > > I found one reference to another user having the same problem. The > posting is minimal, but implies that 'touch /.autorelabel && shutdown > -r now' fixed the problem. I basically understand what this command is > intended to do, but I am concerned that executing it might do more > damage to files that I've chcon'ed in the past, than it will fix. > > Any advise would be much appreciated. Please help! What avc messages are you seeing? You should not need to relabel. But one file may be mislabeled or the policy may not allow it. Look in /var/log/messages or /var/log/audit/audit.log for avc message. > > Steven Stromer > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From vladimir at acm.org Thu Oct 27 03:34:11 2005 From: vladimir at acm.org (Vladimir G. Ivanovic) Date: Wed, 26 Oct 2005 20:34:11 -0700 Subject: SELinux errors: invalid context & inode_doinit_with_dentry: context_to_sid() returned 22 In-Reply-To: Your message of "Wed, 26 Oct 2005 15:36:44 EDT." <435FDACC.10302@redhat.com> Message-ID: <200510270334.j9R3YBFW010095@bach.leonora.org> Bingo! (Thanks.) Note to self: When replacing *important* libraries like libselinux.so, don't just blast the unwanted RPM package away, figuring on then installing the new one. Instead, use --oldpackage or --force to replace the unwanted package with the desired one in atomic operation. Failure to do so will make both rpm and yum (and many other programs) unusable. --- Vladimir -- Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 >>>>> "djw" == Daniel J Walsh writes: djw> You have a mismatch of FC4 policy with an FC5 libselinux. Basically djw> you are running in a mode that thinks it should have djw> MCS turned on. You need to revert back to an older libselinux. From jayendren at hivsa.com Thu Oct 27 06:20:23 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Thu, 27 Oct 2005 08:20:23 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <435E4766.5010902@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> Message-ID: <436071A7.5050805@hivsa.com> Hi! Just noticed more errors! Here is the output: audit(1130392269.590:0): avc: denied { append } for pid=3218 exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t tclass=file audit(1130392269.590:0): avc: denied { append } for pid=3218 exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t tclass=file audit(1130392270.019:0): avc: denied { getattr } for pid=3218 exe=/usr/sbin/squid path=/usr/local/squidclamav/bin/squidclamav dev=hda8 ino=185872 scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t tclass=file Also: [root at shiva jay]# ls -lZ /var/log/squid/ -rw-r--r-- squid squid system_u:object_r:bin_t access.log -rw-r--r-- squid squid system_u:object_r:bin_t cache.log -rw-r--r-- squid squid system_u:object_r:bin_t squid.out -rw-r--r-- squid squid system_u:object_r:bin_t store.log [root at shiva jay]# service squid restart Stopping squid: /etc/init.d/squid: line 82: 5108 Aborted $SQUID -k check >>/var/log/squid/squid.out 2>&1 [FAILED] Starting squid: /etc/init.d/squid: line 53: 5109 Aborted $SQUID $SQUID_OPTS >>/var/log/squid/squid.out 2>&1 [FAILED] Please note that i re-enabled SElinux for squid via system-config-security in FC3. Any help will be appreciated. God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> Thanks for you help, again! >> >> Here is the output: >> >> [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* >> You have mail in /var/spool/mail/jay >> [root at shiva jay]# >> [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin >> -rwxr-xr-x root root system_u:object_r:bin_t >> squidclamav >> >> >> I will reboot, and check the system as it starts up. >> >> Currently, i use system-config-securitylevel to re-enable squid. >> >> Which file can i edit to do this from the command line? > > setsebool and getsebool are command line tools for manipulating booleans > > setsebool -P squid_disable_trans=1 > > Enables SELinux enforcement and writes this to the defaults file > > /etc/selinux/SELINUXTYPE/booleans.local > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From db-fedora at 3di.it Thu Oct 27 07:36:53 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 27 Oct 2005 09:36:53 +0200 Subject: SELinux errors: invalid context & inode_doinit_with_dentry: context_to_sid() returned 22 In-Reply-To: <200510270334.j9R3YBFW010095@bach.leonora.org> References: <200510270334.j9R3YBFW010095@bach.leonora.org> Message-ID: <43608395.1020406@3di.it> Vladimir G. Ivanovic wrote: > Note to self: When replacing *important* libraries like libselinux.so, > don't just blast the unwanted RPM package away, figuring on then > installing the new one. Instead, use --oldpackage or --force to > replace the unwanted package with the desired one in atomic operation. > Failure to do so will make both rpm and yum (and many other programs) > unusable. Is the above advisable ? Does this mean that "rpm -U" or even "yum update" would be inappropriate ? Davide Bolcioni From dwalsh at redhat.com Thu Oct 27 13:31:04 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Oct 2005 09:31:04 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <436071A7.5050805@hivsa.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> <436071A7.5050805@hivsa.com> Message-ID: <4360D698.7070504@redhat.com> Jayendren Anand Maduray wrote: > Hi! > > Just noticed more errors! > > Here is the output: > > audit(1130392269.590:0): avc: denied { append } for pid=3218 > exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 > scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t > tclass=file > audit(1130392269.590:0): avc: denied { append } for pid=3218 > exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 > scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t > tclass=file > audit(1130392270.019:0): avc: denied { getattr } for pid=3218 > exe=/usr/sbin/squid path=/usr/local/squidclamav/bin/squidclamav > dev=hda8 ino=185872 scontext=user_u:system_r:squid_t > tcontext=system_u:object_r:bin_t tclass=file Looks like you labeled /var/log/squid incorrectly. restorecon -R -v /var/log > > > Also: > > [root at shiva jay]# ls -lZ /var/log/squid/ > -rw-r--r-- squid squid system_u:object_r:bin_t access.log > -rw-r--r-- squid squid system_u:object_r:bin_t cache.log > -rw-r--r-- squid squid system_u:object_r:bin_t squid.out > -rw-r--r-- squid squid system_u:object_r:bin_t store.log > > [root at shiva jay]# service squid restart > > Stopping squid: /etc/init.d/squid: line 82: 5108 > Aborted $SQUID -k check >>/var/log/squid/squid.out 2>&1 > [FAILED] > Starting squid: /etc/init.d/squid: line 53: 5109 > Aborted $SQUID $SQUID_OPTS >>/var/log/squid/squid.out > 2>&1 > [FAILED] > > Please note that i re-enabled SElinux for squid via > system-config-security in FC3. > > Any help will be appreciated. > > God bless. > > > Daniel J Walsh wrote: > >> Jayendren Anand Maduray wrote: >> >>> Thanks for you help, again! >>> >>> Here is the output: >>> >>> [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* >>> You have mail in /var/spool/mail/jay >>> [root at shiva jay]# >>> [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin >>> -rwxr-xr-x root root system_u:object_r:bin_t >>> squidclamav >>> >>> >>> I will reboot, and check the system as it starts up. >>> >>> Currently, i use system-config-securitylevel to re-enable squid. >>> >>> Which file can i edit to do this from the command line? >> >> setsebool and getsebool are command line tools for manipulating booleans >> >> setsebool -P squid_disable_trans=1 >> >> Enables SELinux enforcement and writes this to the defaults file >> >> /etc/selinux/SELINUXTYPE/booleans.local >> >> > -- From jayendren at hivsa.com Thu Oct 27 13:48:22 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Thu, 27 Oct 2005 15:48:22 +0200 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <4360D698.7070504@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> <436071A7.5050805@hivsa.com> <4360D698.7070504@redhat.com> Message-ID: <4360DAA6.30906@hivsa.com> Hi! The relabeling was done by touching a /.autorelabel Followed advice, and ran: [root at shiva music]# restorecon -R -v /var/log restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######.log->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/samba/#######->system_u:object_r:var_log_t restorecon reset context /var/log/Xorg.0.log.old->system_u:object_r:var_log_t restorecon reset context /var/log/Xorg.0.log->system_u:object_r:var_log_t restorecon reset context /var/log/squid/store.log->system_u:object_r:squid_log_t restorecon reset context /var/log/squid/access.log->system_u:object_r:squid_log_t restorecon reset context /var/log/squid/cache.log->system_u:object_r:squid_log_t restorecon reset context /var/log/squid/squid.out->system_u:object_r:squid_log_t restorecon reset context /var/log/gdm/:0.log->system_u:object_r:var_log_t restorecon reset context /var/log/gdm/:0.log.3->system_u:object_r:var_log_t restorecon reset context /var/log/gdm/:0.log.1->system_u:object_r:var_log_t restorecon reset context /var/log/gdm/:0.log.2->system_u:object_r:var_log_t restorecon reset context /var/log/gdm/:0.log.4->system_u:object_r:var_log_t [root at shiva music]# ls -lZ /var/log/squid/ -rw-r--r-- squid squid system_u:object_r:squid_log_t access.log -rw-r--r-- squid squid system_u:object_r:squid_log_t cache.log -rw-r--r-- squid squid system_u:object_r:squid_log_t squid.out -rw-r--r-- squid squid system_u:object_r:squid_log_t store.log [root at shiva music]# service squid restart Stopping squid: /etc/init.d/squid: line 82: 8548 Aborted $SQUID -k check >>/var/log/squid/squid.out 2>&1 [FAILED] Starting squid: /etc/init.d/squid: line 53: 8549 Aborted $SQUID $SQUID_OPTS >>/var/log/squid/squid.out 2>&1 [FAILED] [root at shiva music]# dmesg | tail audit(1130420511.344:0): avc: denied { getattr } for pid=8548 exe=/usr/sbin/squid path=/usr/local/squidclamav/bin/squidclamav dev=hda8 ino=185872 scontext=root:system_r:squid_t tcontext=system_u:object_r:bin_t tclass=file audit(1130420511.595:0): avc: denied { getattr } for pid=8549 exe=/usr/sbin/squid path=/usr/local/squidclamav/bin/squidclamav dev=hda8 ino=185872 scontext=root:system_r:squid_t tcontext=system_u:object_r:bin_t tclass=file Some values were hashed out for obvious reasons. Thanks again for your input. It is appreciated. God bless. Daniel J Walsh wrote: > Jayendren Anand Maduray wrote: > >> Hi! >> >> Just noticed more errors! >> >> Here is the output: >> >> audit(1130392269.590:0): avc: denied { append } for pid=3218 >> exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 >> scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t >> tclass=file >> audit(1130392269.590:0): avc: denied { append } for pid=3218 >> exe=/usr/sbin/squid path=/var/log/squid/squid.out dev=hda8 ino=755115 >> scontext=user_u:system_r:squid_t tcontext=system_u:object_r:bin_t >> tclass=file >> audit(1130392270.019:0): avc: denied { getattr } for pid=3218 >> exe=/usr/sbin/squid path=/usr/local/squidclamav/bin/squidclamav >> dev=hda8 ino=185872 scontext=user_u:system_r:squid_t >> tcontext=system_u:object_r:bin_t tclass=file > > Looks like you labeled /var/log/squid incorrectly. restorecon -R -v > /var/log > >> >> >> Also: >> >> [root at shiva jay]# ls -lZ /var/log/squid/ >> -rw-r--r-- squid squid system_u:object_r:bin_t >> access.log >> -rw-r--r-- squid squid system_u:object_r:bin_t cache.log >> -rw-r--r-- squid squid system_u:object_r:bin_t squid.out >> -rw-r--r-- squid squid system_u:object_r:bin_t store.log >> >> [root at shiva jay]# service squid restart >> >> Stopping squid: /etc/init.d/squid: line 82: 5108 >> Aborted $SQUID -k check >>/var/log/squid/squid.out 2>&1 >> [FAILED] >> Starting squid: /etc/init.d/squid: line 53: 5109 >> Aborted $SQUID $SQUID_OPTS >>/var/log/squid/squid.out >> 2>&1 >> [FAILED] >> >> Please note that i re-enabled SElinux for squid via >> system-config-security in FC3. >> >> Any help will be appreciated. >> >> God bless. >> >> >> Daniel J Walsh wrote: >> >>> Jayendren Anand Maduray wrote: >>> >>>> Thanks for you help, again! >>>> >>>> Here is the output: >>>> >>>> [root at shiva jay]# chcon -t bin_t /usr/local/squidclamav/bin/* >>>> You have mail in /var/spool/mail/jay >>>> [root at shiva jay]# >>>> [root at shiva jay]# ls -lZ /usr/local/squidclamav/bin >>>> -rwxr-xr-x root root system_u:object_r:bin_t >>>> squidclamav >>>> >>>> >>>> I will reboot, and check the system as it starts up. >>>> >>>> Currently, i use system-config-securitylevel to re-enable squid. >>>> >>>> Which file can i edit to do this from the command line? >>> >>> >>> setsebool and getsebool are command line tools for manipulating >>> booleans >>> >>> setsebool -P squid_disable_trans=1 >>> >>> Enables SELinux enforcement and writes this to the defaults file >>> >>> /etc/selinux/SELINUXTYPE/booleans.local >>> >>> >> > > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From dwalsh at redhat.com Thu Oct 27 14:15:32 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Oct 2005 10:15:32 -0400 Subject: fedora-selinux-list Digest, Vol 20, Issue 18 In-Reply-To: <4360DAA6.30906@hivsa.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> <436071A7.5050805@hivsa.com> <4360D698.7070504@redhat.com> <4360DAA6.30906@hivsa.com> Message-ID: <4360E104.8020408@redhat.com> What version of policy are you using? rpm -q selinux-policy-targeted The avc you are reporting is allowed in current policy grep -r squid_t.*bin_t policy.conf allow squid_t { lib_t squid_exec_t bin_t sbin_t shell_exec_t } :file { { read getattr lock execute ioctl } execute_no_trans }; -- From filter at stevenstromer.com Thu Oct 27 16:30:18 2005 From: filter at stevenstromer.com (Steven Stromer) Date: Thu, 27 Oct 2005 12:30:18 -0400 Subject: AWStats In-Reply-To: <43604063.3030000@redhat.com> References: <1127751563.4995.8.camel@host124.murray.rudolphtire.com> <43604063.3030000@redhat.com> Message-ID: Daniel J Walsh wrote: > Steven Stromer wrote: > >> Hi, >> >> A few weeks ago, I brought up a problem I was having with SELinux and >> AWStats. I am hoping that someone may be able to help. From my >> original post: >> >>> There exists an option in the web reporting pages called 'Update >>> Now'. It allows you to update reports from the web server's logs >>> without performing the log parsing from the command line. You must >>> change the directive 'AllowToUpdateStatsFromBrowser' from 0 to 1 in >>> your awstats .conf file to activate this practical feature. However, >>> I have understand that the web-based update process needs access to >>> the system's httpd access_log file (usually in /var/log/httpd). I >>> have changed permissions on this file to httpd_sys_script_ra_t, but >>> it was not sufficient to make the update feature work. >> >> >> Also, the awstats.pl file has permissions: >> -rwxr-xr-x root root system_u:object_r:htpd_sys_script_exec_t awstats.pl >> >> I can generate reports from the command line with no problem, but the >> web based tool returns an error saying that I do not have proper >> permissions. >> >> I found one reference to another user having the same problem. The >> posting is minimal, but implies that 'touch /.autorelabel && shutdown >> -r now' fixed the problem. I basically understand what this command is >> intended to do, but I am concerned that executing it might do more >> damage to files that I've chcon'ed in the past, than it will fix. >> >> Any advise would be much appreciated. Please help! > > What avc messages are you seeing? You should not need to relabel. But > one file may be mislabeled or the policy may not allow it. Look in > /var/log/messages or /var/log/audit/audit.log for avc message. I've looked in both logs. Attempting to use the update feature in AWStats does not write any error messages to either of these log files. There are a few avc messages contained in each of the files, but none pertain to this problem. Is there anywhere else I can look, or does this indicated that the problem is not stemming from an SELinux permission problem? Thanks again for the help! From dwalsh at redhat.com Thu Oct 27 20:05:19 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Oct 2005 16:05:19 -0400 Subject: AWStats In-Reply-To: References: <1127751563.4995.8.camel@host124.murray.rudolphtire.com> <43604063.3030000@redhat.com> Message-ID: <436132FF.2050509@redhat.com> Steven Stromer wrote: > Daniel J Walsh wrote: >> Steven Stromer wrote: >> >>> Hi, >>> >>> A few weeks ago, I brought up a problem I was having with SELinux >>> and AWStats. I am hoping that someone may be able to help. From my >>> original post: >>> >>>> There exists an option in the web reporting pages called 'Update >>>> Now'. It allows you to update reports from the web server's logs >>>> without performing the log parsing from the command line. You must >>>> change the directive 'AllowToUpdateStatsFromBrowser' from 0 to 1 in >>>> your awstats .conf file to activate this practical feature. >>>> However, I have understand that the web-based update process needs >>>> access to the system's httpd access_log file (usually in >>>> /var/log/httpd). I have changed permissions on this file to >>>> httpd_sys_script_ra_t, but it was not sufficient to make the update >>>> feature work. >>> >>> >>> Also, the awstats.pl file has permissions: >>> -rwxr-xr-x root root system_u:object_r:htpd_sys_script_exec_t >>> awstats.pl >>> >>> I can generate reports from the command line with no problem, but >>> the web based tool returns an error saying that I do not have proper >>> permissions. >>> >>> I found one reference to another user having the same problem. The >>> posting is minimal, but implies that 'touch /.autorelabel && >>> shutdown -r now' fixed the problem. I basically understand what this >>> command is intended to do, but I am concerned that executing it >>> might do more damage to files that I've chcon'ed in the past, than >>> it will fix. >>> >>> Any advise would be much appreciated. Please help! >> >> What avc messages are you seeing? You should not need to relabel. >> But one file may be mislabeled or the policy may not allow it. Look >> in /var/log/messages or /var/log/audit/audit.log for avc message. > > I've looked in both logs. Attempting to use the update feature in > AWStats does not write any error messages to either of these log > files. There are a few avc messages contained in each of the files, > but none pertain to this problem. Is there anywhere else I can look, > or does this indicated that the problem is not stemming from an > SELinux permission problem? Thanks again for the help! > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Usually you can see if it is an selinux problable, by temporarily turning off selinux protection. setenforce 0 Try you http script. setenforce 1 If it still breaks, it probably is not SELinux fault, if it works, it is probably selinux and you can turn up the auditing by installing policy sources cd /etc/selinux/targeted/src/policy make enableaudit; make load Try it out, Look for avc messages. make clean; make load To reset to less auditing. -- From nicolas.mailhot at laposte.net Thu Oct 27 20:54:33 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 27 Oct 2005 22:54:33 +0200 Subject: Port to use in MTA when communicating with mail filter ? Message-ID: <1130446473.2846.78.camel@rousalka.dyndns.org> Hi, I'm using postfix with the amavid-new spam/virus mail filter. In this type of configuration the MTA sends every processed mail to the filter daemon on one port, and receives the result of the filtering on another. The online documentation is not too clear, but the commonly used ports seem to be on the 10024-10026 range. In my setup the MTA listens on port 10026 and the filter on port 10025. Unfortunately that means the selinux policy in Raw Hide blocks postfix startup: Oct 23 11:56:21 rousalka postfix/master[2076]: fatal: bind 127.0.0.1 port 10026: Permission denied Therefore, I'd like to know: 1. if a port has already been allocated in the Fedora Devel targeted policy for MTA <- filter communication 2. if yes which one is it so I make my installation conformant 3. if not would it be possible to add it? I'm ready to poll the postfix/amavisd-new lists to find out what the canonical port to use would be. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Thu Oct 27 21:37:09 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Oct 2005 17:37:09 -0400 Subject: Port to use in MTA when communicating with mail filter ? In-Reply-To: <1130446473.2846.78.camel@rousalka.dyndns.org> References: <1130446473.2846.78.camel@rousalka.dyndns.org> Message-ID: <43614885.3020108@redhat.com> Nicolas Mailhot wrote: > Hi, > > I'm using postfix with the amavid-new spam/virus mail filter. In this > type of configuration the MTA sends every processed mail to the filter > daemon on one port, and receives the result of the filtering on another. > The online documentation is not too clear, but the commonly used ports > seem to be on the 10024-10026 range. In my setup the MTA listens on port > 10026 and the filter on port 10025. > > Looks like these ports are used by amavisd portcon tcp 10024 system_u:object_r:amavisd_recv_port_t portcon tcp 10025 system_u:object_r:amavisd_send_port_t And reading policy states that postfix can listen on the send port. Are you seeing any avc messages? > Unfortunately that means the selinux policy in Raw Hide blocks postfix > startup: > Oct 23 11:56:21 rousalka postfix/master[2076]: fatal: bind 127.0.0.1 > port 10026: Permission denied > > Therefore, I'd like to know: > 1. if a port has already been allocated in the Fedora Devel targeted > policy for MTA <- filter communication > 2. if yes which one is it so I make my installation conformant > 3. if not would it be possible to add it? I'm ready to poll the > postfix/amavisd-new lists to find out what the canonical port to use > would be. > > Regards, > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From selinux at gmail.com Thu Oct 27 22:58:32 2005 From: selinux at gmail.com (Tom London) Date: Thu, 27 Oct 2005 15:58:32 -0700 Subject: avahi - needs transition? Message-ID: <4c4ba1530510271558k1d2fe63bt6fd272991c682ecd@mail.gmail.com> Running targeted/enforcing, latest rawhide. The avahi-daemon fails to start: Oct 27 14:47:39 localhost avahi-daemon[2279]: Found user 'avahi' (UID 70) and group 'avahi' (GID 70). Oct 27 14:47:39 localhost avahi-daemon[2279]: Successfully dropped root privileges. Oct 27 14:47:39 localhost avahi-daemon[2279]: avahi-daemon 0.5.2 starting up. Oct 27 14:47:39 localhost avahi-daemon[2279]: dbus_bus_get(): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory Works OK in permissive mode, but 'ps -Z' shows the daemon is running in initrc_t. Shouldn't there be a transition to something like howl_t or some such? tom -- Tom London From vikasx.aggarwal at intel.com Fri Oct 28 03:27:49 2005 From: vikasx.aggarwal at intel.com (Aggarwal, VikasX) Date: Thu, 27 Oct 2005 20:27:49 -0700 Subject: Getting "Inappropriate ioctl" :during initrd stage of booting. Message-ID: <69F69FD5FD4A9843ACBF7CE9B7830B4A0630BB87@orsmsx408> Hi, Please tell if there is a way to turn off the selinux after full installation but before first boot. I have a daemon which needs to do ioctl during initrd. daemon + related-driver is already inserted into a new-initrd. Daemon can do ioctl during normal operation of a running machine, but will get "Inappropriate ioctl for device /dev/iscsictl" if built into initrd. Its just a control interface to a software iscsi driver and daemon needs to pass some handler during initrd stage. I already tried passing selinux=0, enforcing=0, disable=1. But looks the selinux policy to disallow ioctl during initrd is built in kernel. I have little knowledge in this area. Will appreciate any ideas for workaround. thanks -vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayendren at hivsa.com Fri Oct 28 06:53:00 2005 From: jayendren at hivsa.com (Jayendren Anand Maduray) Date: Fri, 28 Oct 2005 08:53:00 +0200 Subject: SquidClamAV - SElinux enabled In-Reply-To: <4360E104.8020408@redhat.com> References: <20051020160014.31DF97407D@hormel.redhat.com> <4358BEA6.3010602@hivsa.com> <43591ABA.3070207@redhat.com> <435C7E1F.8060009@hivsa.com> <435CEBC3.6070207@redhat.com> <435DECDF.20906@hivsa.com> <435E4766.5010902@redhat.com> <436071A7.5050805@hivsa.com> <4360D698.7070504@redhat.com> <4360DAA6.30906@hivsa.com> <4360E104.8020408@redhat.com> Message-ID: <4361CACC.7050506@hivsa.com> Good day, sir version: [root at shiva jay]# rpm -qi selinux-policy-targeted Name : selinux-policy-targeted Relocations: /usr Version : 1.17.30 Vendor: Red Hat, Inc. Release : 2.19 Build Date: Mon 01 Nov 2004 23:36:23 SAST Install Date: Thu 21 Apr 2005 20:05:09 SAST Build Host: tweety.build.redhat.com Group : System Environment/Base Source RPM: selinux-policy-targeted-1.17.30-2.19.src.rpm Size : 222858 License: GPL Signature : DSA/SHA1, Tue 02 Nov 2004 18:06:52 SAST, Key ID b44269d04f2a6fd2 Packager : Red Hat, Inc. Summary : SELinux targeted policy configuration This may sound dumb, but what is avc? God bless. Daniel J Walsh wrote: > What version of policy are you using? > > rpm -q selinux-policy-targeted > > The avc you are reporting is allowed in current policy > > grep -r squid_t.*bin_t policy.conf > allow squid_t { lib_t squid_exec_t bin_t sbin_t shell_exec_t } :file { > { read getattr lock execute ioctl } execute_no_trans }; > -- Jayendren Anand Maduray Microsoft Certified Professional Network Plus IT Administrator Perinatal HIV Research Unit Old Potch Road Chris Hani Baragwanath Hospital Soweto South Africa Tel: +27 11 989 9776 Tel: +27 11 989 9999 Fax: +27 11 938 3973 Cel: 082 22 774 94 Alternate email address: jayendren at mweb.co.za From nicolas.mailhot at laposte.net Fri Oct 28 08:12:06 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 10:12:06 +0200 Subject: Port to use in MTA when communicating with mail filter ? In-Reply-To: <43614885.3020108@redhat.com> References: <1130446473.2846.78.camel@rousalka.dyndns.org> <43614885.3020108@redhat.com> Message-ID: <1130487126.8320.8.camel@rousalka.dyndns.org> Le jeudi 27 octobre 2005 ? 17:37 -0400, Daniel J Walsh a ?crit : > Nicolas Mailhot wrote: > > Hi, > > > > I'm using postfix with the amavid-new spam/virus mail filter. In this > > type of configuration the MTA sends every processed mail to the filter > > daemon on one port, and receives the result of the filtering on another. > > The online documentation is not too clear, but the commonly used ports > > seem to be on the 10024-10026 range. In my setup the MTA listens on port > > 10026 and the filter on port 10025. > > Looks like these ports are used by amavisd > portcon tcp 10024 system_u:object_r:amavisd_recv_port_t > portcon tcp 10025 system_u:object_r:amavisd_send_port_t > > And reading policy states that postfix can listen on the send port. > > Are you seeing any avc messages? Ok, thanks, I have an old amavisd install that pre-dates FE packaging, and the amavisd/postfix doc proposed both 10024/10025 and 10025/10026 ports as good setup choices. Since Fedora chose 10024/10025, I'll do the same here. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sds at tycho.nsa.gov Fri Oct 28 11:47:52 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 28 Oct 2005 07:47:52 -0400 Subject: Getting "Inappropriate ioctl" :during initrd stage of booting. In-Reply-To: <69F69FD5FD4A9843ACBF7CE9B7830B4A0630BB87@orsmsx408> References: <69F69FD5FD4A9843ACBF7CE9B7830B4A0630BB87@orsmsx408> Message-ID: <1130500072.18805.397.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-10-27 at 20:27 -0700, Aggarwal, VikasX wrote: > Please tell if there is a way to turn off the selinux after full > installation but before first boot. Booting with selinux=0 disables SELinux at boot time. So if you have tried doing that and it didn't help, then the problem is very unlikely to be related to SELinux at all. > I already tried passing selinux=0, enforcing=0, disable=1. But > looks the selinux policy to disallow ioctl during initrd is built in > kernel. SELinux policy isn't loaded until /sbin/init runs. And SELinux allows everything until policy is loaded (i.e. it is effectively permissive until a policy is loaded no matter how you boot it). And booting with selinux=0 unhooks SELinux entirely. So, as above, I don't think your problem has anything to do with SELinux. -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Fri Oct 28 15:30:01 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 17:30:01 +0200 Subject: procmail is not allowed to talk to spamassassin Message-ID: <1130513401.2796.3.camel@rousalka.dyndns.org> Hi, Looking at audit logs I see several : type=AVC msg=audit(1130513065.226:40): avc: denied { execute } for pid=2935 comm="procmail" name="spamc" dev=dm-0 ino=3349141 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file Shouldn't procmail be allowed to talk to spamassassin ? it's a common enough usage pattern. (system is up-to-date rawhide, selinux-policy-targeted-1.27.2-8) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Fri Oct 28 15:47:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Oct 2005 11:47:31 -0400 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <1130513401.2796.3.camel@rousalka.dyndns.org> References: <1130513401.2796.3.camel@rousalka.dyndns.org> Message-ID: <43624813.9060006@redhat.com> Nicolas Mailhot wrote: > Hi, > > Looking at audit logs I see several : > > type=AVC msg=audit(1130513065.226:40): avc: denied { execute } for > pid=2935 comm="procmail" name="spamc" dev=dm-0 ino=3349141 > scontext=system_u:system_r:postfix_local_t:s0 > tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file > > Shouldn't procmail be allowed to talk to spamassassin ? it's a common > enough usage pattern. > > (system is up-to-date rawhide, selinux-policy-targeted-1.27.2-8) > > Regards, > If you add can_exec(postfix_local_t, spamc_exec_t) does that fix the problem? And if you don't know how to do this, try chcon -t bin_t /usr/bin/spamassassin And tell me if that fixes the problem > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From nicolas.mailhot at laposte.net Fri Oct 28 15:59:23 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 17:59:23 +0200 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <43624813.9060006@redhat.com> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> Message-ID: <1130515164.2796.9.camel@rousalka.dyndns.org> Le vendredi 28 octobre 2005 ? 11:47 -0400, Daniel J Walsh a ?crit : > If you add > > can_exec(postfix_local_t, spamc_exec_t) > > does that fix the problem? Don't know how to so this one > And if you don't know how to do this, > try > > chcon -t bin_t /usr/bin/spamassassin This one does not work (need to replace spamassassin by spamc perhaps ?) > And tell me if that fixes the problem I can try a local fix, but I'd rather have it fixed in the default policy, as local fixes tend to bite you when you move to another system with vendor defaults Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Oct 28 16:04:59 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 18:04:59 +0200 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <1130515164.2796.9.camel@rousalka.dyndns.org> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> Message-ID: <1130515500.2796.13.camel@rousalka.dyndns.org> Also I've just found another postfix selinux problem - do you want it on the list or in bugzilla ? Basically postdrop needs to be able to resolve names : type=AVC msg=audit(1130515276.883:135): avc: denied { udp_send } for pid=3351 comm="postdrop" saddr=127.0.0.1 src=32851 daddr=127.0.0.1 dest=53 netif=lo scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=system_u:object_r:netif_t:s0 tclass=netif Oct 28 16:01:16 rousalka postfix/postdrop[3351]: fatal: config variable inet_interfaces: host not found: rousalka.dyndns.org Oct 28 18:01:17 rousalka postfix/sendmail[3350]: warning: premature end-of-input on /usr/sbin/postdrop -r while reading input attribute name Oct 28 18:01:17 rousalka postfix/sendmail[3350]: warning: command "/usr/sbin/postdrop -r" exited with status 1 Oct 28 18:01:17 rousalka postfix/sendmail[3350]: fatal: nicolas.mailhot at laposte.net(48): unable to execute /usr/sbin/postdrop -r: Success -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Fri Oct 28 17:46:22 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Oct 2005 13:46:22 -0400 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <1130515164.2796.9.camel@rousalka.dyndns.org> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> Message-ID: <436263EE.3000000@redhat.com> Nicolas Mailhot wrote: > Le vendredi 28 octobre 2005 ? 11:47 -0400, Daniel J Walsh a ?crit : > > >> If you add >> >> can_exec(postfix_local_t, spamc_exec_t) >> >> does that fix the problem? >> > > Don't know how to so this one > > >> And if you don't know how to do this, >> try >> >> chcon -t bin_t /usr/bin/spamassassin >> > > This one does not work (need to replace spamassassin by spamc perhaps ?) > > Yes, sorry about that, I will put out policy to fix it, so this is only a change to see if my fix would fix your problem. If the machine is in enforcing mode setenforce 0 Then run this command to allow spam to execute spamc chcon -t bin_t /usr/bin/spamc Run your test, See if there are additional AVC messages Then run restorecon /usr/bin/spamc setenforc 1 And you will be back to your current state. I will then apply fixes to the AVC messages you generate in the next policy package. >> And tell me if that fixes the problem >> > > I can try a local fix, but I'd rather have it fixed in the default > policy, as local fixes tend to bite you when you move to another system > with vendor defaults > > Regards, > > -- From nicolas.mailhot at laposte.net Fri Oct 28 18:09:38 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 20:09:38 +0200 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <436263EE.3000000@redhat.com> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> <436263EE.3000000@redhat.com> Message-ID: <1130522978.2796.23.camel@rousalka.dyndns.org> Le vendredi 28 octobre 2005 ? 13:46 -0400, Daniel J Walsh a ?crit : > Yes, sorry about that, I will put out policy to fix it, so this is only > a change to see if my > fix would fix your problem. > > If the machine is in enforcing mode I tested it several times (checking restorecon restored blocking) and it seems to work. Want to work on the postfix postdrop problem now ? I only get it when a mail is queued by squirrelmail (using the sendmail command - SM does not grok SMTPS yes, or I'd make it queue mail on the submission port like evo) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Fri Oct 28 20:21:51 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 28 Oct 2005 16:21:51 -0400 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <1130522978.2796.23.camel@rousalka.dyndns.org> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> <436263EE.3000000@redhat.com> <1130522978.2796.23.camel@rousalka.dyndns.org> Message-ID: <4362885F.2040200@redhat.com> Nicolas Mailhot wrote: > Le vendredi 28 octobre 2005 ? 13:46 -0400, Daniel J Walsh a ?crit : > > >> Yes, sorry about that, I will put out policy to fix it, so this is only >> a change to see if my >> fix would fix your problem. >> >> If the machine is in enforcing mode >> > > I tested it several times (checking restorecon restored blocking) and it > seems to work. > > Want to work on the postfix postdrop problem now ? I only get it when a > mail is queued by squirrelmail (using the sendmail command - SM does not > grok SMTPS yes, or I'd make it queue mail on the submission port like > evo) > > Regards, > > Updated policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/ Should fix both problems. -- From nicolas.mailhot at laposte.net Fri Oct 28 20:43:39 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 22:43:39 +0200 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <4362885F.2040200@redhat.com> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> <436263EE.3000000@redhat.com> <1130522978.2796.23.camel@rousalka.dyndns.org> <4362885F.2040200@redhat.com> Message-ID: <1130532219.2796.38.camel@rousalka.dyndns.org> Le vendredi 28 octobre 2005 ? 16:21 -0400, Daniel J Walsh a ?crit : > > Updated policy on ftp://people.redhat.com/dwalsh/SELinux/Fedora/ > > Should fix both problems. Thanks, that was quick. However : 1. the avahi changes need more cooking : rpm -Uvh selinux-policy-targeted-1.27.2-9.noarch.rpm Pr?paration... ########################################### [100%] 1:selinux-policy-targeted########################################### [100%] /etc/selinux/targeted/contexts/files/file_contexts: line 776 has invalid context system_u:object_r:avahi_exec_t:s0:s0 /etc/selinux/targeted/contexts/files/file_contexts: line 777 has invalid context system_u:object_r:avahi_exec_t:s0:s0 /etc/selinux/targeted/contexts/files/file_contexts: line 778 has invalid context system_u:object_r:avahi_var_run_t:s0:s0 /var/lib is already defined in /etc/selinux/targeted/contexts/files/file_contexts, /usr/sbin/genhomedircon will not create a new context. 2. procmail still has trouble invoquing spamc type=AVC msg=audit(1130531640.621:489): avc: denied { execute } for pid=6118 comm="procmail" name="spamc" dev=dm-0 ino=3349141 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file type=SYSCALL msg=audit(1130531640.621:489): arch=c000003e syscall=59 success=no exit=-13 a0=51c1a1 a1=51c140 a2=51bf90 a3=51c1a1 items=1 pid=6118 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" type=CWD msg=audit(1130531640.621:489): cwd="/home/nim/.maildir" type=PATH msg=audit(1130531640.621:489): item=0 name="/usr/bin/spamc" flags=101 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1130531640.625:490): avc: denied { getattr } for pid=6118 comm="sh" name="spamc" dev=dm-0 ino=3349141 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file type=SYSCALL msg=audit(1130531640.625:490): arch=c000003e syscall=4 success=no exit=-13 a0=6bf780 a1=7fffff877bf0 a2=7fffff877bf0 a3=2 items=1 pid=6118 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="sh" exe="/bin/bash" type=AVC_PATH msg=audit(1130531640.625:490): path="/usr/bin/spamc" type=CWD msg=audit(1130531640.625:490): cwd="/home/nim/.maildir" type=PATH msg=audit(1130531640.625:490): item=0 name="/usr/bin/spamc" flags=1 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 3. But squirrelmail now works -> the postfix postdrop problem is fixed. Thank you ! (I'm running with a tail on /var/log/audit/audit.log in a term now) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Oct 28 20:50:25 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 28 Oct 2005 22:50:25 +0200 Subject: procmail is not allowed to talk to spamassassin In-Reply-To: <1130532219.2796.38.camel@rousalka.dyndns.org> References: <1130513401.2796.3.camel@rousalka.dyndns.org> <43624813.9060006@redhat.com> <1130515164.2796.9.camel@rousalka.dyndns.org> <436263EE.3000000@redhat.com> <1130522978.2796.23.camel@rousalka.dyndns.org> <4362885F.2040200@redhat.com> <1130532219.2796.38.camel@rousalka.dyndns.org> Message-ID: <1130532626.2796.43.camel@rousalka.dyndns.org> And I've just noticed saslauthd is being denied setuid, though it does not seem to cause any failure anywhere (no problems, nor errors in other maillog or messages) type=USER_ACCT msg=audit(1130532067.754:516): user pid=6257 uid=0 auid=4294967295 msg='PAM: accounting acct=nim : exe="/usr/libexec/dovecot/dovecot-auth" (hostname=?, addr=?, terminal=dovecot res=success)' type=AVC msg=audit(1130532220.600:517): avc: denied { setuid } for pid=6271 comm="saslauthd" capability=7 scontext=system_u:system_r:saslauthd_t:s0 tcontext=system_u:system_r:saslauthd_t:s0 tclass=capability type=SYSCALL msg=audit(1130532220.600:517): arch=c000003e syscall=105 success=yes exit=0 a0=0 a1=51d160 a2=315e2346f0 a3=515e20 items=0 pid=6271 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="saslauthd" exe="/usr/sbin/saslauthd" type=USER_AUTH msg=audit(1130532220.608:518): user pid=2160 uid=0 auid=4294967295 msg='PAM: authentication acct=nim : exe="/usr/sbin/saslauthd" (hostname=?, addr=?, terminal=? res=success)' type=AVC msg=audit(1130532220.612:519): avc: denied { setuid } for pid=6272 comm="saslauthd" capability=7 scontext=system_u:system_r:saslauthd_t:s0 tcontext=system_u:system_r:saslauthd_t:s0 tclass=capability type=SYSCALL msg=audit(1130532220.612:519): arch=c000003e syscall=105 success=yes exit=0 a0=0 a1=51d380 a2=315e2346f0 a3=51d2f0 items=0 pid=6272 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="saslauthd" exe="/usr/sbin/saslauthd" type=USER_ACCT msg=audit(1130532220.616:520): user pid=2160 uid=0 auid=4294967295 msg='PAM: accounting acct=nim : exe="/usr/sbin/saslauthd" (hostname=?, addr=?, terminal=? res=success)' type=USER_AUTH msg=audit(1130532234.605:521): user pid=6285 uid=0 auid=4294967295 msg='PAM: authentication acct=nim : exe="/usr/libexec/dovecot/dovecot-auth" (hostname=?, addr=?, terminal=dovecot res=success)' -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rhallyx at mindspring.com Sat Oct 29 04:15:06 2005 From: rhallyx at mindspring.com (Richard Hally) Date: Sat, 29 Oct 2005 00:15:06 -0400 Subject: strict policy does not compile Message-ID: <4362F74A.6010809@mindspring.com> Below is an error from updating strict policy sources from today's rawhide. The same error occurs when doing a "make reload" in the policy directory. Updating : selinux-policy-strict-source ####################### [26/55] initial_sid_contexts:9:ERROR 'unknown category s0' at token 'sid' on line 427891: sid kernel system_u:system_r:kernel_t:s0:s0 sid security system_u:object_r:security_t:s0:s0 /usr/bin/checkpolicy: error(s) encountered while parsing configuration make: *** [/etc/selinux/strict/policy/policy.20] Error 1 Richard Hally From gene at czarc.net Sat Oct 29 20:03:44 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 29 Oct 2005 16:03:44 -0400 Subject: trying to use MCS Message-ID: <200510291603.44718.gene@czarc.net> OK, I have "current" development installed and now I want to start playing with MCS. I have figured out that running targeted is also running MCS ... good so far. As root, I can change categories with chcon and chcat. Defining some "test" categories in setrans.conf takes effect immediately and that works ... as root. BUT, as a "regular user", I cannot seem to do anything. How do I define what users can use what categories? Sorry if I am a bit dense but I could find nothing about this searching this or other related mailing lists. Gene From gene at czarc.net Sat Oct 29 21:43:20 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sat, 29 Oct 2005 17:43:20 -0400 Subject: trying to use MCS In-Reply-To: <200510291603.44718.gene@czarc.net> References: <200510291603.44718.gene@czarc.net> Message-ID: <200510291743.20655.gene@czarc.net> On Saturday 29 October 2005 16:03, Gene Czarcinski wrote: > BUT, as a "regular user", I cannot seem to do anything. ?How do I define > what users can use what categories? Never mind ... I figured it out that it is the seusers file. From felipe.alfaro at gmail.com Sun Oct 30 09:11:44 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sun, 30 Oct 2005 11:11:44 +0200 Subject: SELinux AVCs with swap stored in LVM volume Message-ID: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> Hello, I'm running Fedora Core RawHhide and I'm seeing lots of SELinux AVCs during boot, related to my swap stored in a LVM volume: audit(1130670344.636:4): avc: denied { read } for pid=919 comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file audit(1130670345.668:5): avc: denied { use } for pid=932 comm="fsck" name="VolGroup00-Swap" dev=tmpfs ino=653 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd audit(1130670345.952:6): avc: denied { read } for pid=940 comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file audit(1130670346.092:7): avc: denied { read } for pid=941 comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 scontext=system_u:system_r:restorecon_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file Attached to this message you will find "dmesg" which stores the dmesg kernel ring which results after booting into runlevel 5. Any ideas? Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg Type: application/octet-stream Size: 15760 bytes Desc: not available URL: From gene at czarc.net Mon Oct 31 00:34:44 2005 From: gene at czarc.net (Gene Czarcinski) Date: Sun, 30 Oct 2005 20:34:44 -0400 Subject: MCS Message-ID: <200510301934.44633.gene@czarc.net> OK, I am starting to work with MCS. First I added some categories to setrans.conf: s0:c1=moonbeam s0:c2=test2 s0:c3=test3 Then I added a user to seusers: gc:user_r:s0:c0.c15 Then I logged into that user. All new (written to?) files get created with s0:c0.c15 like: -rw-r--r-- gc gc user_u:object_r:user_home_t:s0:c0.c15 bookmarks1.html including some in /tmp: drwx------ gc gc user_u:object_r:tmp_t:s0:c0.c15 orbit-gc drwx------ gc gc user_u:object_r:tmp_t:s0:c0.c15 gconfd-gc Shouldn't they default to nothing and only get set if I do a chcat? BTW, I seem to remember that there were some gripe messages during bootup about the files in /tmp ... nothing in /var/log/* or dmesg. Bug, feature, or what am I doing wrong? Gene From nicolas.mailhot at laposte.net Mon Oct 31 09:14:03 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 31 Oct 2005 10:14:03 +0100 Subject: Webdav problems in enforcing mode in Raw Hide Message-ID: <1130750043.11775.7.camel@rousalka.dyndns.org> Hi, I've just test tested webdav in enforcing mode on Fedora Devel and it doesn't work : - apache needs rw access on /srv (don't know where the default dav root should be, I put it in srv since its seems the FHS wants this kind of stuff there) type=AVC msg=audit(1130749513.951:3772): avc: denied { read } for pid=11759 comm="httpd" name="nim" dev=dm-0 ino=1048598 scontext=root:system_r:httpd_t:s0 tcontext=root:object_r:var_t:s0 tclass=dir type=SYSCALL msg=audit(1130749513.951:3772): arch=c000003e syscall=2 success=no exit=-13 a0=5555558ca410 a1=10800 a2=5555558c7ff8 a3=5555558c58a7 items=1 pid=11759 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" - it also needs rw acces to its default /var/lib/dav/lockdb.dir type=AVC msg=audit(1130749738.930:3777): avc: denied { write } for pid=11766 comm="httpd" name="lockdb.dir" dev=dm-0 ino=2392524 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1130749738.930:3777): arch=c000003e syscall=2 success=no exit=-13 a0=5555558c7580 a1=42 a2=1b6 a3=3 items=1 pid=11766 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=CWD msg=audit(1130749738.930:3777): cwd="/" type=PATH msg=audit(1130749738.930:3777): item=0 name="/var/lib/dav/lockdb.dir" flags=310 inode=2392223 dev=fd:00 mode=040700 ouid=48 ogid=48 rdev=00:00 On another topic I still have spamassassin procmail problems : type=CWD msg=audit(1130749836.551:3779): cwd="/home/nim/.maildir" type=PATH msg=audit(1130749836.551:3779): item=0 name="/usr/bin/spamc" flags=1 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1130749839.979:3780): avc: denied { execute } for pid=11852 comm="procmail" name="spamc" dev=dm-0 ino=3349141 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file type=SYSCALL msg=audit(1130749839.979:3780): arch=c000003e syscall=59 success=no exit=-13 a0=51c1d1 a1=51c170 a2=51bfc0 a3=51c1d1 items=1 pid=11852 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" type=CWD msg=audit(1130749839.979:3780): cwd="/home/nim/.maildir" type=PATH msg=audit(1130749839.979:3780): item=0 name="/usr/bin/spamc" flags=101 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1130749839.983:3781): avc: denied { getattr } for pid=11852 comm="sh" name="spamc" dev=dm-0 ino=3349141 scontext=system_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=filetype=SYSCALL msg=audit(1130749839.983:3781): arch=c000003e syscall=4 success=no exit=-13 a0=6bf780 a1=7fffffefb5c0 a2=7fffffefb5c0 a3=2 items=1 pid=11852 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 comm="sh" exe="/bin/bash" type=AVC_PATH msg=audit(1130749839.983:3781): path="/usr/bin/spamc" type=CWD msg=audit(1130749839.983:3781): cwd="/home/nim/.maildir" type=PATH msg=audit(1130749839.983:3781): item=0 name="/usr/bin/spamc" flags=1 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 Package versions : selinux-policy-targeted-1.27.2-10 libselinux-1.27.17-1 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwalsh at redhat.com Mon Oct 31 14:38:30 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 09:38:30 -0500 Subject: MCS In-Reply-To: <200510301934.44633.gene@czarc.net> References: <200510301934.44633.gene@czarc.net> Message-ID: <43662C66.30606@redhat.com> Gene Czarcinski wrote: > OK, I am starting to work with MCS. > > First I added some categories to setrans.conf: > s0:c1=moonbeam > s0:c2=test2 > s0:c3=test3 > > > Then I added a user to seusers: > gc:user_r:s0:c0.c15 > > Then I logged into that user. > > All new (written to?) files get created with s0:c0.c15 like: > -rw-r--r-- gc gc user_u:object_r:user_home_t:s0:c0.c15 > bookmarks1.html > You want to specify gc:user_u:s0-s0:c0.c15 This sets up user gc to be an SELinux user user_u with a range of Categories from s0-s0:c0.c15. By default he will login with level s0 and all files will be created as s0. If you want to create a file under a different category you can use chcon or chcat to create it. > including some in /tmp: > drwx------ gc gc user_u:object_r:tmp_t:s0:c0.c15 orbit-gc > drwx------ gc gc user_u:object_r:tmp_t:s0:c0.c15 gconfd-gc > > > Shouldn't they default to nothing and only get set if I do a chcat? > > BTW, I seem to remember that there were some gripe messages during bootup > about the files in /tmp ... nothing in /var/log/* or dmesg. > > Bug, feature, or what am I doing wrong? > > Gene > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From dwalsh at redhat.com Mon Oct 31 14:42:06 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 09:42:06 -0500 Subject: strict policy does not compile In-Reply-To: <4362F74A.6010809@mindspring.com> References: <4362F74A.6010809@mindspring.com> Message-ID: <43662D3E.30405@redhat.com> Richard Hally wrote: > Below is an error from updating strict policy sources from today's > rawhide. The same error occurs when doing a "make reload" in the > policy directory. > > Updating : selinux-policy-strict-source ####################### [26/55] > initial_sid_contexts:9:ERROR 'unknown category s0' at token 'sid' on > line 427891: > sid kernel system_u:system_r:kernel_t:s0:s0 > sid security system_u:object_r:security_t:s0:s0 > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/strict/policy/policy.20] Error 1 Did you run make mcsconvert? or make mlsconvert? You can not run these a second time. This seems to work for me. > > > Richard Hally > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From dwalsh at redhat.com Mon Oct 31 14:47:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 09:47:14 -0500 Subject: SELinux AVCs with swap stored in LVM volume In-Reply-To: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> References: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> Message-ID: <43662E72.9010501@redhat.com> Felipe Alfaro Solana wrote: > Hello, > > I'm running Fedora Core RawHhide and I'm seeing lots of SELinux AVCs > during boot, related to my swap stored in a LVM volume: > > audit(1130670344.636:4): avc: denied { read } for pid=919 > comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > audit(1130670345.668:5): avc: denied { use } for pid=932 > comm="fsck" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:fsadm_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd > > audit(1130670345.952:6): avc: denied { read } for pid=940 > comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > audit(1130670346.092:7): avc: denied { read } for pid=941 > comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > Attached to this message you will find "dmesg" which stores the dmesg > kernel ring which results after booting into runlevel 5. > > Any ideas? > Thanks! > The fd:use and blk_file read is caused by a kernel bug. Basically the kernel is leaking open file descriptors to subprocesses and SELinux is preventing access to these leaked file descriptors. This is a good thing, since these processes could gain would be able to manipulate these file descriptors. SELinux is great at detecting and preventing this type of problem. This has been reported to bugsilla. Reviewing you dmesg file also reveals that you have blkid.tab labeled incorrectly. restorecon /etc/blkid.tab* will fix this. > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- From sds at tycho.nsa.gov Mon Oct 31 14:21:52 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 31 Oct 2005 09:21:52 -0500 Subject: SELinux AVCs with swap stored in LVM volume In-Reply-To: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> References: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> Message-ID: <1130768512.22731.40.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2005-10-30 at 11:11 +0200, Felipe Alfaro Solana wrote: > Hello, > > I'm running Fedora Core RawHhide and I'm seeing lots of SELinux AVCs > during boot, related to my swap stored in a LVM volume: > > audit(1130670344.636:4): avc: denied { read } for pid=919 > comm="restorecon" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:restorecon_t:s0 > tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file > > audit(1130670345.668:5): avc: denied { use } for pid=932 > comm="fsck" name="VolGroup00-Swap" dev=tmpfs ino=653 > scontext=system_u:system_r:fsadm_t:s0 > tcontext=system_u:system_r:kernel_t:s0 tclass=fd This implies that a process that ran before the initial policy load by /sbin/init (hence a "kernel_t" file descriptor) opened the device (hence a "fixed_disk_device_t" block device file) and failed to ever close it (or mark it close-on-exec), thereby leaking it to all descendants. Already bugzilla'd: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165912 Dan, James - looks like this could just be a bug in lvm? Should be filed against it? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Oct 31 15:55:34 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 31 Oct 2005 10:55:34 -0500 Subject: SELinux AVCs with swap stored in LVM volume In-Reply-To: <43662E72.9010501@redhat.com> References: <6f6293f10510300111j1d058d06he0c99f6a135f7060@mail.gmail.com> <43662E72.9010501@redhat.com> Message-ID: <1130774134.22731.111.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-10-31 at 09:47 -0500, Daniel J Walsh wrote: > The fd:use and blk_file read is caused by a kernel bug. Basically the > kernel is leaking open file descriptors to subprocesses and SELinux is > preventing access to these leaked file descriptors. This is a good > thing, since these processes could gain would be able to manipulate > these file descriptors. SELinux is great at detecting and preventing > this type of problem. This has been reported to bugsilla. Reviewing > you dmesg file also reveals that you have blkid.tab labeled incorrectly. I think it may be a lvm bug rather than a kernel bug, so you may want to re-assign it in bugzilla. Note that anything that runs prior to initial policy load by /sbin/init or anything that runs as a usermode helper from the kernel without a domain transition defined will run with type kernel_t. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Oct 31 16:05:47 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 11:05:47 -0500 Subject: Webdav problems in enforcing mode in Raw Hide In-Reply-To: <1130750043.11775.7.camel@rousalka.dyndns.org> References: <1130750043.11775.7.camel@rousalka.dyndns.org> Message-ID: <436640DB.3080304@redhat.com> Nicolas Mailhot wrote: > Hi, > > I've just test tested webdav in enforcing mode on Fedora Devel and it > doesn't work : > > > - apache needs rw access on /srv (don't know where the default dav root > should be, I put it in srv since its seems the FHS wants this kind of > stuff there) > > type=AVC msg=audit(1130749513.951:3772): avc: denied { read } for > pid=11759 comm="httpd" name="nim" dev=dm-0 ino=1048598 > scontext=root:system_r:httpd_t:s0 tcontext=root:object_r:var_t:s0 > tclass=dir > type=SYSCALL msg=audit(1130749513.951:3772): arch=c000003e syscall=2 > success=no exit=-13 a0=5555558ca410 a1=10800 a2=5555558c7ff8 > a3=5555558c58a7 items=1 pid=11759 auid=4294967295 uid=48 gid=48 euid=48 > suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" > exe="/usr/sbin/httpd" > > You need to change the context of those directories so that httpd can read/write them chcon -R -t httpd_sys_script_rw_t /var/lib/dav http://fedora.redhat.com/docs/selinux-apache-fc3/ Has a good description of how to use httpd and selinux. > > - it also needs rw acces to its default /var/lib/dav/lockdb.dir > > type=AVC msg=audit(1130749738.930:3777): avc: denied { write } for > pid=11766 comm="httpd" name="lockdb.dir" dev=dm-0 ino=2392524 > scontext=root:system_r:httpd_t:s0 > tcontext=system_u:object_r:var_lib_t:s0 tclass=file > type=SYSCALL msg=audit(1130749738.930:3777): arch=c000003e syscall=2 > success=no exit=-13 a0=5555558c7580 a1=42 a2=1b6 a3=3 items=1 pid=11766 > auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 > fsgid=48 comm="httpd" exe="/usr/sbin/httpd" > type=CWD msg=audit(1130749738.930:3777): cwd="/" > type=PATH msg=audit(1130749738.930:3777): item=0 > name="/var/lib/dav/lockdb.dir" flags=310 inode=2392223 dev=fd:00 > mode=040700 ouid=48 ogid=48 rdev=00:00 > > > On another topic I still have spamassassin procmail problems : > > type=CWD msg=audit(1130749836.551:3779): cwd="/home/nim/.maildir" > type=PATH msg=audit(1130749836.551:3779): item=0 name="/usr/bin/spamc" > flags=1 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1130749839.979:3780): avc: denied { execute } for > pid=11852 comm="procmail" name="spamc" dev=dm-0 ino=3349141 > scontext=system_u:system_r:postfix_local_t:s0 > tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file > type=SYSCALL msg=audit(1130749839.979:3780): arch=c000003e syscall=59 > success=no exit=-13 a0=51c1d1 a1=51c170 a2=51bfc0 a3=51c1d1 items=1 > pid=11852 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="procmail" exe="/usr/bin/procmail" > type=CWD msg=audit(1130749839.979:3780): cwd="/home/nim/.maildir" > type=PATH msg=audit(1130749839.979:3780): item=0 name="/usr/bin/spamc" > flags=101 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1130749839.983:3781): avc: denied { getattr } for > pid=11852 comm="sh" name="spamc" dev=dm-0 ino=3349141 > scontext=system_u:system_r:postfix_local_t:s0 > tcontext=system_u:object_r:spamc_exec_t:s0 tclass=filetype=SYSCALL > msg=audit(1130749839.983:3781): arch=c000003e syscall=4 success=no > exit=-13 a0=6bf780 a1=7fffffefb5c0 a2=7fffffefb5c0 a3=2 items=1 > pid=11852 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 comm="sh" exe="/bin/bash" > type=AVC_PATH msg=audit(1130749839.983:3781): path="/usr/bin/spamc" > type=CWD msg=audit(1130749839.983:3781): cwd="/home/nim/.maildir" > type=PATH msg=audit(1130749839.983:3781): item=0 name="/usr/bin/spamc" > flags=1 inode=3349141 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 > > > > Package versions : > > selinux-policy-targeted-1.27.2-10 > libselinux-1.27.17-1 > > Regards, > > -- From nicolas.mailhot at laposte.net Mon Oct 31 16:15:04 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 31 Oct 2005 17:15:04 +0100 Subject: Webdav problems in enforcing mode in Raw Hide In-Reply-To: <436640DB.3080304@redhat.com> References: <1130750043.11775.7.camel@rousalka.dyndns.org> <436640DB.3080304@redhat.com> Message-ID: <1130775305.12653.9.camel@rousalka.dyndns.org> Le lundi 31 octobre 2005 ? 11:05 -0500, Daniel J Walsh a ?crit : > You need to change the context of those directories so that httpd can > read/write them > > chcon -R -t httpd_sys_script_rw_t /var/lib/dav > > http://fedora.redhat.com/docs/selinux-apache-fc3/ > > Has a good description of how to use httpd and selinux. Thanks for the info ! However since one of the directories is defined in the httpd.conf Red Hat ships, and the other is in the FHS, shouldn't they be part of the default policy ? Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gene at czarc.net Mon Oct 31 16:34:00 2005 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 31 Oct 2005 12:34:00 -0400 Subject: MCS In-Reply-To: <43662C66.30606@redhat.com> References: <200510301934.44633.gene@czarc.net> <43662C66.30606@redhat.com> Message-ID: <200510311134.01151.gene@czarc.net> On Monday 31 October 2005 09:38, Daniel J Walsh wrote: > Gene Czarcinski wrote: > > OK, I am starting to work with MCS. > > > > First I added some categories to setrans.conf: > > s0:c1=moonbeam > > s0:c2=test2 > > s0:c3=test3 > > > > > > Then I added a user to seusers: > > gc:user_r:s0:c0.c15 > > > > Then I logged into that user. > > > > All new (written to?) files get created with s0:c0.c15 like: > > -rw-r--r-- ?gc ? ? ? gc ? ? ? user_u:object_r:user_home_t:s0:c0.c15 > > bookmarks1.html > > ? > > You want to specify > gc:user_u:s0-s0:c0.c15 > > This sets up user gc to be an SELinux user ?user_u with a range of > Categories from s0-s0:c0.c15. ?By default he will login with level s0 > and all files will be created as s0. ?If you want to create a file under > a different category you can use chcon or chcat to create it. Thanks. Now I understand what is happening. I should have seen this from the definition for root. Gene From dwalsh at redhat.com Mon Oct 31 16:35:47 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 11:35:47 -0500 Subject: Webdav problems in enforcing mode in Raw Hide In-Reply-To: <1130775305.12653.9.camel@rousalka.dyndns.org> References: <1130750043.11775.7.camel@rousalka.dyndns.org> <436640DB.3080304@redhat.com> <1130775305.12653.9.camel@rousalka.dyndns.org> Message-ID: <436647E3.1070405@redhat.com> Nicolas Mailhot wrote: > Le lundi 31 octobre 2005 ? 11:05 -0500, Daniel J Walsh a ?crit : > >> You need to change the context of those directories so that httpd can >> read/write them >> >> chcon -R -t httpd_sys_script_rw_t /var/lib/dav >> >> http://fedora.redhat.com/docs/selinux-apache-fc3/ >> >> Has a good description of how to use httpd and selinux. >> > > Thanks for the info ! > > However since one of the directories is defined in the httpd.conf Red > Hat ships, and the other is in the FHS, shouldn't they be part of the > default policy ? > > Regards, > > Ok, if I change the context to be httpd_var_lib_t does that work? chcon -R -t httpd_var_lib_t /var/lib/dav -- From dwalsh at redhat.com Mon Oct 31 16:38:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 31 Oct 2005 11:38:12 -0500 Subject: Webdav problems in enforcing mode in Raw Hide In-Reply-To: <436647E3.1070405@redhat.com> References: <1130750043.11775.7.camel@rousalka.dyndns.org> <436640DB.3080304@redhat.com> <1130775305.12653.9.camel@rousalka.dyndns.org> <436647E3.1070405@redhat.com> Message-ID: <43664874.4000901@redhat.com> Daniel J Walsh wrote: > Nicolas Mailhot wrote: >> Le lundi 31 octobre 2005 ? 11:05 -0500, Daniel J Walsh a ?crit : >> >>> You need to change the context of those directories so that httpd >>> can read/write them >>> >>> chcon -R -t httpd_sys_script_rw_t /var/lib/dav >>> >>> http://fedora.redhat.com/docs/selinux-apache-fc3/ >>> >>> Has a good description of how to use httpd and selinux. >> >> Thanks for the info ! >> >> However since one of the directories is defined in the httpd.conf Red >> Hat ships, and the other is in the FHS, shouldn't they be part of the >> default policy ? >> >> Regards, >> >> > Ok, if I change the context to be httpd_var_lib_t does that work? > > chcon -R -t httpd_var_lib_t /var/lib/dav > Also what is the standard directory under /srv? Dan -- From gene at czarc.net Mon Oct 31 19:49:15 2005 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 31 Oct 2005 14:49:15 -0500 Subject: More MCS Message-ID: <200510311449.15468.gene@czarc.net> I tried seting a category on a directory in /tmp and then (with touch) creating a file under that directory. So far so good. I then ssh'ed into the system as another user which does not have those categories defined in seusers. This user could access the file. This sounds like a bug to me. Also, is there a way that a category value can be propogated to all files/directories below it? Gene From sds at tycho.nsa.gov Mon Oct 31 20:06:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 31 Oct 2005 15:06:16 -0500 Subject: More MCS In-Reply-To: <200510311449.15468.gene@czarc.net> References: <200510311449.15468.gene@czarc.net> Message-ID: <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-10-31 at 14:49 -0500, Gene Czarcinski wrote: > I tried seting a category on a directory in /tmp and then (with touch) > creating a file under that directory. So far so good. > > I then ssh'ed into the system as another user which does not have those > categories defined in seusers. This user could access the file. This sounds > like a bug to me. Looks like the MCS constraints (as defined in policy/mcs) only constrain access to files, not directories, presently (and this is noted in a comment in that file, so it seems to be intentional). They do appear to work correctly for files. Use of categories on directories doesn't seem to be supported at present under MCS. > Also, is there a way that a category value can be propogated to all > files/directories below it? Hmmm...the current MLS logic inherits from the process' effective/current/low level rather than from the parent directory. -- Stephen Smalley National Security Agency From gene at czarc.net Mon Oct 31 22:04:01 2005 From: gene at czarc.net (Gene Czarcinski) Date: Mon, 31 Oct 2005 17:04:01 -0500 Subject: More MCS In-Reply-To: <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> References: <200510311449.15468.gene@czarc.net> <1130789176.22731.197.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200510311704.02077.gene@czarc.net> On Monday 31 October 2005 15:06, Stephen Smalley wrote: > On Mon, 2005-10-31 at 14:49 -0500, Gene Czarcinski wrote: > > I tried seting a category on a directory in /tmp and then (with touch) > > creating a file under that directory. So far so good. > > > > I then ssh'ed into the system as another user which does not have those > > categories defined in seusers. This user could access the file. This > > sounds like a bug to me. > > Looks like the MCS constraints (as defined in policy/mcs) only constrain > access to files, not directories, presently (and this is noted in a > comment in that file, so it seems to be intentional). They do appear to > work correctly for files. Use of categories on directories doesn't seem > to be supported at present under MCS. Yes, files work but not directories ... this is not intuitive (not expected). > > > Also, is there a way that a category value can be propogated to all > > files/directories below it? > > Hmmm...the current MLS logic inherits from the process' > effective/current/low level rather than from the parent directory. Whether MCS or MLS, if a user without the category/compartment can "blast through" the directory, this will be unexpected behavior. Gene From chanson at TrustedCS.com Mon Oct 31 23:16:09 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Mon, 31 Oct 2005 18:16:09 -0500 Subject: More MCS Message-ID: <36282A1733C57546BE392885C061859205731D@chaos.tcs.tcs-sec.com> > Hmmm...the current MLS logic inherits from the process' > effective/current/low level rather than from the parent directory. That is correct for MLS :) -Chad