From jsingh at ensim.com Tue Nov 2 06:51:45 2004 From: jsingh at ensim.com (Jaspreet Singh) Date: Tue, 02 Nov 2004 12:21:45 +0530 Subject: set/getxattrs - I am badly struck .. In-Reply-To: <20041102003903.GR9643@lkcl.net> References: <1099347144.9776.3.camel@jsingh> <1099347590.9784.3.camel@jsingh> <20041102003903.GR9643@lkcl.net> Message-ID: <1099378305.11007.13.camel@jsingh> Hi, Thanx for the mail .. i have corrected the problem using audit2allow .. basically the domain needed permissions to access file-system. Could you please help in this case .. I am struck in kernel space get/setxattrs (FC3-2.6.8-541 fs=etx3) Should there be a difference between using user-space and kernel-space get/setxattrs to get/set file xattrs ... I have some trouble with using inode->i_op->get/setxattrs ... i getxattr from /home and set it to /var/home using inode operations and get this - ls -Zd /home /var/home drwxr-xr-x+ root root system_u:object_r:home_root_t /home/ drwxr-xr-x+ root root system_u:object_r:home_root_t /var/home/ perfect till now .. but now when i try and create files inside /var/home they get the "root:object_r:var_t" unlike /home where i get "root:object_r:user_home_dir_t" :-( and on the contrary if i create /var/home and tag with "home_root_t" using setfiles it works perfectly fine ... any clues I cant use user-space get/setxattr coz I am writing a overlay file-system ... so .... Does selinux intercept (and probably note down ) get/setxattrs syscalls or any of the type_tranistions. any suggestions .... Jaspreet Singh From lkcl at lkcl.net Tue Nov 2 09:17:11 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Tue, 2 Nov 2004 09:17:11 +0000 Subject: set/getxattrs - I am badly struck .. In-Reply-To: <1099378305.11007.13.camel@jsingh> References: <1099347144.9776.3.camel@jsingh> <1099347590.9784.3.camel@jsingh> <20041102003903.GR9643@lkcl.net> <1099378305.11007.13.camel@jsingh> Message-ID: <20041102091711.GU9643@lkcl.net> jaspreet, hi, it sounds like you're endeavouring to do _exactly_ what i have been trying to do: making a filesystem simultaneously available at a second location. realistically, you will need to examine types/files.fc and modify genhomedircon. i recommend you cut/paste genhomedircon's use of HOME_ROOT and HOME_DIR to create a second set of macro substitutions VIRTUAL_HOME_ROOT and VIRTUAL_HOME_DIR. then, cut/paste the three or so lines in types/files.fc that use HOME_ROOT and HOME_DIR, prepending VIRTUAL_ in the right places. and you make sure that genhomedircon prepends /var/ whereever the new substitutions VIRTUAL_ are used. in this way, you will end up with a file_contexts that has double-entries for /home and /var/home. alternatively, ignore the above and hack genhomedircon to double-output its lines: outputting both a line for /home and also an identical context line for /var/home. what _i_ did was restrict the system to only having one user: therefore i can get away with using fusexmp to proxy mount /home/sez to /Documents. therefore, in the file contexts, i can get away without having to hack genhomedircon, i can just add a hacked-up entry like this files/misc/hack.sez.fc: /Documents sez:object_r:user_t. l. On Tue, Nov 02, 2004 at 12:21:45PM +0530, Jaspreet Singh wrote: > Hi, > > Thanx for the mail .. i have corrected the problem using audit2allow .. > basically the domain needed permissions to access file-system. > > Could you please help in this case .. I am struck in kernel space > get/setxattrs (FC3-2.6.8-541 fs=etx3) > > Should there be a difference between using user-space and kernel-space > get/setxattrs to get/set file xattrs ... > > > I have some trouble with using inode->i_op->get/setxattrs ... > > i getxattr from /home and set it to /var/home using inode operations and > get this - > > ls -Zd /home /var/home > drwxr-xr-x+ root root system_u:object_r:home_root_t /home/ > drwxr-xr-x+ root root system_u:object_r:home_root_t /var/home/ > > perfect till now .. but now when i try and create files inside /var/home > they get the "root:object_r:var_t" unlike /home where i get > "root:object_r:user_home_dir_t" :-( > > and on the contrary if i create /var/home and tag with "home_root_t" > using setfiles it works perfectly fine ... any clues > > I cant use user-space get/setxattr coz I am writing a overlay > file-system ... so .... > > Does selinux intercept (and probably note down ) get/setxattrs syscalls > or any of the type_tranistions. > > any suggestions .... > > Jaspreet Singh > -- -- you don't have to BE MAD | this space | my brother wanted to join mensa, to work, but IT HELPS | for rent | for an ego trip - and get kicked you feel better! I AM | can pay cash | out for a even bigger one. -- From russell at coker.com.au Tue Nov 2 15:16:35 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 3 Nov 2004 02:16:35 +1100 Subject: Truncated log entries In-Reply-To: <1099066681.21971.25.camel@redrum.boston.redhat.com> References: <992869706CCB3842977776032647EA9B0115C445@treexchange.ccgroupnet.com> <1098897877.30470.165.camel@moss-spartans.epoch.ncsc.mil> <1099066681.21971.25.camel@redrum.boston.redhat.com> Message-ID: <200411030216.35871.russell@coker.com.au> On Sat, 30 Oct 2004 02:18, Peter Martuccelli wrote: > I want to verify that people have only seen this issue on SMP systems. I'm running 2.6.9-1.649 on a single Pentium-M 1700MHz (Thinkpad T41p). I see the truncated errors repeatedly and often. I don't do anything special, just run strict policy and do basic desktop stuff like checking my email. gam_server triggers a good supply of AVC messages. -- 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 linux_4ever at yahoo.com Tue Nov 2 16:31:33 2004 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 2 Nov 2004 08:31:33 -0800 (PST) Subject: Truncated log entries In-Reply-To: <200411030216.35871.russell@coker.com.au> Message-ID: <20041102163133.99323.qmail@web50607.mail.yahoo.com> >I see the truncated errors repeatedly and often. I don't do anything special, >just run strict policy and do basic desktop stuff like checking my email. I was wondering where the code was that actually does the logging. I see an avc_init function call that takes a logger callback function. I was wondering what is being used for the callback. Is it in user space or kernel? -Steve Grubb __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sds at epoch.ncsc.mil Tue Nov 2 17:36:07 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 02 Nov 2004 12:36:07 -0500 Subject: Truncated log entries In-Reply-To: <20041102163133.99323.qmail@web50607.mail.yahoo.com> References: <20041102163133.99323.qmail@web50607.mail.yahoo.com> Message-ID: <1099416967.31739.183.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-11-02 at 11:31, Steve G wrote: > >I see the truncated errors repeatedly and often. I don't do anything special, > >just run strict policy and do basic desktop stuff like checking my email. > > I was wondering where the code was that actually does the logging. I see an > avc_init function call that takes a logger callback function. I was wondering > what is being used for the callback. Is it in user space or kernel? The issue has to do with the kernel audit framework (linux-2.6.x/kernel/audit.c), which is called by the kernel AVC (linux-2.6.x/security/selinux/avc.c:avc_audit). Userspace AVC is a port of the kernel AVC to userspace, not relevant to this particular bug. -- Stephen Smalley National Security Agency From selinux at gmail.com Wed Nov 3 05:10:41 2004 From: selinux at gmail.com (Tom London) Date: Tue, 2 Nov 2004 21:10:41 -0800 Subject: PT_GNU_STACK, ld.so.cache and java Message-ID: <4c4ba153041102211031bbab08@mail.gmail.com> The 'legacy' binary problem seems to hit the java VMs I've installed and tested under strict/enforcing (java-1-4.2 and java-1.5.0). 'execstack -c' doesn't fix this. Any pointers to 'Fedora compiled' versions or workarounds? ('gij' doesn't seem to cut it.) thanks, tom -- Tom London From himainu-ynakam at miomio.jp Wed Nov 3 14:02:37 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Wed, 03 Nov 2004 09:02:37 -0500 Subject: setools in Fedora In-Reply-To: <200410201539.i9KFdXSf021993@gotham.columbia.tresys.com> References: <200410201539.i9KFdXSf021993@gotham.columbia.tresys.com> Message-ID: <200411031402.iA3E2r6Q025916@mms-r00.iijmio.jp> "Karl MacMillan" wrote: > We can't reproduce this problem, unfortunately. We will keep a bug open for > this in case something comes up in the future. You might try contacting the > BWidget developers. One of Japanese users reported same problem, but he could resolve it. As he say, it seems language dependent problem. When we install Fedora as Japanese, LANG is ja_JP.UTF-8. When LANG is ja_JP.UTF-8 Bwidget is very slow in some environment. But, after "unset LANG" Bwidget and setools works normally! When "LANG = en_US.UTF-8" Bwidget works fine as well. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) ??http://www.selinux.gr.jp/ Hitachi Software http://www.selinux.hitachi-sk.co.jp/en The George Washington University From kmacmillan at tresys.com Thu Nov 4 22:15:11 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Thu, 04 Nov 2004 17:15:11 -0500 Subject: ANN: Setools 1.5.1 Message-ID: <1099606511.20150.95.camel@pham.columbia.tresys.com> There is a new release of setools at http://www.tresys.com/selinux/. This is a minor release to fix a few bugs in the 1.5 release that was made last week. Thanks, Karl -- Karl MacMillan Tresys Technology kmacmillan at tresys.com http://www.tresys.com From selinux at gmail.com Mon Nov 8 16:40:14 2004 From: selinux at gmail.com (Tom London) Date: Mon, 8 Nov 2004 08:40:14 -0800 Subject: kudzu (kmodule) and /dev/zero: latest rawhide issues.... Message-ID: <4c4ba15304110808406094d287@mail.gmail.com> Latest rawhide packages, kudzu has problems with /dev/zero and /dev/mem kudzu generates: Nov 7 17:20:13 fedora kernel: audit(1099847973.501:0): avc: denied { read } for pid=826 exe=/sbin/kmodule name=zero dev=tmpfs ino=3510 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:zero_device_t tclass=chr_file Nov 7 17:20:13 fedora kernel: audit(1099847973.501:0): avc: denied { read } for pid=826 exe=/sbin/kmodule name=zero dev=tmpfs ino=3510 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:zero_device_t tclass=chr_file after fixing this, it fails on mmap of /dev/zero, so need to also add execute. Here's a patch: --- SAVE/kudzu.te 2004-11-07 18:18:24.889196971 -0800 +++ ./kudzu.te 2004-11-07 18:18:52.095994659 -0800 @@ -18,6 +18,7 @@ allow kudzu_t modules_object_t:dir r_dir_perms; allow kudzu_t { modules_object_t modules_dep_t }:file { getattr read }; allow kudzu_t mouse_device_t:chr_file { read write }; +allow kudzu_t zero_device_t:chr_file { read execute }; allow kudzu_t proc_t:file { getattr read }; allow kudzu_t { fixed_disk_device_t removable_device_t }:blk_file rw_file_perms; allow kudzu_t scsi_generic_device_t:chr_file r_file_perms; But, it now produces: Nov 8 06:53:38 fedora kernel: audit(1099896764.946:0): avc: denied { read write } for pid=826 exe=/sbin/kmodule name=mem dev=tmpfs ino=909 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:memory_device_t tclass=chr_file Adding allow kudzu_t memory_device_t:chr_file { read write }; produces /usr/bin/checkpolicy: loading policy configuration from policy.conf security: 5 users, 6 roles, 1323 types, 31 bools security: 53 classes, 313479 rules assertion on line 269956 violated by allow kudzu_t memory_device_t:chr_file { read write }; make: *** [/etc/selinux/strict/policy/policy.18] Error 1 Some help, please? thanks, tom -- Tom London From selinux at gmail.com Mon Nov 8 16:43:26 2004 From: selinux at gmail.com (Tom London) Date: Mon, 8 Nov 2004 08:43:26 -0800 Subject: privoxy.te Message-ID: <4c4ba15304110808433fcd3bf9@mail.gmail.com> Running strict/enforcing off of latest rawhide (selinux-policy-strict-1.18.2-2): privoxy generates: Nov 7 13:44:10 fedora kernel: audit(1099863850.432:0): avc: denied { connect } for pid=14703 exe=/usr/sbin/privoxy scontext=system_u:system_r:privoxy_t tcontext=system_u:system_r:privoxy_t tclass=udp_socket Nov 7 13:44:10 fedora kernel: audit(1099863850.469:0): avc: denied { connect } for pid=14703 exe=/usr/sbin/privoxy scontext=system_u:system_r:privoxy_t tcontext=system_u:system_r:privoxy_t tclass=tcp_socket This patch seems to fix it: --- SAVE/privoxy.te 2004-11-07 18:00:09.433732712 -0800 +++ ./privoxy.te 2004-11-07 18:00:40.419276794 -0800 @@ -18,6 +18,7 @@ # Use the network. can_network(privoxy_t) allow privoxy_t port_t:{ tcp_socket udp_socket } name_bind; +allow privoxy_t self:{ tcp_socket udp_socket } connect; allow privoxy_t etc_t:file { getattr read }; allow privoxy_t self:capability { setgid setuid }; allow privoxy_t self:unix_stream_socket create_socket_perms ; tom -- Tom London From dwalsh at redhat.com Mon Nov 8 18:42:12 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 08 Nov 2004 13:42:12 -0500 Subject: privoxy.te In-Reply-To: <4c4ba15304110808433fcd3bf9@mail.gmail.com> References: <4c4ba15304110808433fcd3bf9@mail.gmail.com> Message-ID: <418FBE04.5000107@redhat.com> Tom London wrote: >Running strict/enforcing off of latest rawhide >(selinux-policy-strict-1.18.2-2): > >privoxy generates: > >Nov 7 13:44:10 fedora kernel: audit(1099863850.432:0): avc: denied >{ connect } for pid=14703 exe=/usr/sbin/privoxy >scontext=system_u:system_r:privoxy_t >tcontext=system_u:system_r:privoxy_t tclass=udp_socket >Nov 7 13:44:10 fedora kernel: audit(1099863850.469:0): avc: denied >{ connect } for pid=14703 exe=/usr/sbin/privoxy >scontext=system_u:system_r:privoxy_t >tcontext=system_u:system_r:privoxy_t tclass=tcp_socket > >This patch seems to fix it: >--- SAVE/privoxy.te 2004-11-07 18:00:09.433732712 -0800 >+++ ./privoxy.te 2004-11-07 18:00:40.419276794 -0800 >@@ -18,6 +18,7 @@ > # Use the network. > can_network(privoxy_t) > allow privoxy_t port_t:{ tcp_socket udp_socket } name_bind; >+allow privoxy_t self:{ tcp_socket udp_socket } connect; > allow privoxy_t etc_t:file { getattr read }; > allow privoxy_t self:capability { setgid setuid }; > allow privoxy_t self:unix_stream_socket create_socket_perms ; > > >tom > > Added thanks. Dan From sds at epoch.ncsc.mil Tue Nov 9 15:24:55 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 09 Nov 2004 10:24:55 -0500 Subject: first encounters with SELINUX, with some suggestions In-Reply-To: <1100002330.15772.41.camel@otto.amantes> References: <1100002330.15772.41.camel@otto.amantes> Message-ID: <1100013895.408.100.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-11-09 at 07:12, Thomas Vander Stichele wrote: > The latter has a paragraph about where policy is stored, and mentions > Makefiles and other stuff in /etc/selinux. None of this is present on > my FC3 system, so I'm assuming here that Red Hat has changed some things > from the default SELinux which obliviate this step, but I have way of > finding out how. Am I missing something ? Maybe there's a package I > need to install ? FC3 places the policy under /etc/selinux/targeted (or strict, if using that policy). By default, only the compiled policy (selinux-policy-targeted) is installed, I think. You need to install selinux-policy-targeted-sources for the policy sources. The policy sources and Makefile are placed under /etc/selinux/targeted/src/policy. > The former howto tells me I can run > /sbin/fixfiles relabel /home/thomas/www > > but that command just gives me this: > Usage: /sbin/fixfiles {-R rpmpackage[,rpmpackage...] [-l logfile ] [-o > outputfile ] |check|restore|[-F] relabel} > > It would seem to me that what I issued was correct, both from the howto > as well as the usage output. Clearly I'm missing something else here. fixfiles doesn't take a list of directories, AFAIK, nor does the usage message say that it does. It is just a script front-end by RedHat for the setfiles program. setfiles was the original program, used to label entire filesystems for an initial install of SELinux, although it can be applied to a subtree. > So I tried this: > restorecon -v -R /home/thomas/www > > and that did something. How do these two tools differ ? Why does the > first not work as advertised. setfiles - The original upstream program. Relabels or checks entire filesystems or at least a subtree starting from the specified directories. Requires explicit specification of a file_contexts configuration and of the list of directories to traverse. fixfiles - script front-end by RedHat for setfiles. Doesn't require (or even permit) specification of a file_contexts configuration or a list of directories to traverse; has some additional features like being able to selectively relabel all files in a given package. restorecon - variant of setfiles program by RedHat. Doesn't require or permit specification of a file_contexts configuration; does require specification of paths to relabel; only traverses directories recursively if -R is specified. This is more like a chown/chmod-style program, except you don't have to specify the context itself, as that is obtained from the file_contexts configuration based on the pathname. Over time, restorecon has been getting more and more like setfiles (e.g. via -R option); it just presents a different default interface to the user. Should likely be merged with setfiles in some manner. chcon - chown/chmod equivalent for security contexts. You specify the context and the individual files, can also recurse via -R. > Using ls -alz /home/thomas I seem to get the impression this security > context has been adopted. Still, apache refuses to see the directory. >From the initial denial, it looked like apache couldn't even search the top-level home directory ("thomas") because it lacked the proper security context (should have user_home_dir_t, not default_t). restorecon -R /home/thomas. > So I read some more of the howto. There's a binary called audit2allow > that could help me generate rules. So I run it, restart apache a few > times, but the binary doesn't print anything, not even with -v. Maybe > I'm using it wrong, but there's no way of finding out if I am. audit2allow -d (to read audit from dmesg output) or audit2allow -i /var/log/messages (to read from the messages file). Otherwise, it defaults to acting as a filter, reading from stdin. Possibly not the best choice of interface. > Maybe it would be a good idea to write a simple "getting started" guide > explaining how to do two or three common tasks (I'd say "serving web > pages from a nonstandard directory" would be one of them), making sure > that EVERY STEP works. Right now the howto contains things that do not > work as advertised, and links to docs that reference stuff that is not > present, without a mention close by where to get it. I think Colin has/is working on such a guide. I agree that the existing documentation is inadequate, and that part of the problem is that there is too much reliance on documentation that predates the Fedora SELinux integration and doesn't reflect changes made for it. Even FC2->FC3 introduced a lot of changes, so some documentation that was updated for FC2 is now out of date. > - A lot of developers I know, including a bunch at Red Hat, *turn off > SELINUX entirely*. IMO, something that gets pushed at heavily as this > should be dogfooded by the development team at Red Hat completely, so > they encounter firsthand what it means and how to fix basic issues. > Knowledge spreads through increasingly growing circles starting from the > center. If all RH developers, who have "easy" access to the SELINUX > people at Red Hat, were to use it, they'd have basic knowledge about it. > When the next circle of developers - outside of redhat, but having links > to inside - gets hit, they do the same. And so on. > > It looks to me like the first circle is already completely broken, hence > halting the dissemination of information and increasing the annoyance > level outside of Red Hat. It won't be long before sysadmins and users > ignore the default and turn it off entirely. Fair point, no argument here. > - The documentation is not easy to find, out of date, and doesn't match > the system. IMO, if FC3 gets released, the howto for something as basic > as SELINUX should be uptodate and easy to find. Yes, and either there shouldn't be so much reliance on pre-existing documentation that predates Fedora SELinux integration or Fedora project should be submitting patches to update that pre-existing documentation. > I just want to get a good picture of where SELINUX is at and how to > solve issues, so that I can try to fix stuff myself, and explain to > other people. Otherwise I'll just have to turn off SELINUX myself, and > recommend the same to others when questions are asked about it. > > Feel free to comment, both on the particular issue at hand as well as > the general issue of entry barriers to selinux. Thanks for the feedback, and sorry for your troubles. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Tue Nov 9 15:43:08 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 09 Nov 2004 10:43:08 -0500 Subject: selinux and /etc/passwd In-Reply-To: <41905450.7020900@rogers.com> References: <41905450.7020900@rogers.com> Message-ID: <1100014988.408.115.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-11-09 at 00:23, Sergiu Giurgiu wrote: > hi, > I've just installed FC3 tonight (clean install) and ... I've came across > a small problem. > Users cannot be created. I hev created a user at the first-boot wizard, > I have tried to use the graphical tool, and ... at the console I tried > to use useradd. The wizard didn't say anything (like everything was ok), > the user/group manager graphical tool remain blocked when I pressed OK > to add a new user, but useradd said that it cannot alter /etc/passwd (I > don't recall the exact message). As a result, I couldn't add a new user. > To start eventually working, I have disabled selinux and rebooted. > everthing works fine now. > Given that I'm not quite knowledgeable about selinux (why is it there > and what is it doing), and this machine functions as a > workstation/desktop machine, I can say that I'm ok with this solution. > However I would like to know what was happening. Is it a bug (didn't > found reports about this)? It's a feature? Can it be fixed? If so, how? > The filesystem installed is reiserfs (does it matter?). > Thank you. What does 'audit2allow -v -i /var/log/messages' show? reiserfs doesn't yet support individual file labeling for SELinux, so all files in it are mapped to a single security type, but I would have expected you to be able to access it under the targeted policy just fine. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Wed Nov 10 15:40:32 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 10 Nov 2004 16:40:32 +0100 Subject: PHP cannot connect to mysql server Message-ID: <41923670.7070909@feuerpokemon.de> I am running FC3 with selinux on targeted policy. When PHP tryies to connect to the mysql server i get this messages in dmesg: sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Disabling SELinux for Apache fix this, but I want to run httpd with selinux. So how can i fix this? From selinux at gmail.com Wed Nov 10 15:40:11 2004 From: selinux at gmail.com (Tom London) Date: Wed, 10 Nov 2004 07:40:11 -0800 Subject: chkpwd_macros.te Message-ID: <4c4ba1530411100740553746b7@mail.gmail.com> running rawhide/strict, I get the following about once or twice a day: Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied { search } for pid=27040 exe=/sbin/unix_chkpwd name=run dev=hda2 ino=4456484 scontext=user_u:user_r:user_chkpwd_t tcontext=system_u:object_r:var_run_t tclass=dir Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied { search } for pid=27040 exe=/sbin/unix_chkpwd name=nscd dev=hda2 ino=4556982 scontext=user_u:user_r:user_chkpwd_t tcontext=system_u:object_r:nscd_var_run_t tclass=dir Suggest the following: --- SAVE/chkpwd_macros.te 2004-11-10 07:37:22.098409600 -0800 +++ ./chkpwd_macros.te 2004-11-10 07:38:32.387484758 -0800 @@ -67,6 +67,8 @@ # for nscd dontaudit $1_chkpwd_t var_t:dir search; +dontaudit $1_chkpwd_t var_run_t:dir search; +dontaudit $1_chkpwd_t nscd_var_run_t:dir search; dontaudit $1_chkpwd_t fs_t:filesystem getattr; ') tom -- Tom London From dwalsh at redhat.com Wed Nov 10 15:52:22 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 Nov 2004 10:52:22 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41923670.7070909@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> Message-ID: <41923936.6000307@redhat.com> dragoran wrote: > I am running FC3 with selinux on targeted policy. When PHP tryies to > connect to the mysql server i get this messages in dmesg: > sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t > tclass=sock_file > Disabling SELinux for Apache fix this, but I want to run httpd with > selinux. > So how can i fix this? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list A couple of things to try. I am thinking of adding mysqld.te file to targeted policy. (attached) You can try to use it by doing the following * Install selinux-policy-targeted-sources. * yum install selinux-policy-targeted-sources * cd /etc/selinux/targeted/src/policy * cp MYSQLD.te domains/program/ * make load * rpm -q -l mysql | restorecon -R -f - * service mysql restart Or you can just add the ability to write to sock_files in var lib. * Install selinux-policy-targeted-sources. * yum install selinux-policy-targeted-sources * cd /etc/selinux/targeted/src/policy * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > domains/program/httpd_socket.te * make load -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mysqld.te URL: From dwalsh at redhat.com Wed Nov 10 15:55:15 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 Nov 2004 10:55:15 -0500 Subject: chkpwd_macros.te In-Reply-To: <4c4ba1530411100740553746b7@mail.gmail.com> References: <4c4ba1530411100740553746b7@mail.gmail.com> Message-ID: <419239E3.4030709@redhat.com> Tom London wrote: >running rawhide/strict, > >I get the following about once or twice a day: > >Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied >{ search } for pid=27040 exe=/sbin/unix_chkpwd name=run dev=hda2 >ino=4456484 scontext=user_u:user_r:user_chkpwd_t >tcontext=system_u:object_r:var_run_t tclass=dir >Nov 10 06:49:17 fedora kernel: audit(1100098157.523:0): avc: denied >{ search } for pid=27040 exe=/sbin/unix_chkpwd name=nscd dev=hda2 >ino=4556982 scontext=user_u:user_r:user_chkpwd_t >tcontext=system_u:object_r:nscd_var_run_t tclass=dir > >Suggest the following: > >--- SAVE/chkpwd_macros.te 2004-11-10 07:37:22.098409600 -0800 >+++ ./chkpwd_macros.te 2004-11-10 07:38:32.387484758 -0800 >@@ -67,6 +67,8 @@ > > # for nscd > dontaudit $1_chkpwd_t var_t:dir search; >+dontaudit $1_chkpwd_t var_run_t:dir search; >+dontaudit $1_chkpwd_t nscd_var_run_t:dir search; > > dontaudit $1_chkpwd_t fs_t:filesystem getattr; > ') > >tom > > > This should fix it. diff -u chkpwd_macros.te~ chkpwd_macros.te --- chkpwd_macros.te~ 2004-11-09 14:08:33.000000000 -0500 +++ chkpwd_macros.te 2004-11-10 10:54:20.098525218 -0500 @@ -15,7 +15,7 @@ ifdef(`chkpwd.te', ` define(`chkpwd_domain',` # Derived domain based on the calling user domain and the program. -type $1_chkpwd_t, domain, privlog, auth; +type $1_chkpwd_t, domain, privlog, nscd_client_domain, auth; # is_selinux_enabled allow $1_chkpwd_t proc_t:file read; From sds at epoch.ncsc.mil Wed Nov 10 15:51:10 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 10 Nov 2004 10:51:10 -0500 Subject: chkpwd_macros.te In-Reply-To: <4c4ba1530411100740553746b7@mail.gmail.com> References: <4c4ba1530411100740553746b7@mail.gmail.com> Message-ID: <1100101870.1972.201.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-11-10 at 10:40, Tom London wrote: > Suggest the following: > > --- SAVE/chkpwd_macros.te 2004-11-10 07:37:22.098409600 -0800 > +++ ./chkpwd_macros.te 2004-11-10 07:38:32.387484758 -0800 > @@ -67,6 +67,8 @@ > > # for nscd > dontaudit $1_chkpwd_t var_t:dir search; > +dontaudit $1_chkpwd_t var_run_t:dir search; > +dontaudit $1_chkpwd_t nscd_var_run_t:dir search; > > dontaudit $1_chkpwd_t fs_t:filesystem getattr; > ') Hmmm...shouldn't $1_chkpwd_t by a nscd_client_domain? It seems legitimate for it to perform passwd lookups via nscd. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Wed Nov 10 16:05:02 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 10 Nov 2004 17:05:02 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <41923936.6000307@redhat.com> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> Message-ID: <41923C2E.4070507@feuerpokemon.de> Daniel J Walsh schrieb: > dragoran wrote: > >> I am running FC3 with selinux on targeted policy. When PHP tryies to >> connect to the mysql server i get this messages in dmesg: >> sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t >> tclass=sock_file >> Disabling SELinux for Apache fix this, but I want to run httpd with >> selinux. >> So how can i fix this? >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > A couple of things to try. > > I am thinking of adding mysqld.te file to targeted policy. (attached) > > You can try to use it by doing the following > > * Install selinux-policy-targeted-sources. > * yum install selinux-policy-targeted-sources > * cd /etc/selinux/targeted/src/policy > * cp MYSQLD.te domains/program/ > * make load > * rpm -q -l mysql | restorecon -R -f - > * service mysql restart > > Or you can just add the ability to write to sock_files in var lib. > > * Install selinux-policy-targeted-sources. > * yum install selinux-policy-targeted-sources > * cd /etc/selinux/targeted/src/policy > * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > > domains/program/httpd_socket.te > * make load > >------------------------------------------------------------------------ > >#DESC Mysqld - Database server ># ># Author: Russell Coker ># X-Debian-Packages: mysql-server ># > >################################# ># ># Rules for the mysqld_t domain. ># ># mysqld_exec_t is the type of the mysqld executable. ># >daemon_domain(mysqld) > >type mysqld_port_t, port_type; >allow mysqld_t mysqld_port_t:tcp_socket name_bind; > >allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; > >etcdir_domain(mysqld) >typealias mysqld_etc_t alias etc_mysqld_t; >type mysqld_db_t, file_type, sysadmfile; > >log_domain(mysqld) > ># for temporary tables >tmp_domain(mysqld) > >allow mysqld_t usr_t:file { getattr read }; > >allow mysqld_t self:fifo_file { read write }; >allow mysqld_t self:unix_stream_socket create_stream_socket_perms; >allow initrc_t mysqld_t:unix_stream_socket connectto; >allow initrc_t mysqld_var_run_t:sock_file write; > >allow initrc_t mysqld_log_t:file { write append setattr ioctl }; > >allow mysqld_t self:capability { dac_override setgid setuid }; >allow mysqld_t self:process getsched; > >allow mysqld_t proc_t:file { getattr read }; > ># Allow access to the mysqld databases >create_dir_file(mysqld_t, mysqld_db_t) >allow mysqld_t var_lib_t:dir { getattr search }; > >can_network(mysqld_t) >can_ypbind(mysqld_t) > ># read config files >r_dir_file(initrc_t, mysqld_etc_t) >allow mysqld_t { etc_t etc_runtime_t }:{ file lnk_file } { read getattr }; > >allow mysqld_t etc_t:dir search; > >allow mysqld_t sysctl_kernel_t:dir search; >allow mysqld_t sysctl_kernel_t:file read; > >can_unix_connect(sysadm_t, mysqld_t) > ># for /root/.my.cnf - should not be needed >allow mysqld_t sysadm_home_dir_t:dir search; >allow mysqld_t sysadm_home_t:file { read getattr }; > >ifdef(`logrotate.te', ` >r_dir_file(logrotate_t, mysqld_etc_t) >allow logrotate_t mysqld_db_t:dir search; >allow logrotate_t mysqld_var_run_t:dir search; >allow logrotate_t mysqld_var_run_t:sock_file write; >can_unix_connect(logrotate_t, mysqld_t) >') > >ifdef(`user_db_connect', ` >allow userdomain mysqld_var_run_t:dir search; >allow userdomain mysqld_var_run_t:sock_file write; >') > >ifdef(`daemontools.te', ` >domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t) >allow svc_start_t mysqld_t:process signal; >svc_ipc_domain(mysqld_t) >')dnl end ifdef daemontools > >ifdef(`distro_redhat', ` >allow initrc_t mysqld_db_t:dir create_dir_perms; > ># because Fedora has the sock_file in the database directory >file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file) >') > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > i tried this: Or you can just add the ability to write to sock_files in var lib. * Install selinux-policy-targeted-sources. * yum install selinux-policy-targeted-sources * cd /etc/selinux/targeted/src/policy * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > domains/program/httpd_socket.te * make load but i get this when excuting make load: domains/program/httpd_socket.te:2:ERROR 'permission bind is not defined for class sock_file' at token ';' on line 8239: allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr append bind connect getopt setopt shutdown }; #line 1 "domains/program/httpd_socket.te" domains/program/httpd_socket.te:2:ERROR 'permission connect is not defined for class sock_file' at token ';' on line 8239: allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr append bind connect getopt setopt shutdown }; #line 1 "domains/program/httpd_socket.te" domains/program/httpd_socket.te:2:ERROR 'permission getopt is not defined for class sock_file' at token ';' on line 8239: allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr append bind connect getopt setopt shutdown }; #line 1 "domains/program/httpd_socket.te" domains/program/httpd_socket.te:2:ERROR 'permission setopt is not defined for class sock_file' at token ';' on line 8239: allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr append bind connect getopt setopt shutdown }; #line 1 "domains/program/httpd_socket.te" domains/program/httpd_socket.te:2:ERROR 'permission shutdown is not defined for class sock_file' at token ';' on line 8239: allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr append bind connect getopt setopt shutdown }; #line 1 "domains/program/httpd_socket.te" security: 3 users, 4 roles, 280 types, 16 bools security: 53 classes, 5495 rules /usr/bin/checkpolicy: error(s) encountered while parsing configuration make: *** [/etc/selinux/targeted/policy/policy.18] Fehler 1 From dwalsh at redhat.com Wed Nov 10 16:17:59 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 Nov 2004 11:17:59 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41923C2E.4070507@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> Message-ID: <41923F37.3010808@redhat.com> dragoran wrote: > Daniel J Walsh schrieb: > >> dragoran wrote: >> >>> I am running FC3 with selinux on targeted policy. When PHP tryies to >>> connect to the mysql server i get this messages in dmesg: >>> sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t >>> tclass=sock_file >>> Disabling SELinux for Apache fix this, but I want to run httpd with >>> selinux. >>> So how can i fix this? >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> >> A couple of things to try. >> >> I am thinking of adding mysqld.te file to targeted policy. (attached) >> >> You can try to use it by doing the following >> >> * Install selinux-policy-targeted-sources. >> * yum install selinux-policy-targeted-sources >> * cd /etc/selinux/targeted/src/policy >> * cp MYSQLD.te domains/program/ >> * make load >> * rpm -q -l mysql | restorecon -R -f - >> * service mysql restart >> >> Or you can just add the ability to write to sock_files in var lib. >> >> * Install selinux-policy-targeted-sources. >> * yum install selinux-policy-targeted-sources >> * cd /etc/selinux/targeted/src/policy >> * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > >> domains/program/httpd_socket.te >> * make load >> >> ------------------------------------------------------------------------ >> >> #DESC Mysqld - Database server >> # >> # Author: Russell Coker >> # X-Debian-Packages: mysql-server >> # >> >> ################################# >> # >> # Rules for the mysqld_t domain. >> # >> # mysqld_exec_t is the type of the mysqld executable. >> # >> daemon_domain(mysqld) >> >> type mysqld_port_t, port_type; >> allow mysqld_t mysqld_port_t:tcp_socket name_bind; >> >> allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; >> >> etcdir_domain(mysqld) >> typealias mysqld_etc_t alias etc_mysqld_t; >> type mysqld_db_t, file_type, sysadmfile; >> >> log_domain(mysqld) >> >> # for temporary tables >> tmp_domain(mysqld) >> >> allow mysqld_t usr_t:file { getattr read }; >> >> allow mysqld_t self:fifo_file { read write }; >> allow mysqld_t self:unix_stream_socket create_stream_socket_perms; >> allow initrc_t mysqld_t:unix_stream_socket connectto; >> allow initrc_t mysqld_var_run_t:sock_file write; >> >> allow initrc_t mysqld_log_t:file { write append setattr ioctl }; >> >> allow mysqld_t self:capability { dac_override setgid setuid }; >> allow mysqld_t self:process getsched; >> >> allow mysqld_t proc_t:file { getattr read }; >> >> # Allow access to the mysqld databases >> create_dir_file(mysqld_t, mysqld_db_t) >> allow mysqld_t var_lib_t:dir { getattr search }; >> >> can_network(mysqld_t) >> can_ypbind(mysqld_t) >> >> # read config files >> r_dir_file(initrc_t, mysqld_etc_t) >> allow mysqld_t { etc_t etc_runtime_t }:{ file lnk_file } { read >> getattr }; >> >> allow mysqld_t etc_t:dir search; >> >> allow mysqld_t sysctl_kernel_t:dir search; >> allow mysqld_t sysctl_kernel_t:file read; >> >> can_unix_connect(sysadm_t, mysqld_t) >> >> # for /root/.my.cnf - should not be needed >> allow mysqld_t sysadm_home_dir_t:dir search; >> allow mysqld_t sysadm_home_t:file { read getattr }; >> >> ifdef(`logrotate.te', ` >> r_dir_file(logrotate_t, mysqld_etc_t) >> allow logrotate_t mysqld_db_t:dir search; >> allow logrotate_t mysqld_var_run_t:dir search; >> allow logrotate_t mysqld_var_run_t:sock_file write; >> can_unix_connect(logrotate_t, mysqld_t) >> ') >> >> ifdef(`user_db_connect', ` >> allow userdomain mysqld_var_run_t:dir search; >> allow userdomain mysqld_var_run_t:sock_file write; >> ') >> >> ifdef(`daemontools.te', ` >> domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t) >> allow svc_start_t mysqld_t:process signal; >> svc_ipc_domain(mysqld_t) >> ')dnl end ifdef daemontools >> >> ifdef(`distro_redhat', ` >> allow initrc_t mysqld_db_t:dir create_dir_perms; >> >> # because Fedora has the sock_file in the database directory >> file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file) >> ') >> >> >> ------------------------------------------------------------------------ >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > i tried this: > Or you can just add the ability to write to sock_files in var lib. > > * Install selinux-policy-targeted-sources. > * yum install selinux-policy-targeted-sources > * cd /etc/selinux/targeted/src/policy > * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > > domains/program/httpd_socket.te Sorry make that rw_file_perms; > * make load > but i get this when excuting make load: > domains/program/httpd_socket.te:2:ERROR 'permission bind is not > defined for class sock_file' at token ';' on line 8239: > allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr > append bind connect getopt setopt shutdown }; > #line 1 "domains/program/httpd_socket.te" > domains/program/httpd_socket.te:2:ERROR 'permission connect is not > defined for class sock_file' at token ';' on line 8239: > allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr > append bind connect getopt setopt shutdown }; > #line 1 "domains/program/httpd_socket.te" > domains/program/httpd_socket.te:2:ERROR 'permission getopt is not > defined for class sock_file' at token ';' on line 8239: > allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr > append bind connect getopt setopt shutdown }; > #line 1 "domains/program/httpd_socket.te" > domains/program/httpd_socket.te:2:ERROR 'permission setopt is not > defined for class sock_file' at token ';' on line 8239: > allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr > append bind connect getopt setopt shutdown }; > #line 1 "domains/program/httpd_socket.te" > domains/program/httpd_socket.te:2:ERROR 'permission shutdown is not > defined for class sock_file' at token ';' on line 8239: > allow httpd_t var_lib_t:sock_file { ioctl read getattr write setattr > append bind connect getopt setopt shutdown }; > #line 1 "domains/program/httpd_socket.te" > security: 3 users, 4 roles, 280 types, 16 bools > security: 53 classes, 5495 rules > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > make: *** [/etc/selinux/targeted/policy/policy.18] Fehler 1 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at epoch.ncsc.mil Wed Nov 10 16:19:03 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 10 Nov 2004 11:19:03 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41923C2E.4070507@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> Message-ID: <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-11-10 at 11:05, dragoran wrote: > * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > > domains/program/httpd_socket.te Yes, that instruction was incorrect. Two different objects for a Unix domain socket: the file that is used to "name" it, and the socket itself. So you need something like: allow httpd_t var_lib_t:sock_file rw_file_perms; can_unix_send(httpd_t, unconfined_t) can_unix_connect(httpd_t, unconfined_t) The first line allows it to access the file object, while the latter two lines allow the inter-process communication between httpd and the mysqld (which is running unconfined by default in the targeted policy). The obvious problem with this approach is that an exploit of a flaw in your httpd can now reach an unconfined process, possibly subverting it and thus gaining full access to the system. Better to add a separate domain for mysqld. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Wed Nov 10 16:25:57 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 10 Nov 2004 17:25:57 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41924115.9050305@feuerpokemon.de> Stephen Smalley schrieb: >On Wed, 2004-11-10 at 11:05, dragoran wrote: > > >> * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > >> domains/program/httpd_socket.te >> >> > >Yes, that instruction was incorrect. Two different objects for a Unix >domain socket: the file that is used to "name" it, and the socket >itself. So you need something like: > >allow httpd_t var_lib_t:sock_file rw_file_perms; >can_unix_send(httpd_t, unconfined_t) >can_unix_connect(httpd_t, unconfined_t) > >The first line allows it to access the file object, while the latter two >lines allow the inter-process communication between httpd and the mysqld >(which is running unconfined by default in the targeted policy). The >obvious problem with this approach is that an exploit of a flaw in your >httpd can now reach an unconfined process, possibly subverting it and >thus gaining full access to the system. Better to add a separate domain >for mysqld. > > > and how can I add a separte doiman for mysqld ? Sorry I am new to selinux.... From dwalsh at redhat.com Wed Nov 10 16:30:49 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 Nov 2004 11:30:49 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41924115.9050305@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> Message-ID: <41924239.1070100@redhat.com> dragoran wrote: > Stephen Smalley schrieb: > >> On Wed, 2004-11-10 at 11:05, dragoran wrote: >> >> >>> * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > >>> domains/program/httpd_socket.te >>> >> >> >> Yes, that instruction was incorrect. Two different objects for a Unix >> domain socket: the file that is used to "name" it, and the socket >> itself. So you need something like: >> >> allow httpd_t var_lib_t:sock_file rw_file_perms; >> can_unix_send(httpd_t, unconfined_t) >> can_unix_connect(httpd_t, unconfined_t) >> >> The first line allows it to access the file object, while the latter two >> lines allow the inter-process communication between httpd and the mysqld >> (which is running unconfined by default in the targeted policy). The >> obvious problem with this approach is that an exploit of a flaw in your >> httpd can now reach an unconfined process, possibly subverting it and >> thus gaining full access to the system. Better to add a separate domain >> for mysqld. >> >> >> > and how can I add a separte doiman for mysqld ? Sorry I am new to > selinux.... > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Follow the first part of my orignal reply You can try to use it by doing the following MYSQLD.te is the attached file * Install selinux-policy-targeted-sources. * yum install selinux-policy-targeted-sources * cd /etc/selinux/targeted/src/policy * cp MYSQLD.te domains/program/ * make load * rpm -q -l mysql | restorecon -R -f - * service mysql restart -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mysqld.te URL: From sds at epoch.ncsc.mil Wed Nov 10 16:29:57 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 10 Nov 2004 11:29:57 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41924115.9050305@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> Message-ID: <1100104197.1972.227.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-11-10 at 11:25, dragoran wrote: > and how can I add a separte doiman for mysqld ? Sorry I am new to > selinux.... That was the first option suggested in Dan's initial reply, i.e. add the mysqld.te file he included in his reply to your policy, reload it, apply the file labels, and restart mysql. Then mysqld should run in its own domain (mysqld_t), the socket file should have a distinct type (mysqld_var_run_t), and you should be able to selectively allow httpd_t to connect to it without exposing the rest of your system. -- Stephen Smalley National Security Agency From dragoran at feuerpokemon.de Wed Nov 10 16:37:39 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Wed, 10 Nov 2004 17:37:39 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <41924239.1070100@redhat.com> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> Message-ID: <419243D3.90907@feuerpokemon.de> Daniel J Walsh schrieb: > dragoran wrote: > >> Stephen Smalley schrieb: >> >>> On Wed, 2004-11-10 at 11:05, dragoran wrote: >>> >>> >>>> * echo "allow httpd_t var_lib_t:sock_file rw_socket_perms;" > >>>> domains/program/httpd_socket.te >>>> >>> >>> >>> >>> Yes, that instruction was incorrect. Two different objects for a Unix >>> domain socket: the file that is used to "name" it, and the socket >>> itself. So you need something like: >>> >>> allow httpd_t var_lib_t:sock_file rw_file_perms; >>> can_unix_send(httpd_t, unconfined_t) >>> can_unix_connect(httpd_t, unconfined_t) >>> >>> The first line allows it to access the file object, while the latter >>> two >>> lines allow the inter-process communication between httpd and the >>> mysqld >>> (which is running unconfined by default in the targeted policy). The >>> obvious problem with this approach is that an exploit of a flaw in your >>> httpd can now reach an unconfined process, possibly subverting it and >>> thus gaining full access to the system. Better to add a separate >>> domain >>> for mysqld. >>> >>> >>> >> and how can I add a separte doiman for mysqld ? Sorry I am new to >> selinux.... >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > Follow the first part of my orignal reply > You can try to use it by doing the following > MYSQLD.te is the attached file > > * Install selinux-policy-targeted-sources. > * yum install selinux-policy-targeted-sources > * cd /etc/selinux/targeted/src/policy > * cp MYSQLD.te domains/program/ > * make load > * rpm -q -l mysql | restorecon -R -f - > * service mysql restart > >------------------------------------------------------------------------ > >#DESC Mysqld - Database server ># ># Author: Russell Coker ># X-Debian-Packages: mysql-server ># > >################################# ># ># Rules for the mysqld_t domain. ># ># mysqld_exec_t is the type of the mysqld executable. ># >daemon_domain(mysqld) > >type mysqld_port_t, port_type; >allow mysqld_t mysqld_port_t:tcp_socket name_bind; > >allow mysqld_t mysqld_var_run_t:sock_file create_file_perms; > >etcdir_domain(mysqld) >typealias mysqld_etc_t alias etc_mysqld_t; >type mysqld_db_t, file_type, sysadmfile; > >log_domain(mysqld) > ># for temporary tables >tmp_domain(mysqld) > >allow mysqld_t usr_t:file { getattr read }; > >allow mysqld_t self:fifo_file { read write }; >allow mysqld_t self:unix_stream_socket create_stream_socket_perms; >allow initrc_t mysqld_t:unix_stream_socket connectto; >allow initrc_t mysqld_var_run_t:sock_file write; > >allow initrc_t mysqld_log_t:file { write append setattr ioctl }; > >allow mysqld_t self:capability { dac_override setgid setuid }; >allow mysqld_t self:process getsched; > >allow mysqld_t proc_t:file { getattr read }; > ># Allow access to the mysqld databases >create_dir_file(mysqld_t, mysqld_db_t) >allow mysqld_t var_lib_t:dir { getattr search }; > >can_network(mysqld_t) >can_ypbind(mysqld_t) > ># read config files >r_dir_file(initrc_t, mysqld_etc_t) >allow mysqld_t { etc_t etc_runtime_t }:{ file lnk_file } { read getattr }; > >allow mysqld_t etc_t:dir search; > >allow mysqld_t sysctl_kernel_t:dir search; >allow mysqld_t sysctl_kernel_t:file read; > >can_unix_connect(sysadm_t, mysqld_t) > ># for /root/.my.cnf - should not be needed >allow mysqld_t sysadm_home_dir_t:dir search; >allow mysqld_t sysadm_home_t:file { read getattr }; > >ifdef(`logrotate.te', ` >r_dir_file(logrotate_t, mysqld_etc_t) >allow logrotate_t mysqld_db_t:dir search; >allow logrotate_t mysqld_var_run_t:dir search; >allow logrotate_t mysqld_var_run_t:sock_file write; >can_unix_connect(logrotate_t, mysqld_t) >') > >ifdef(`user_db_connect', ` >allow userdomain mysqld_var_run_t:dir search; >allow userdomain mysqld_var_run_t:sock_file write; >') > >ifdef(`daemontools.te', ` >domain_auto_trans( svc_run_t, mysqld_exec_t, mysqld_t) >allow svc_start_t mysqld_t:process signal; >svc_ipc_domain(mysqld_t) >')dnl end ifdef daemontools > >ifdef(`distro_redhat', ` >allow initrc_t mysqld_db_t:dir create_dir_perms; > ># because Fedora has the sock_file in the database directory >file_type_auto_trans(mysqld_t, mysqld_db_t, mysqld_var_run_t, sock_file) >') > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > thx it seems to work ;) From franks at afrl.kirtland.af.mil Wed Nov 10 16:39:30 2004 From: franks at afrl.kirtland.af.mil (Ed Franks) Date: Wed, 10 Nov 2004 09:39:30 -0700 Subject: subscribe Message-ID: <200411101640.iAAGeiJ7002646@bell.kirtland.af.mil> FYI: I found this list email address in the new O'Reilly book: "SELINUX NSA's Open Source Security Enhanced Linux" by Bill McCarty ... which just hit the street. On pg 198, it posts this email address as a place to review postings. You may expect many more hits due to this new published work. I have been a follower of SELinux for over 3 years: since attending Stephen Smalley's presentation at USENIX June 2001 in Boston. I have explored quite a bit with SELinux, LIDS, and other implementations of the Linux kernel capabilities features. regards, ed -- Ed Franks Contracted to: SysAdmin - Solaris/Linux/Security o CIO Office UNISYS Federal Systems _.<\-' Air Force Research Lab Albuquerque, New Mexico ...(_)/_(_) Kirtland AFB From patrick at fany.info Thu Nov 11 03:55:57 2004 From: patrick at fany.info (Patrick Chiang) Date: Wed, 10 Nov 2004 22:55:57 -0500 Subject: Dont know the meaning of sestatus's report In-Reply-To: <1091228285.11946.13582.camel@erato.phig.org> References: <20040605160027.A1B787590F@hormel.redhat.com> <40C21435.9080803@mcgill.ca> <1091228285.11946.13582.camel@erato.phig.org> Message-ID: <1100145357.22237.8.camel@ASHLEY.YUN.TO> Dear all, I'm new to SELinux, hopefully my question is not a FAQ, I've googled around for a while but still no clues at all. while I run sestatus, I found these messages... allow_ypbind inactive httpd_disable_trans inactive httpd_enable_cgi active httpd_enable_homedirs active httpd_ssi_exec active httpd_unified active named_disable_trans inactive named_write_master_zonesinactive some of them are easy to understand, but the rest phrases, such as named_disable_trans, httpd_unified, are rather difficult. Does anybody know how to decode these? TIA, Patrick From dragoran at feuerpokemon.de Thu Nov 11 06:10:32 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 11 Nov 2004 07:10:32 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <419243D3.90907@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> Message-ID: <41930258.9080408@feuerpokemon.de> no it sitill don't work... after a reboot i now get this messages in demsg: audit(1100152360.021:0): avc: denied { write } for pid=2635 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file audit(1100152677.098:0): avc: denied { append } for pid=4078 exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t tclass=file audit(1100152677.099:0): avc: denied { append } for pid=4078 exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t tclass=file audit(1100152682.751:0): avc: denied { write } for pid=2636 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=root:object_r:mysqld_var_run_t tclass=sock_file audit(1100152683.427:0): avc: denied { write } for pid=2636 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=root:object_r:mysqld_var_run_t tclass=sock_file audit(1100152683.978:0): avc: denied { write } for pid=2636 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=root:object_r:mysqld_var_run_t tclass=sock_file audit(1100152755.278:0): avc: denied { write } for pid=2637 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=root:object_r:mysqld_var_run_t tclass=sock_file audit(1100152756.063:0): avc: denied { write } for pid=2637 exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 scontext=user_u:system_r:httpd_t tcontext=root:object_r:mysqld_var_run_t tclass=sock_file mysql cannot access the log file and httpd still canncot connect to the mysql socket ... From dwalsh at redhat.com Thu Nov 11 10:59:40 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Nov 2004 05:59:40 -0500 Subject: Dont know the meaning of sestatus's report In-Reply-To: <1100145357.22237.8.camel@ASHLEY.YUN.TO> References: <20040605160027.A1B787590F@hormel.redhat.com> <40C21435.9080803@mcgill.ca> <1091228285.11946.13582.camel@erato.phig.org> <1100145357.22237.8.camel@ASHLEY.YUN.TO> Message-ID: <4193461C.8050904@redhat.com> Patrick Chiang wrote: >Dear all, > >I'm new to SELinux, >hopefully my question is not a FAQ, >I've googled around for a while but still no clues at all. > >while I run sestatus, I found these messages... > >allow_ypbind inactive >httpd_disable_trans inactive >httpd_enable_cgi active >httpd_enable_homedirs active >httpd_ssi_exec active >httpd_unified active >named_disable_trans inactive >named_write_master_zonesinactive > >some of them are easy to understand, >but the rest phrases, such as named_disable_trans, httpd_unified, are >rather difficult. > > If you use system-config-securitylevel, these booleans get a better translation. It probably would be a good idea to use the translation table in s-c-sl for this tool. (Put it on my todo list. :^)) SERVICE_disable_trans - if active means that the SERVICE will run without SELinux protection, so if I can not get apache to run under SELinux I could specify setsebool -P httpd_disable_trans 1 And then restart httpd, it will now run under unconfined_t instead of httpd_t. httpd_unified - tells policy to treat all files marked as httpd content the same way. So httpd and freiends can read/write/execute all content. >Does anybody know how to decode these? > >TIA, > >Patrick > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dwalsh at redhat.com Thu Nov 11 11:08:25 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Nov 2004 06:08:25 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41930258.9080408@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> Message-ID: <41934829.5090408@redhat.com> dragoran wrote: > no it sitill don't work... after a reboot i now get this messages in > demsg: > audit(1100152360.021:0): avc: denied { write } for pid=2635 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t > tclass=sock_file > audit(1100152677.098:0): avc: denied { append } for pid=4078 > exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 > scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t > tclass=file > audit(1100152677.099:0): avc: denied { append } for pid=4078 > exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 > scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t > tclass=file > audit(1100152682.751:0): avc: denied { write } for pid=2636 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t > tcontext=root:object_r:mysqld_var_run_t tclass=sock_file > audit(1100152683.427:0): avc: denied { write } for pid=2636 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t > tcontext=root:object_r:mysqld_var_run_t tclass=sock_file > audit(1100152683.978:0): avc: denied { write } for pid=2636 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t > tcontext=root:object_r:mysqld_var_run_t tclass=sock_file > audit(1100152755.278:0): avc: denied { write } for pid=2637 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t > tcontext=root:object_r:mysqld_var_run_t tclass=sock_file > audit(1100152756.063:0): avc: denied { write } for pid=2637 > exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 > scontext=user_u:system_r:httpd_t > tcontext=root:object_r:mysqld_var_run_t tclass=sock_file > mysql cannot access the log file and httpd still canncot connect to > the mysql socket ... > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Looks like you have it mislabled. Did you do a rpm -q -l mysql | restorecon -R -f - ???? The labels on a few files are wrong. Dan From patrick at fany.info Thu Nov 11 14:01:21 2004 From: patrick at fany.info (Patrick Chiang) Date: Thu, 11 Nov 2004 09:01:21 -0500 Subject: Dont know the meaning of sestatus's report In-Reply-To: <4193461C.8050904@redhat.com> References: <20040605160027.A1B787590F@hormel.redhat.com> <40C21435.9080803@mcgill.ca> <1091228285.11946.13582.camel@erato.phig.org> <1100145357.22237.8.camel@ASHLEY.YUN.TO> <4193461C.8050904@redhat.com> Message-ID: <1100181681.3094.5.camel@ASHLEY.YUN.TO> Thanks Daniel, your approach is really smart :) I used to change the settings by the following, # cd /etc/selinux/$selinux_policy/ # vi booleans (change something from F to T or vice versa) # load_policy policy/policy.18 booleans now setsebool -P httpd_disable_trans 1 looks much cool :-) thanks for sharing your experience :) Patrick > > > If you use system-config-securitylevel, these booleans get a better > translation. It probably would be > a good idea to use the translation table in s-c-sl for this tool. (Put > it on my todo list. :^)) > > SERVICE_disable_trans - if active means that the SERVICE will run > without SELinux protection, > so if I can not get apache to run under SELinux I could specify > > setsebool -P httpd_disable_trans 1 > > And then restart httpd, it will now run under unconfined_t instead of > httpd_t. > > httpd_unified - tells policy to treat all files marked as httpd content > the same way. > So httpd and freiends can read/write/execute all content. > > >Does anybody know how to decode these? From jwr at xmission.com Thu Nov 11 14:38:24 2004 From: jwr at xmission.com (Jared W. Robinson) Date: Thu, 11 Nov 2004 07:38:24 -0700 Subject: SELinux, httpd and TWiki in FC3 Message-ID: <41937960.5050700@xmission.com> Here's my notes on getting Apache & TWiki to run under SELinux. Basically, I think most people will want to turn SELinux off for apache, but it's not easy without turning it off for the other targeted services too. First, I wanted to disable SELinux for just Apache, which is supposed to be possible. I ran "system-config-securitylevel", selected the "SELinux" tab, and opened the "transition" list, and selected "Disable Selinux protection for httpd daemon", , clicked "ok", then restarted httpd. Unfortunately, this didn't work. Second, I stopped enforcing SELinux policy, and noticed that TWiki ran just fine. I'd recommend that people get their cgi scripts running correctly without SELinux before trying to troubleshoot further. Third, I started enforcing SELinux policy again, and I made sure I set the types appropriately for the cgi scripts and for the files the scripts read/write to using chcon -t httpd_user_script_exec_t chcon -t httpd_sys_content_t I also used "system-config-securitylevel" and enabled some of the options for Apache -- the unification of types to httpd_sys_content_t, allowing of cgi scripts. Fourth, I watched /var/log/messages for "avc: denied" messages, and used audit2allow to generate rules: $ cd /etc/selinux/targeted/src/policy $ audit2allow -d -l -o domains/misc/local.te $ vi domains/misc/local.te $ make reload $ service httpd restart And I repeated this process several times, merging the appropriate new rules from audit2allow into my original local.te file. Here's my local.te file that seems to work so far: allow httpd_sys_script_t sysctl_kernel_t:dir { search }; allow httpd_sys_script_t sysctl_kernel_t:file { read }; allow httpd_sys_script_t sysctl_t:dir { search }; allow httpd_sys_script_t tmp_t:lnk_file { read }; allow httpd_sys_script_t httpd_sys_content_t:dir { read }; allow httpd_sys_script_t httpd_sys_content_t:file { append }; allow httpd_sys_script_t httpd_sys_content_t:dir { write }; allow httpd_sys_script_t httpd_sys_content_t:file { write }; allow httpd_sys_script_t httpd_sys_content_t:dir { add_name }; allow httpd_sys_script_t httpd_sys_content_t:file { create }; allow httpd_sys_script_t httpd_sys_content_t:file { setattr }; allow httpd_sys_script_t httpd_sys_content_t:dir { remove_name }; allow httpd_sys_script_t httpd_sys_content_t:file { rename }; allow httpd_sys_script_t httpd_sys_content_t:file { unlink }; I found the following presentation to be quite helpful: http://web.verbum.org/selinux/linuxfest/img0.html http://web.verbum.org/selinux/linuxfest/text21.html (good slide) And this was also helpful: http://people.redhat.com/walters/selinux-apache-en/index.html In the end, I'm glad that turning of the targeted policy for httpd didn't work (using system-config-securitylevel). It forced me to learn more about SELinux (although I feel like I'm just beginning), and hopefully, my server is more secure than before. - Jared From dwalsh at redhat.com Thu Nov 11 16:40:07 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 11 Nov 2004 11:40:07 -0500 Subject: SELinux, httpd and TWiki in FC3 In-Reply-To: <41937960.5050700@xmission.com> References: <41937960.5050700@xmission.com> Message-ID: <419395E7.1060308@redhat.com> Jared W. Robinson wrote: > Here's my notes on getting Apache & TWiki to run under SELinux. > Basically, I think most people will want to turn SELinux off for > apache, but it's not easy without turning it off for the other > targeted services too. > > First, I wanted to disable SELinux for just Apache, which is supposed > to be possible. I ran "system-config-securitylevel", selected the > "SELinux" tab, and opened the > "transition" list, and selected "Disable Selinux protection for httpd > daemon", > , clicked "ok", then restarted httpd. Unfortunately, this didn't work. What didn't work? What went wrong? Do you have any AVC Messages? > > Second, I stopped enforcing SELinux policy, and noticed that TWiki ran > just fine. I'd recommend that people get their cgi scripts running > correctly without SELinux before trying to troubleshoot further. > > Third, I started enforcing SELinux policy again, and I made sure I set > the types appropriately for the cgi scripts and for the files the > scripts read/write to using > chcon -t httpd_user_script_exec_t > chcon -t httpd_sys_content_t You might want to change this to chcon -t httpd_sys_script_rw_t Which would eliminate a lot of AVC messages from below. httpd_sys_content_t should only be for static content. > I also used "system-config-securitylevel" and enabled some of the > options for Apache -- the unification of types to httpd_sys_content_t, > allowing of cgi scripts. > > Fourth, I watched /var/log/messages for "avc: denied" messages, and > used audit2allow to generate rules: > $ cd /etc/selinux/targeted/src/policy > $ audit2allow -d -l -o domains/misc/local.te > $ vi domains/misc/local.te > $ make reload > $ service httpd restart > And I repeated this process several times, merging the appropriate new > rules from audit2allow into my original local.te file. > > Here's my local.te file that seems to work so far: > allow httpd_sys_script_t sysctl_kernel_t:dir { search }; > allow httpd_sys_script_t sysctl_kernel_t:file { read }; > allow httpd_sys_script_t sysctl_t:dir { search }; What is asking for these? > allow httpd_sys_script_t tmp_t:lnk_file { read }; /usr/tmp? > allow httpd_sys_script_t httpd_sys_content_t:dir { read }; > allow httpd_sys_script_t httpd_sys_content_t:file { append }; > allow httpd_sys_script_t httpd_sys_content_t:dir { write }; > allow httpd_sys_script_t httpd_sys_content_t:file { write }; > allow httpd_sys_script_t httpd_sys_content_t:dir { add_name }; > allow httpd_sys_script_t httpd_sys_content_t:file { create }; > allow httpd_sys_script_t httpd_sys_content_t:file { setattr }; > allow httpd_sys_script_t httpd_sys_content_t:dir { remove_name }; > allow httpd_sys_script_t httpd_sys_content_t:file { rename }; > allow httpd_sys_script_t httpd_sys_content_t:file { unlink }; > Changing httpd_sys_content_t to httpd_sys_script_rw_t would fix most of these? What is the settings of httpd_unified? > I found the following presentation to be quite helpful: > http://web.verbum.org/selinux/linuxfest/img0.html > http://web.verbum.org/selinux/linuxfest/text21.html (good slide) > > And this was also helpful: > http://people.redhat.com/walters/selinux-apache-en/index.html > > In the end, I'm glad that turning of the targeted policy for httpd > didn't work (using system-config-securitylevel). It forced me to learn > more about SELinux (although I feel like I'm just beginning), and > hopefully, my server is more secure than before. > - Jared > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From jwr at xmission.com Thu Nov 11 18:07:44 2004 From: jwr at xmission.com (Jared W. Robinson) Date: Thu, 11 Nov 2004 11:07:44 -0700 Subject: SELinux, httpd and TWiki in FC3 In-Reply-To: <419395E7.1060308@redhat.com> References: <41937960.5050700@xmission.com> <419395E7.1060308@redhat.com> Message-ID: <20041111180744.GA15291@mars.localdomain> On Thu, Nov 11, 2004 at 11:40:07AM -0500, Daniel J Walsh wrote: > Jared W. Robinson wrote: > > >First, I wanted to disable SELinux for just Apache, which is supposed > >to be possible. I ran "system-config-securitylevel", selected the > >"SELinux" tab, and opened the "transition" list, and selected > >"Disable Selinux protection for httpd daemon", , clicked "ok", then > >restarted httpd. Unfortunately, this didn't work. > > What didn't work? What went wrong? Do you have any AVC Messages? I'm assuming that when I selected to disable the protection for httpd, and I select "OK" on the dialog (in system-config-securitylevel), then httpd would run as if it weren't being restricted by SELinux anymore. But, I still got the same AVC denied messages as before I tried to disable it. > >Third, I started enforcing SELinux policy again, and I made sure I set > >the types appropriately for the cgi scripts and for the files the > >scripts read/write to using > >chcon -t httpd_user_script_exec_t > >chcon -t httpd_sys_content_t > > You might want to change this to > chcon -t httpd_sys_script_rw_t > Which would eliminate a lot of AVC messages from below. > > httpd_sys_content_t should only be for static content. Thanks; I've now changed them. > >Here's my local.te file that seems to work so far: > >allow httpd_sys_script_t sysctl_kernel_t:dir { search }; > >allow httpd_sys_script_t sysctl_kernel_t:file { read }; > >allow httpd_sys_script_t sysctl_t:dir { search }; > > What is asking for these? Good question. I'm assuming that it's something from one of the TWiki cgi scripts. > >allow httpd_sys_script_t tmp_t:lnk_file { read }; > > /usr/tmp? Don't know. It might be nice if the AVC messages gave full paths -- but I guess SELinux works with objects, not paths, right? > >allow httpd_sys_script_t httpd_sys_content_t:dir { read }; > >allow httpd_sys_script_t httpd_sys_content_t:file { append }; > >allow httpd_sys_script_t httpd_sys_content_t:dir { write }; > >allow httpd_sys_script_t httpd_sys_content_t:file { write }; > >allow httpd_sys_script_t httpd_sys_content_t:dir { add_name }; > >allow httpd_sys_script_t httpd_sys_content_t:file { create }; > >allow httpd_sys_script_t httpd_sys_content_t:file { setattr }; > >allow httpd_sys_script_t httpd_sys_content_t:dir { remove_name }; > >allow httpd_sys_script_t httpd_sys_content_t:file { rename }; > >allow httpd_sys_script_t httpd_sys_content_t:file { unlink }; > > > Changing httpd_sys_content_t to httpd_sys_script_rw_t would fix most of > these? I tried that, and turned off httpd_unified (I think), and now I get this: Nov 11 10:56:08 myhost kernel: audit(1100195768.763:0): avc: denied { execute } for pid=24886 exe=/usr/sbin/httpd name=view dev=dm-1 ino=1329201 scontext=root:system_r:httpd_t tcontext=user_u:object_r:httpd_sys_content_t tclass=file What should I do about that? The "view" cgi script has user_u:object_r:httpd_sys_script_exec_t as the type. > What is the settings of httpd_unified? If httpd_unified correlates with the similiar named setting in system-config-securitylevel, then it is enabled (except when I turned it off for my test above). I think I prefer to run with httpd_unified, and the local.te policy that I already have, simply because it works. - Jared From dragoran at feuerpokemon.de Thu Nov 11 18:28:35 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 11 Nov 2004 19:28:35 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <41934829.5090408@redhat.com> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> Message-ID: <4193AF53.6090909@feuerpokemon.de> Daniel J Walsh schrieb: > dragoran wrote: > >> no it sitill don't work... after a reboot i now get this messages in >> demsg: >> audit(1100152360.021:0): avc: denied { write } for pid=2635 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t >> tclass=sock_file >> audit(1100152677.098:0): avc: denied { append } for pid=4078 >> exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 >> scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t >> tclass=file >> audit(1100152677.099:0): avc: denied { append } for pid=4078 >> exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 >> scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t >> tclass=file >> audit(1100152682.751:0): avc: denied { write } for pid=2636 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t >> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >> audit(1100152683.427:0): avc: denied { write } for pid=2636 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t >> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >> audit(1100152683.978:0): avc: denied { write } for pid=2636 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t >> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >> audit(1100152755.278:0): avc: denied { write } for pid=2637 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t >> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >> audit(1100152756.063:0): avc: denied { write } for pid=2637 >> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >> scontext=user_u:system_r:httpd_t >> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >> mysql cannot access the log file and httpd still canncot connect to >> the mysql socket ... >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > Looks like you have it mislabled. > > Did you do a > > rpm -q -l mysql | restorecon -R -f - > > ???? > > The labels on a few files are wrong. > > Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > php now works but mysql still can't write to its log file: -rw-r----- mysql mysql system_u:object_r:var_log_t mysqld.log seems to be wrong but how do i change it? i have run rpm -q -l mysql | restorecon -R -f - but it did'nt help. From dragoran at feuerpokemon.de Thu Nov 11 18:36:32 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 11 Nov 2004 19:36:32 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <4193AF53.6090909@feuerpokemon.de> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> <4193AF53.6090909@feuerpokemon.de> Message-ID: <4193B130.7050000@feuerpokemon.de> dragoran schrieb: > Daniel J Walsh schrieb: > >> dragoran wrote: >> >>> no it sitill don't work... after a reboot i now get this messages in >>> demsg: >>> audit(1100152360.021:0): avc: denied { write } for pid=2635 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t >>> tclass=sock_file >>> audit(1100152677.098:0): avc: denied { append } for pid=4078 >>> exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 >>> scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t >>> tclass=file >>> audit(1100152677.099:0): avc: denied { append } for pid=4078 >>> exe=/usr/libexec/mysqld path=/var/log/mysqld.log dev=hda3 ino=765672 >>> scontext=root:system_r:mysqld_t tcontext=system_u:object_r:var_log_t >>> tclass=file >>> audit(1100152682.751:0): avc: denied { write } for pid=2636 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t >>> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >>> audit(1100152683.427:0): avc: denied { write } for pid=2636 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t >>> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >>> audit(1100152683.978:0): avc: denied { write } for pid=2636 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t >>> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >>> audit(1100152755.278:0): avc: denied { write } for pid=2637 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t >>> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >>> audit(1100152756.063:0): avc: denied { write } for pid=2637 >>> exe=/usr/sbin/httpd name=mysql.sock dev=hda3 ino=309535 >>> scontext=user_u:system_r:httpd_t >>> tcontext=root:object_r:mysqld_var_run_t tclass=sock_file >>> mysql cannot access the log file and httpd still canncot connect to >>> the mysql socket ... >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> Looks like you have it mislabled. >> >> Did you do a >> >> rpm -q -l mysql | restorecon -R -f - >> >> ???? >> >> The labels on a few files are wrong. >> >> Dan >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > php now works but mysql still can't write to its log file: > -rw-r----- mysql mysql system_u:object_r:var_log_t mysqld.log > seems to be wrong but how do i change it? i have run rpm -q -l mysql > | restorecon -R -f - but it did'nt help. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > restorecon -R -v /var/log solved it From i.pilcher at comcast.net Fri Nov 12 06:18:01 2004 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 12 Nov 2004 00:18:01 -0600 Subject: Making content readable by httpd Message-ID: I am trying to get Netjuke (http://www.netjuke.org/) working on FC3 with SELinux enabled. Netjuke is a PHP-based "jukebox" application, and I use it to stream Ogg Vorbis music files around my house. The music files live on several separate reiserfs filesystems, which have no security contexts at all. (These filesystems are mounted under /mnt and symlinked into the /var/www/html tree, if it makes any difference.) I've read through the FC3 SELinux FAQ and the man pages for setfiles, fixfiles, and restorecon, and I've even tried playing with the options that look nondestructive, but none the tools find anything wrong with the current setup. What do I need to do to make these files readable by the httpd server? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sds at epoch.ncsc.mil Fri Nov 12 12:19:19 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 12 Nov 2004 07:19:19 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41934829.5090408@redhat.com> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> Message-ID: <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> You still need to add rules allowing httpd to talk to mysqld. Adding mysqld.te just created a separate domain for it (not sure about the log file problem). So you still need to add: allow httpd_t mysqld_var_run_t:sock_file rw_file_perms; can_unix_connect(httpd_t, mysqld_t) can_unix_send(httpd_t, mysqld_t) -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Nov 12 12:37:53 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 12 Nov 2004 07:37:53 -0500 Subject: Making content readable by httpd In-Reply-To: References: Message-ID: <4194AEA1.2070600@redhat.com> Ian Pilcher wrote: > I am trying to get Netjuke (http://www.netjuke.org/) working on FC3 with > SELinux enabled. Netjuke is a PHP-based "jukebox" application, and I > use it to stream Ogg Vorbis music files around my house. The music > files live on several separate reiserfs filesystems, which have no > security contexts at all. (These filesystems are mounted under /mnt and > symlinked into the /var/www/html tree, if it makes any difference.) > > I've read through the FC3 SELinux FAQ and the man pages for setfiles, > fixfiles, and restorecon, and I've even tried playing with the options > that look nondestructive, but none the tools find anything wrong with > the current setup. What do I need to do to make these files readable > by the httpd server? > > Thanks! > Look for AVC Messages in the /var/log/messages file. You can run audit2allow -l -i /var/log/messages They you can customize policy to allow these. From sds at epoch.ncsc.mil Fri Nov 12 13:29:12 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 12 Nov 2004 08:29:12 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1100266152.4306.51.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-11-12 at 07:19, Stephen Smalley wrote: > You still need to add rules allowing httpd to talk to mysqld. Adding > mysqld.te just created a separate domain for it (not sure about the log > file problem). So you still need to add: > allow httpd_t mysqld_var_run_t:sock_file rw_file_perms; > can_unix_connect(httpd_t, mysqld_t) > can_unix_send(httpd_t, mysqld_t) Hmmm...unless it is actually httpd_php_t that is talking to mysqld, and not the httpd_t process itself. In that case, those permissions are already present in the apache.te file. -- Stephen Smalley National Security Agency From i.pilcher at comcast.net Fri Nov 12 17:32:16 2004 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 12 Nov 2004 11:32:16 -0600 Subject: Making content readable by httpd In-Reply-To: <4194AEA1.2070600@redhat.com> References: <4194AEA1.2070600@redhat.com> Message-ID: Daniel J Walsh wrote: > Look for AVC Messages in the /var/log/messages file. I should have posted those before. Here is an example of what happens when httpd tries to access the reiserfs filesystem: Nov 11 23:33:38 home kernel: audit(1100237618.326:0): avc: denied { search } for pid=9106 exe=/usr/sbin/httpd dev=md5 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=dir Nov 11 23:33:38 home kernel: audit(1100237618.326:0): avc: denied { getattr } for pid=9106 exe=/usr/sbin/httpd path=/mnt/music1 dev=md5 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=dir > You can run audit2allow -l -i /var/log/messages Here's what audit2allow says about it: allow httpd_t bin_t:lnk_file { read }; allow httpd_t nfs_t:dir { getattr search }; allow httpd_t user_home_t:file { getattr read }; > They you can customize policy to allow these. To my *very* inexpert eye, it looks like audit2allow is telling me to loosen the restrictions on httpd. I suppose that this is an option (as turning SELinux off entirely for httpd), but I really want to figure out what contexts I need to add the the music filesystems to make them accessible by httpd under the present policy. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From walters at redhat.com Fri Nov 12 17:41:13 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 12 Nov 2004 12:41:13 -0500 Subject: Making content readable by httpd In-Reply-To: References: <4194AEA1.2070600@redhat.com> Message-ID: <1100281273.28179.27.camel@nexus.verbum.private> On Fri, 2004-11-12 at 11:32 -0600, Ian Pilcher wrote: > Daniel J Walsh wrote: > > Look for AVC Messages in the /var/log/messages file. > > I should have posted those before. Here is an example of what happens > when httpd tries to access the reiserfs filesystem: > > Nov 11 23:33:38 home kernel: audit(1100237618.326:0): avc: denied { > search } for pid=9106 exe=/usr/sbin/httpd dev=md5 ino=2 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t tclass=dir One approach is to mount the filesystem with the httpd_sys_content_t type, like this: mount -o remount,fscontext=system_u:object_r:httpd_sys_content_t /path/to/your/reiserfs Another is to give httpd_t access to nfs_t, like this: r_dir_file(httpd_t, nfs_t) From dwalsh at redhat.com Fri Nov 12 18:07:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 12 Nov 2004 13:07:04 -0500 Subject: Making content readable by httpd In-Reply-To: References: <4194AEA1.2070600@redhat.com> Message-ID: <4194FBC8.3090308@redhat.com> Ian Pilcher wrote: > Daniel J Walsh wrote: > >> Look for AVC Messages in the /var/log/messages file. > > > I should have posted those before. Here is an example of what happens > when httpd tries to access the reiserfs filesystem: > > Nov 11 23:33:38 home kernel: audit(1100237618.326:0): avc: denied { > search } for pid=9106 exe=/usr/sbin/httpd dev=md5 ino=2 > scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t > tclass=dir > > Nov 11 23:33:38 home kernel: audit(1100237618.326:0): avc: denied { > getattr } for pid=9106 exe=/usr/sbin/httpd path=/mnt/music1 dev=md5 > ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:nfs_t > tclass=dir > >> You can run audit2allow -l -i /var/log/messages > > > Here's what audit2allow says about it: > > allow httpd_t bin_t:lnk_file { read }; > allow httpd_t nfs_t:dir { getattr search }; > allow httpd_t user_home_t:file { getattr read }; > >> They you can customize policy to allow these. > > > To my *very* inexpert eye, it looks like audit2allow is telling me to > loosen the restrictions on httpd. I suppose that this is an option (as > turning SELinux off entirely for httpd), but I really want to figure out > what contexts I need to add the the music filesystems to make them > accessible by httpd under the present policy. > > Thanks! > Try the policy on ftp://people.redhat.com/dwalsh/SELinux/ FC3 selinux-policy-targeted-1.17.30-2.23 This is a preview of the one that will be in update 1. It has allow rules for the NFS partition. Dan From i.pilcher at comcast.net Fri Nov 12 18:21:35 2004 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 12 Nov 2004 12:21:35 -0600 Subject: Making content readable by httpd In-Reply-To: <1100281273.28179.27.camel@nexus.verbum.private> References: <4194AEA1.2070600@redhat.com> <1100281273.28179.27.camel@nexus.verbum.private> Message-ID: Colin Walters wrote: > > One approach is to mount the filesystem with the httpd_sys_content_t > type, like this: > > mount -o remount,fscontext=system_u:object_r:httpd_sys_content_t /path/to/your/reiserfs > So much for printing /etc/fstab in portrait mode! Works like a charm. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Fri Nov 12 18:24:58 2004 From: i.pilcher at comcast.net (Ian Pilcher) Date: Fri, 12 Nov 2004 12:24:58 -0600 Subject: Making content readable by httpd In-Reply-To: <4194FBC8.3090308@redhat.com> References: <4194AEA1.2070600@redhat.com> <4194FBC8.3090308@redhat.com> Message-ID: Daniel J Walsh wrote: > Try the policy on ftp://people.redhat.com/dwalsh/SELinux/ FC3 Thanks for your responses. I have modified my /etc/fstab, as suggested by Colin Walters to mount my reiserfs filesystems with the httpd_sys_content_t type. It seems to be working, and I believe that it does what I want to do -- mark these filesystems as data intended to be served by Apache. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From rodrigo.damazio at poli.usp.br Sat Nov 13 03:35:38 2004 From: rodrigo.damazio at poli.usp.br (Rodrigo Damazio) Date: Sat, 13 Nov 2004 01:35:38 -0200 Subject: A few policy changes I had to make Message-ID: <4195810A.1080404@poli.usp.br> Hello. I started playing with SELinux on FC2, and recently moved to FC3, and I must say it's much better now, with the targeted policy. Congrats on this. I still had to change a few things in my policies, though. Following is a collection of the avc errors justifying my changes. I'm not experienced with SElinux yet, so I may be doing something wrong...please let me know if these changes are correct or not. Also, the unlink allow for httpd_t is because, for some reason, when I try to remove a file from within PHP, it uses httpd_t instead of httpd_sys_script_t . I would also like a rule(which I'm not sure how to write) to allow PHP programs to execute external programs, since I have a script which receives an uploaded file, does a lot of processing with it through external programs, and stores it in the database - when I run that, it gives me avc execute errors trying to run bash and the other utilities. Apache: Nov 12 16:50:46 fireball kernel: audit(1100285446.637:0): avc: denied { connectto } for pid=2522 exe=/usr/sbin/httpd path=/tmp/.s.PGSQL.5432 scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:unconfined_t tclass=unix_stream_socket NTPd: Nov 11 19:51:49 fireball kernel: audit(1100209909.743:0): avc: denied { create } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket Nov 11 19:51:49 fireball kernel: audit(1100209909.745:0): avc: denied { bind } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket Nov 11 19:51:49 fireball kernel: audit(1100209909.745:0): avc: denied { getattr } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket Nov 11 19:51:49 fireball kernel: audit(1100209909.747:0): avc: denied { write } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket Nov 11 19:51:49 fireball kernel: audit(1100209909.749:0): avc: denied { net_admin } for pid=2293 exe=/usr/sbin/ntpd capability=12 scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=capability Nov 11 19:51:49 fireball kernel: audit(1100209909.750:0): avc: denied { nlmsg_read } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket Nov 11 19:51:49 fireball kernel: audit(1100209909.752:0): avc: denied { read } for pid=2293 exe=/usr/sbin/ntpd scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t tclass=netlink_route_socket DHCPd: Nov 12 23:37:25 fireball kernel: audit(1100309845.314:0): avc: denied { create } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.317:0): avc: denied { bind } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.320:0): avc: denied { getattr } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.323:0): avc: denied { write } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.325:0): avc: denied { net_admin } for pid=10002 exe=/usr/sbin/dhcpd capability=12 scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=capability Nov 12 23:37:25 fireball kernel: audit(1100309845.326:0): avc: denied { nlmsg_read } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.327:0): avc: denied { read } for pid=10002 exe=/usr/sbin/dhcpd scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t tclass=netlink_route_socket Nov 12 23:37:25 fireball kernel: audit(1100309845.909:0): avc: denied { unlink } for pid=10008 exe=/usr/sbin/dhcpd name=dhcpd.leases~ dev=hda1 ino=425472 scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:file_t tclass=file named: Nov 12 23:41:25 fireball kernel: audit(1100310085.797:0): avc: denied { create } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Nov 12 23:41:25 fireball kernel: audit(1100310085.798:0): avc: denied { bind } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Nov 12 23:41:25 fireball kernel: audit(1100310085.799:0): avc: denied { getattr } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Nov 12 23:41:25 fireball kernel: audit(1100310085.803:0): avc: denied { write } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Nov 12 23:41:25 fireball kernel: audit(1100310085.806:0): avc: denied { nlmsg_read } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Nov 12 23:41:25 fireball kernel: audit(1100310085.809:0): avc: denied { read } for pid=10183 exe=/usr/sbin/named scontext=root:system_r:named_t tcontext=root:system_r:named_t tclass=netlink_route_socket Thanks, Rodrigo -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-targeted-policy-rdamazio.patch Type: text/x-patch Size: 3465 bytes Desc: not available URL: From jmorris at redhat.com Sat Nov 13 02:48:49 2004 From: jmorris at redhat.com (James Morris) Date: Fri, 12 Nov 2004 21:48:49 -0500 (EST) Subject: Linux Journal Article Message-ID: What's New in Fedora Core 3 SE Linux By Faye Coker http://www.linuxjournal.com/node/7887 -- James Morris From dwalsh at redhat.com Sat Nov 13 13:05:51 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 13 Nov 2004 08:05:51 -0500 Subject: A few policy changes I had to make In-Reply-To: <4195810A.1080404@poli.usp.br> References: <4195810A.1080404@poli.usp.br> Message-ID: <419606AF.6010800@redhat.com> Rodrigo Damazio wrote: > Hello. I started playing with SELinux on FC2, and recently moved > to FC3, and I must say it's much better now, with the targeted policy. > Congrats on this. > I still had to change a few things in my policies, though. > Following is a collection of the avc errors justifying my changes. I'm > not experienced with SElinux yet, so I may be doing something > wrong...please let me know if these changes are correct or not. Also, > the unlink allow for httpd_t is because, for some reason, when I try > to remove a file from within PHP, it uses httpd_t instead of > httpd_sys_script_t . I would also like a rule(which I'm not sure how > to write) to allow PHP programs to execute external programs, since I > have a script which receives an uploaded file, does a lot of > processing with it through external programs, and stores it in the > database - when I run that, it gives me avc execute errors trying to > run bash and the other utilities. > > Apache: > Nov 12 16:50:46 fireball kernel: audit(1100285446.637:0): avc: > denied { connectto } for pid=2522 exe=/usr/sbin/httpd > path=/tmp/.s.PGSQL.5432 scontext=user_u:system_r:httpd_t > tcontext=user_u:system_r:unconfined_t tclass=unix_stream_socket > > NTPd: > Nov 11 19:51:49 fireball kernel: audit(1100209909.743:0): avc: > denied { create } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > Nov 11 19:51:49 fireball kernel: audit(1100209909.745:0): avc: > denied { bind } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > Nov 11 19:51:49 fireball kernel: audit(1100209909.745:0): avc: > denied { getattr } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > Nov 11 19:51:49 fireball kernel: audit(1100209909.747:0): avc: > denied { write } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > Nov 11 19:51:49 fireball kernel: audit(1100209909.749:0): avc: > denied { net_admin } for pid=2293 exe=/usr/sbin/ntpd capability=12 > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=capability > Nov 11 19:51:49 fireball kernel: audit(1100209909.750:0): avc: > denied { nlmsg_read } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > Nov 11 19:51:49 fireball kernel: audit(1100209909.752:0): avc: > denied { read } for pid=2293 exe=/usr/sbin/ntpd > scontext=user_u:system_r:ntpd_t tcontext=user_u:system_r:ntpd_t > tclass=netlink_route_socket > > DHCPd: > Nov 12 23:37:25 fireball kernel: audit(1100309845.314:0): avc: > denied { create } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.317:0): avc: > denied { bind } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.320:0): avc: > denied { getattr } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.323:0): avc: > denied { write } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.325:0): avc: > denied { net_admin } for pid=10002 exe=/usr/sbin/dhcpd capability=12 > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=capability > Nov 12 23:37:25 fireball kernel: audit(1100309845.326:0): avc: > denied { nlmsg_read } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.327:0): avc: > denied { read } for pid=10002 exe=/usr/sbin/dhcpd > scontext=root:system_r:dhcpd_t tcontext=root:system_r:dhcpd_t > tclass=netlink_route_socket > Nov 12 23:37:25 fireball kernel: audit(1100309845.909:0): avc: > denied { unlink } for pid=10008 exe=/usr/sbin/dhcpd > name=dhcpd.leases~ dev=hda1 ino=425472 scontext=root:system_r:dhcpd_t > tcontext=system_u:object_r:file_t tclass=file > > named: > Nov 12 23:41:25 fireball kernel: audit(1100310085.797:0): avc: > denied { create } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > Nov 12 23:41:25 fireball kernel: audit(1100310085.798:0): avc: > denied { bind } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > Nov 12 23:41:25 fireball kernel: audit(1100310085.799:0): avc: > denied { getattr } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > Nov 12 23:41:25 fireball kernel: audit(1100310085.803:0): avc: > denied { write } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > Nov 12 23:41:25 fireball kernel: audit(1100310085.806:0): avc: > denied { nlmsg_read } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > Nov 12 23:41:25 fireball kernel: audit(1100310085.809:0): avc: > denied { read } for pid=10183 exe=/usr/sbin/named > scontext=root:system_r:named_t tcontext=root:system_r:named_t > tclass=netlink_route_socket > > Thanks, > Rodrigo > >------------------------------------------------------------------------ > >diff -ru src.orig/policy/domains/program/apache.te src/policy/domains/program/apache.te >--- src.orig/policy/domains/program/apache.te 2004-11-01 19:36:22.000000000 -0200 >+++ src/policy/domains/program/apache.te 2004-11-12 23:54:36.127952796 -0200 >@@ -285,6 +285,8 @@ > # Allow httpd to work with postgresql > # > allow httpd_t tmp_t:sock_file rw_file_perms; >+allow httpd_t tmp_t:unix_stream_socket rw_file_perms; >+allow httpd_t unconfined_t:unix_stream_socket rw_file_perms; > ') dnl targeted policy > > This would allow httpd to talk to any unix_stream_socket (XWindows for example.) I am going to try to add postgresql.te (As we have with mysql.te) to targeted policy to see if it fixes this and does not cause other problems. > > # >diff -ru src.orig/policy/domains/program/dhcpd.te src/policy/domains/program/dhcpd.te >--- src.orig/policy/domains/program/dhcpd.te 2004-11-01 19:36:22.000000000 -0200 >+++ src/policy/domains/program/dhcpd.te 2004-11-12 23:38:18.000000000 -0200 >@@ -33,13 +33,14 @@ > can_ypbind(dhcpd_t) > allow dhcpd_t self:unix_dgram_socket create_socket_perms; > allow dhcpd_t self:unix_stream_socket create_socket_perms; >+allow dhcpd_t self:netlink_route_socket r_netlink_socket_perms; > > > Added, but have never seen this before. > allow dhcpd_t var_lib_t:dir search; > > allow dhcpd_t devtty_t:chr_file { read write }; > > # Use capabilities >-allow dhcpd_t dhcpd_t:capability { net_raw net_bind_service }; >+allow dhcpd_t dhcpd_t:capability { net_raw net_admin net_bind_service }; > > > net_admin is a strong capability Allows you to bring up and down network interfaces, iptable rules. Do you have any idea what it is trying to do that would cause this? Could you try to dontaudit it and see what happens. dontaudit dhcpd_t self:capability net_admin; > # Allow access to the dhcpd file types > type dhcp_state_t, file_type, sysadmfile; >diff -ru src.orig/policy/domains/program/named.te src/policy/domains/program/named.te >--- src.orig/policy/domains/program/named.te 2004-11-01 19:36:22.000000000 -0200 >+++ src/policy/domains/program/named.te 2004-11-12 23:42:38.000000000 -0200 >@@ -60,6 +60,7 @@ > # Bind to the named port. > allow named_t dns_port_t:udp_socket name_bind; > allow named_t { dns_port_t rndc_port_t }:tcp_socket name_bind; >+allow named_t self:netlink_route_socket r_netlink_socket_perms; > > > Added. but again have not seen this. > bool named_write_master_zones false; > >diff -ru src.orig/policy/domains/program/ntpd.te src/policy/domains/program/ntpd.te >--- src.orig/policy/domains/program/ntpd.te 2004-11-01 19:36:22.000000000 -0200 >+++ src/policy/domains/program/ntpd.te 2004-11-12 23:33:18.000000000 -0200 >@@ -22,7 +22,7 @@ > # for SSP > allow ntpd_t urandom_device_t:chr_file read; > >-allow ntpd_t self:capability { setgid setuid sys_time net_bind_service ipc_lock sys_chroot }; >+allow ntpd_t self:capability { setgid setuid sys_time net_bind_service ipc_lock sys_chroot net_admin }; > > This should definitely not be allowed. I can't see why ntpd would want to modify your network environment. > allow ntpd_t self:process { setcap setsched }; > # ntpdate wants sys_nice > dontaudit ntpd_t self:capability { fsetid sys_nice }; >@@ -39,6 +39,7 @@ > allow ntpd_t ntp_port_t:udp_socket name_bind; > allow ntpd_t self:unix_dgram_socket create_socket_perms; > allow ntpd_t self:unix_stream_socket create_socket_perms; >+allow ntpd_t self:netlink_route_socket r_netlink_socket_perms; > > > Same as previous comments about netlink_sockets > # so the start script can change firewall entries > allow initrc_t net_conf_t:file { getattr read ioctl }; >diff -ru src.orig/policy/macros/program/apache_macros.te src/policy/macros/program/apache_macros.te >--- src.orig/policy/macros/program/apache_macros.te 2004-11-01 19:36:22.000000000 -0200 >+++ src/policy/macros/program/apache_macros.te 2004-11-12 23:01:49.000000000 -0200 >@@ -106,6 +106,7 @@ > ############################################################################ > r_dir_file(httpd_$1_script_t, httpd_$1_script_ro_t) > create_dir_file(httpd_$1_script_t, httpd_$1_script_rw_t) >+allow httpd_t { httpd_$1_script_rw_t }:{ file dir lnk_file } { unlink }; > ra_dir_file(httpd_$1_script_t, httpd_$1_script_ra_t) > > if (httpd_enable_cgi) && (httpd_unified) { > > > > The update policy has the following which would cover this case. r_dir_file(httpd_t, httpd_sys_script_ro_t) create_dir_file(httpd_t, httpd_sys_script_rw_t) ra_dir_file(httpd_t, httpd_sys_script_ra_t) >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From troels at arvin.dk Sat Nov 13 22:25:12 2004 From: troels at arvin.dk (Troels Arvin) Date: Sat, 13 Nov 2004 23:25:12 +0100 Subject: Non-root listening at port < 1024 Message-ID: Hello, I'm new to selinux, and I haven't read all documentation yet. Still, can't help asking: Does selinux make it possible to run a non-root program and let that program bind to a port < 1024? (Something which I've long missed in Linux.) -- Greetings from Troels Arvin, Copenhagen, Denmark From jouni.viikari at vip.fi Sun Nov 14 10:06:38 2004 From: jouni.viikari at vip.fi (Jouni Viikari) Date: Sun, 14 Nov 2004 12:06:38 +0200 Subject: Problem upgrading FC2 -> FC3 Message-ID: <1100426798.7648.1.camel@pappa.viikarit.com> Hi, I upgraded my FC2 system (which did not have selinux enabled) to FC3. After the upgrade selinux was not enabled. First I tried to enable it by using system-config-securitylevel. On boot I got plenty of error messages on console (nothing showed up in the system logs). I immediately rebooted again with selinux disadled. Nest I installed selinux-policy-targeted-sources package and did: cd /etc/selinux/targeted/src/policy make make relabel Now when I reboot things looks quite ok except: 1) Contrary to http://fedora.redhat.com/docs/selinux-faq-fc3/ pages: id -Z shows: root:system_r:unconfined_t (not root:sysadm_r:sysadm_t) (After su -) I tried only to remove and reinstall pam package (system-auth was changed but there was no system-auth.rpmnew). This had no influence. 2) ISDN does not start correctly on boot: First problem was that even without selinux the test in isdn rc-script failed on: isdnctrl list all >/dev/null 2>&1 if [ $? = 0 ] ; then (prints Can't open /dev/isdnctrl or /dev/isdn/isdnctrl: No such file or directory) I guess this is udev related problem? However disabling this test it works without selinux. With selinux I get on boot: kernel: audit(1100423485.839:0): avc: denied { create } for pid=2610 exe=/sbin/MAKEDEV name=isdnctrl scontext=user_u:system_r:unconfined_t tcontext=system_u:object_r:tty_device_t tclass=lnk_file 'mgetty ttyI':s do open but do not work. After boot "service isdn start" works even with selinux (I need to make it work in boot) and devices operate properly. 3) Now if I try to start "system-config-securitylevel" *with selinux enabled* I just get: Traceback (most recent call last): File "/usr/share/system-config-securitylevel/system-config- securitylevel.py", line 18, in ? app.stand_alone() File "/usr/share/system-config-securitylevel/securitylevel.py", line 427, in stand_alone self.selinuxPage = selinuxPage.selinuxPage() File "/usr/share/system-config-securitylevel/selinuxPage.py", line 329, in __init__ self.refreshTunables(self.initialtype) File "/usr/share/system-config-securitylevel/selinuxPage.py", line 427, in refreshTunables self.loadBooleans() File "/usr/share/system-config-securitylevel/selinuxPage.py", line 418, in loadBooleans on=rec[3]=="1" IndexError: list index out of range Never have I seen there a way to make httpd work without selinux. When running box with selinux disabled I see only named (rndc option) and get... option on screen). 4) Most of my web pages do not work (most of these are PHP based pages): Nov 14 11:20:53 srv kernel: audit(1100424053.389:0): avc: denied { execute } for pid=4416 exe=/usr/sbin/httpd name=rrdcgi dev=dm-0 ino=3542815 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:usr_t tclass=file Nov 14 11:20:59 srv kernel: audit(1100424059.745:0): avc: denied { getattr } for pid=4415 exe=/usr/sbin/httpd path=/opt/bb/bb1.9e- btf/www/bb.html dev=dm-0 ino=1491992 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file Nov 14 11:20:59 srv kernel: audit(1100424059.745:0): avc: denied { getattr } for pid=4415 exe=/usr/sbin/httpd path=/opt/bb/bb1.9e- btf/www/bb.html dev=dm-0 ino=1491992 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file Nov 14 11:21:50 srv kernel: audit(1100424110.999:0): avc: denied { write } for pid=4415 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=3932284 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Nov 14 11:21:52 srv kernel: audit(1100424112.001:0): avc: denied { write } for pid=4415 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=3932284 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Nov 14 11:21:53 srv kernel: audit(1100424113.003:0): avc: denied { write } for pid=4415 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=3932284 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Nov 14 11:21:54 srv kernel: audit(1100424114.004:0): avc: denied { write } for pid=4415 exe=/usr/sbin/httpd name=mysql.sock dev=dm-0 ino=3932284 scontext=user_u:system_r:httpd_t tcontext=user_u:object_r:var_lib_t tclass=sock_file Nov 14 11:22:09 srv kernel: audit(1100424129.740:0): avc: denied { read } for pid=4421 exe=/usr/sbin/httpd name=sh dev=dm-0 ino=3443116 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:bin_t tclass=lnk_file Nov 14 11:22:09 srv kernel: audit(1100424129.741:0): avc: denied { read } for pid=4422 exe=/usr/sbin/httpd name=sh dev=dm-0 ino=3443116 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:bin_t tclass=lnk_file Nov 14 11:22:13 srv kernel: audit(1100424133.029:0): avc: denied { execute } for pid=4423 exe=/usr/sbin/httpd name=rrdcgi dev=dm-0 ino=3542815 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:usr_t tclass=file I wonder how could I make these work without opening selinux too much? What is the best way to upgrade selinux to same state where it would be after fresh install of FC3 (Reinstalling my server is unfortunately no option)? This would also be good material for the FAQ pages. Tia, Jouni From jouni.viikari at vip.fi Sun Nov 14 14:22:27 2004 From: jouni.viikari at vip.fi (Jouni Viikari) Date: Sun, 14 Nov 2004 16:22:27 +0200 Subject: Problem upgrading FC2 -> FC3 In-Reply-To: <1100426798.7648.1.camel@pappa.viikarit.com> References: <1100426798.7648.1.camel@pappa.viikarit.com> Message-ID: <1100442147.9776.11.camel@pappa.viikarit.com> > 4) Most of my web pages do not work (most of these are PHP based > pages): As a followup to my own post: I was able to get most of my web pages running: I was able to make mysql work with following instructions http://www.redhat.com/archives/fedora-selinux-list/2004- November/msg00022.html and with following changes: (name mysqld.te has to be with lower case letters) rpm -q -l mysql-server | restorecon -R -f - #(note -server above) restorecon -R -v /var/log Also I had to place following to local.te # connect to mysql ifdef(`mysqld.te', ` allow httpd_t mysqld_var_run_t:dir { search }; allow httpd_t mysqld_var_run_t:sock_file { write }; can_unix_connect(httpd_t, mysqld_t) ') since I was not able to run my php pages with httpd_php_t context as specified in current apache.te for mysqld. How should I do this? One problem still remains: I have an php-based photo gallery program which generates a lot of: kernel: audit(1100441228.517:0): avc: denied { search } for pid=2467 exe=/usr/sbin/httpd dev=dm-1 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir I am unable to find what causes these. There exists an symbolic link to my data directories (which is in another disk). Could this cause problems? All my related files are httpd_sys_content_t as far as I can tell. BR, Jouni From dragoran at feuerpokemon.de Mon Nov 15 06:34:08 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 15 Nov 2004 07:34:08 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <1100266152.4306.51.camel@moss-spartans.epoch.ncsc.mil> References: <41923670.7070909@feuerpokemon.de> <41923936.6000307@redhat.com> <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> <1100266152.4306.51.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <41984DE0.9040006@feuerpokemon.de> Stephen Smalley schrieb: >On Fri, 2004-11-12 at 07:19, Stephen Smalley wrote: > > >>You still need to add rules allowing httpd to talk to mysqld. Adding >>mysqld.te just created a separate domain for it (not sure about the log >>file problem). So you still need to add: >> allow httpd_t mysqld_var_run_t:sock_file rw_file_perms; >> can_unix_connect(httpd_t, mysqld_t) >> can_unix_send(httpd_t, mysqld_t) >> >> > >Hmmm...unless it is actually httpd_php_t that is talking to mysqld, and >not the httpd_t process itself. In that case, those permissions are >already present in the apache.te file. > > > I have an other problem with mysql: i got this errormessage when i executed a query: mySQL query error: SELECT p.*,t.title,t.posts,m.avatar_location,m.avatar_size,m.avatar_type FROM ibf_posts p LEFT JOIN ibf_topics t ON p.topic_id=t.tid LEFT JOIN ibf_member_extra m ON m.id=p.author_id where t.forum_id IN (2) AND t.approved=1 group by p.topic_id order by p.post_date DESC LIMIT 0,5 mySQL error: Can't create/write to file '/tmp/#sqla12_e_0.MYI' (Errcode: 13) in dmesg I have this messages: audit(1100500197.839:0): avc: denied { write } for pid=3912 exe=/usr/libexec/mysqld name=tmp dev=hda3 ino=24 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:root_t tclass=dir audit(1100500209.169:0): avc: denied { write } for pid=3913 exe=/usr/libexec/mysqld name=tmp dev=hda3 ino=24 scontext=user_u:system_r:mysqld_t tcontext=root:object_r:root_t tclass=dir From cra at WPI.EDU Mon Nov 15 13:44:07 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 15 Nov 2004 08:44:07 -0500 Subject: PHP cannot connect to mysql server In-Reply-To: <41984DE0.9040006@feuerpokemon.de> References: <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> <1100266152.4306.51.camel@moss-spartans.epoch.ncsc.mil> <41984DE0.9040006@feuerpokemon.de> Message-ID: <20041115134407.GB20837@angus.ind.WPI.EDU> On Mon, Nov 15, 2004 at 07:34:08AM +0100, dragoran wrote: > mySQL error: Can't create/write to file '/tmp/#sqla12_e_0.MYI' (Errcode: 13) I would rather that mySQL wrote to a private directory for this purpose. I don't see why a shared directory like /tmp is needed. From dwalsh at redhat.com Mon Nov 15 15:12:29 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Nov 2004 10:12:29 -0500 Subject: Non-root listening at port < 1024 In-Reply-To: References: Message-ID: <4198C75D.8030302@redhat.com> Troels Arvin wrote: >Hello, > >I'm new to selinux, and I haven't read all documentation yet. > >Still, can't help asking: >Does selinux make it possible to run a non-root program and let that >program bind to a port < 1024? (Something which I've long missed in Linux.) > > > No. SELinux is parallel to normal Linux/Unix protections. So anything that is prevented do to Normal Unix protections will be prevented in an SELinux System. In the future this might change. Dan From linux_4ever at yahoo.com Mon Nov 15 15:16:39 2004 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 15 Nov 2004 07:16:39 -0800 (PST) Subject: Non-root listening at port < 1024 In-Reply-To: Message-ID: <20041115151639.32480.qmail@web50605.mail.yahoo.com> >Does selinux make it possible to run a non-root program and let that >program bind to a port < 1024? (Something which I've long missed in Linux) Not that I know of. SE Linux adds more restriction on top of those already in place by the OS. The OS will not let you bind to a port < 1024. Most applications that need to do this start as root and then change uid after securing privileged resources. You might also look at xinetd as a way to start an application without needing root. (You'll need root to edit xinetd's config and the app will need to be inetd aware.) Hope this helps... -Steve Grubb __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From sds at epoch.ncsc.mil Mon Nov 15 15:14:16 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 15 Nov 2004 10:14:16 -0500 Subject: Non-root listening at port < 1024 In-Reply-To: <4198C75D.8030302@redhat.com> References: <4198C75D.8030302@redhat.com> Message-ID: <1100531656.31773.97.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-11-15 at 10:12, Daniel J Walsh wrote: > No. SELinux is parallel to normal Linux/Unix protections. So anything > that is prevented do > to Normal Unix protections will be prevented in an SELinux System. In > the future this might > change. Note however that you can run a uid 0 process in a particular SELinux security domain and deny it all capabilities except CAP_NET_BIND_SERVICE using the SELinux policy, and further use SELinux policy to limit it to a specific port number or range. -- Stephen Smalley National Security Agency From walters at redhat.com Mon Nov 15 17:22:11 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 15 Nov 2004 12:22:11 -0500 Subject: A few policy changes I had to make In-Reply-To: <419606AF.6010800@redhat.com> References: <4195810A.1080404@poli.usp.br> <419606AF.6010800@redhat.com> Message-ID: <1100539331.30684.5.camel@nexus.verbum.private> On Sat, 2004-11-13 at 08:05 -0500, Daniel J Walsh wrote: > > r_dir_file(httpd_t, httpd_sys_script_ro_t) > create_dir_file(httpd_t, httpd_sys_script_rw_t) > ra_dir_file(httpd_t, httpd_sys_script_ra_t) Hm, this does kind of invalidate the discussion at the end of section 7 in the Apache guide :/ From cra at WPI.EDU Mon Nov 15 17:29:25 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 15 Nov 2004 12:29:25 -0500 Subject: A few policy changes I had to make In-Reply-To: <1100539331.30684.5.camel@nexus.verbum.private> References: <4195810A.1080404@poli.usp.br> <419606AF.6010800@redhat.com> <1100539331.30684.5.camel@nexus.verbum.private> Message-ID: <20041115172925.GF14135@angus.ind.WPI.EDU> On Mon, Nov 15, 2004 at 12:22:11PM -0500, Colin Walters wrote: > On Sat, 2004-11-13 at 08:05 -0500, Daniel J Walsh wrote: > > > > r_dir_file(httpd_t, httpd_sys_script_ro_t) > > create_dir_file(httpd_t, httpd_sys_script_rw_t) > > ra_dir_file(httpd_t, httpd_sys_script_ra_t) > > Hm, this does kind of invalidate the discussion at the end of section 7 > in the Apache guide :/ Do you have a link to "section 7"? From walters at redhat.com Mon Nov 15 17:52:02 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 15 Nov 2004 12:52:02 -0500 Subject: A few policy changes I had to make In-Reply-To: <20041115172925.GF14135@angus.ind.WPI.EDU> References: <4195810A.1080404@poli.usp.br> <419606AF.6010800@redhat.com> <1100539331.30684.5.camel@nexus.verbum.private> <20041115172925.GF14135@angus.ind.WPI.EDU> Message-ID: <1100541122.30684.11.camel@nexus.verbum.private> On Mon, 2004-11-15 at 12:29 -0500, Charles R. Anderson wrote: > On Mon, Nov 15, 2004 at 12:22:11PM -0500, Colin Walters wrote: > > On Sat, 2004-11-13 at 08:05 -0500, Daniel J Walsh wrote: > > > > > > r_dir_file(httpd_t, httpd_sys_script_ro_t) > > > create_dir_file(httpd_t, httpd_sys_script_rw_t) > > > ra_dir_file(httpd_t, httpd_sys_script_ra_t) > > > > Hm, this does kind of invalidate the discussion at the end of section 7 > > in the Apache guide :/ > > Do you have a link to "section 7"? Sorry for the oblique reference. The document's still being reviewed for posting; it's not secret or anything (certainly you can find it if you search bugzilla or whatever), but I'd prefer people to see it *after* the docs team has fixed my embarrassing grammar :) From himainu-ynakam at miomio.jp Tue Nov 16 05:14:03 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Tue, 16 Nov 2004 00:14:03 -0500 Subject: Where is fixfiles.cron? Message-ID: <200411160514.iAG5EcgB024267@mms-r01.iijmio.jp> We found that in FedoraCore3 fixfiles.cron is removed after yum update. It seems that there is no fixfiles.cron in the latest policycoreutils. Why is it removed? I think fixfiles.cron is necessary to maintain security. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) ??http://www.selinux.gr.jp/ From jorton at redhat.com Tue Nov 16 13:21:10 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 16 Nov 2004 13:21:10 +0000 Subject: SELinux/httpd integration Message-ID: <20041116132110.GA32134@redhat.com> I think one thing that would help would be making the sets of example httpd module configurations self-documentating w.r.t. SELinux for some of the modules. So for instance, how do I get Subversion/mod_dav_svn working with an SELinux-enabled httpd? Can we make it such that an SVN repos is as easy to set up as: # cd /src/svn # svnadmin create mystuff # vi /etc/httpd/conf.d/subversion.conf - uncomment the defaults? even with SELinux enabled? The commented default in subversion.conf here could be: DAV svn SVNParentPath /srv/svn A more generic example would be if we provide a /srv/www directory or something to which the httpd domain is allowed read+write access by default; somewhere to put the PHP webapps. Does this make sense? joe From dwalsh at redhat.com Tue Nov 16 13:41:02 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 16 Nov 2004 08:41:02 -0500 Subject: Where is fixfiles.cron? In-Reply-To: <200411160514.iAG5EcgB024267@mms-r01.iijmio.jp> References: <200411160514.iAG5EcgB024267@mms-r01.iijmio.jp> Message-ID: <419A036E.7000203@redhat.com> Yuichi Nakamura wrote: >We found that in FedoraCore3 fixfiles.cron is removed after yum update. >It seems that there is no fixfiles.cron in the latest policycoreutils. >Why is it removed? > >I think fixfiles.cron is necessary to maintain security. > >--- >Yuichi Nakamura >Japan SELinux Users Group(JSELUG) >??http://www.selinux.gr.jp/ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > fixfiles.cron causes more problems than it solves. It made little sense in targeted policy. It also informed users of problems when there were none and it some cases would open up security holes. Consider if a user wants to make a copy of his gpg keys, he makes a copy maintaining the security context, next time fixfiles.cron runs it will tell the administrator that he has mislabeled files and he might blindly relabel them, removing the save security context. The other example was if users are labeling directories to be run by apache using the full power of httpd_TYPE_script_rw_t and others, the fixfiles will report these as errors. So until someone comes up with a better way to handle these situations I thought it better to not install it any longer. Dan From dragoran at feuerpokemon.de Tue Nov 16 17:07:36 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 16 Nov 2004 18:07:36 +0100 Subject: PHP cannot connect to mysql server In-Reply-To: <20041115134407.GB20837@angus.ind.WPI.EDU> References: <41923C2E.4070507@feuerpokemon.de> <1100103543.1972.219.camel@moss-spartans.epoch.ncsc.mil> <41924115.9050305@feuerpokemon.de> <41924239.1070100@redhat.com> <419243D3.90907@feuerpokemon.de> <41930258.9080408@feuerpokemon.de> <41934829.5090408@redhat.com> <1100261959.4306.1.camel@moss-spartans.epoch.ncsc.mil> <1100266152.4306.51.camel@moss-spartans.epoch.ncsc.mil> <41984DE0.9040006@feuerpokemon.de> <20041115134407.GB20837@angus.ind.WPI.EDU> Message-ID: <419A33D8.8040907@feuerpokemon.de> Charles R. Anderson schrieb: >On Mon, Nov 15, 2004 at 07:34:08AM +0100, dragoran wrote: > > >>mySQL error: Can't create/write to file '/tmp/#sqla12_e_0.MYI' (Errcode: 13) >> >> > >I would rather that mySQL wrote to a private directory for this >purpose. I don't see why a shared directory like /tmp is needed. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > thx I fixed it by using /var/lib/mysql/tmp as tmpdir From walters at redhat.com Tue Nov 16 18:56:56 2004 From: walters at redhat.com (Colin Walters) Date: Tue, 16 Nov 2004 13:56:56 -0500 Subject: SELinux/httpd integration In-Reply-To: <20041116132110.GA32134@redhat.com> References: <20041116132110.GA32134@redhat.com> Message-ID: <1100631416.26494.27.camel@nexus.verbum.private> On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote: > I think one thing that would help would be making the sets of example > httpd module configurations self-documentating w.r.t. SELinux for some > of the modules. It would be nice to go through more possible configurations and try them; so far we've only done a few. > So for instance, how do I get Subversion/mod_dav_svn working with an > SELinux-enabled httpd? Can we make it such that an SVN repos is as easy > to set up as: > > # cd /src/svn > # svnadmin create mystuff > # vi /etc/httpd/conf.d/subversion.conf > - uncomment the defaults? Well, given that the path /src/ doesn't exist by default right now, we can't ensure it's labeled correctly out of the box. Maybe we could have default configuration use /var/www/. > A more generic example would be if we provide a /srv/www directory or > something to which the httpd domain is allowed read+write access by > default; somewhere to put the PHP webapps. /srv/www should probably be just be labeled the same as /var/www by default. Since the default label is httpd_sys_content_t, which in the default boolean set httpd_t is allowed to write to, PHP apps storing e.g. a SQLite database there should work. From himainu-ynakam at miomio.jp Tue Nov 16 19:43:32 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Tue, 16 Nov 2004 14:43:32 -0500 Subject: Where is fixfiles.cron? In-Reply-To: <419A036E.7000203@redhat.com> References: <419A036E.7000203@redhat.com> Message-ID: <200411161944.iAGJi7Ru024817@mms-r01.iijmio.jp> Daniel J Walsh wrote: > fixfiles.cron causes more problems than it solves. It made little sense > in targeted policy. I understand. But fixfiles.cron will be useful for users who understands SELinux well. I hope the script is included in somewhere. > fixfiles will report these as errors. So until someone comes up > with a better way to handle these situations I thought it better to not > install it any longer. Integrity of labeling is critical for SELinux, it should be solved. I think there are two choice, one is to modify policy and the other is to modify fixfiles. - Changing policy: For example, if we do not want label of key file to be never changed by setfiles, declare type "key_t" with attribute, like type key_t, dontchange; And make setfiles(or fixfiles) run as setfiles_t. setfiles_t are configured to be unable to modify label for neverchange attribute. - Changing fixfiles: There is exclude list in fixfiles.cron. For example the content of the list is "httpd_user_script_rw_t" and "gpgkey_t". fixfiles skips files that have label in exclude list. Changing policy is more "MAC" but will take more time to modify and side effect will be bigger. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) ??http://www.selinux.gr.jp/ From jorton at redhat.com Tue Nov 16 20:33:17 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 16 Nov 2004 20:33:17 +0000 Subject: SELinux/httpd integration In-Reply-To: <1100631416.26494.27.camel@nexus.verbum.private> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> Message-ID: <20041116203317.GB4356@redhat.com> On Tue, Nov 16, 2004 at 01:56:56PM -0500, Colin Walters wrote: > On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote: > > I think one thing that would help would be making the sets of example > > httpd module configurations self-documentating w.r.t. SELinux for some > > of the modules. > > It would be nice to go through more possible configurations and try > them; so far we've only done a few. I'll try to go through more of the modules in /etc/httpd/conf.d/*.conf. > > So for instance, how do I get Subversion/mod_dav_svn working with an > > SELinux-enabled httpd? Can we make it such that an SVN repos is as easy > > to set up as: > > > > # cd /src/svn > > # svnadmin create mystuff > > # vi /etc/httpd/conf.d/subversion.conf > > - uncomment the defaults? > > Well, given that the path /src/ doesn't exist by default right now, we > can't ensure it's labeled correctly out of the box. Maybe we could have > default configuration use /var/www/. That would work too. > > A more generic example would be if we provide a /srv/www directory or > > something to which the httpd domain is allowed read+write access by > > default; somewhere to put the PHP webapps. > > /srv/www should probably be just be labeled the same as /var/www by > default. Since the default label is httpd_sys_content_t, which in the > default boolean set httpd_t is allowed to write to, PHP apps storing > e.g. a SQLite database there should work. httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem? When I set up /var/www/svn as above, I get AVC messages like: audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file joe From dwalsh at redhat.com Tue Nov 16 20:35:49 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 16 Nov 2004 15:35:49 -0500 Subject: SELinux/httpd integration In-Reply-To: <20041116203317.GB4356@redhat.com> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> <20041116203317.GB4356@redhat.com> Message-ID: <419A64A5.9010302@redhat.com> Joe Orton wrote: >On Tue, Nov 16, 2004 at 01:56:56PM -0500, Colin Walters wrote: > > >>On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote: >> >> >>>I think one thing that would help would be making the sets of example >>>httpd module configurations self-documentating w.r.t. SELinux for some >>>of the modules. >>> >>> >>It would be nice to go through more possible configurations and try >>them; so far we've only done a few. >> >> > >I'll try to go through more of the modules in /etc/httpd/conf.d/*.conf. > > > >>>So for instance, how do I get Subversion/mod_dav_svn working with an >>>SELinux-enabled httpd? Can we make it such that an SVN repos is as easy >>>to set up as: >>> >>># cd /src/svn >>># svnadmin create mystuff >>># vi /etc/httpd/conf.d/subversion.conf >>> - uncomment the defaults? >>> >>> >>Well, given that the path /src/ doesn't exist by default right now, we >>can't ensure it's labeled correctly out of the box. Maybe we could have >>default configuration use /var/www/. >> >> > >That would work too. > > > >>>A more generic example would be if we provide a /srv/www directory or >>>something to which the httpd domain is allowed read+write access by >>>default; somewhere to put the PHP webapps. >>> >>> >>/srv/www should probably be just be labeled the same as /var/www by >>default. Since the default label is httpd_sys_content_t, which in the >>default boolean set httpd_t is allowed to write to, PHP apps storing >>e.g. a SQLite database there should work. >> >> > >httpd_t *cannot* write to anything labelled with httpd_sys_content_t by >default, surely - that's the whole problem? > >When I set up /var/www/svn as above, I get AVC messages like: > >audit(1100636258.341:0): avc: denied { write } for pid=21318 >exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 >scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater. From rgorosito at afip.gov.ar Tue Nov 16 21:00:14 2004 From: rgorosito at afip.gov.ar (Gorosito Ricardo) Date: Tue, 16 Nov 2004 18:00:14 -0300 Subject: HTTP (php) can't connect to local postgresql Message-ID: <419A6A5E.4050805@afip.gov.ar> First at all: I'm using targeted policy and When my web application (using php) try to connect to postgresql database I get: *Warning*: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: 8???| Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? in */var/www/html/encuesta/index.php* on line *7 *In dmesg I see: audit(1100638278.903:0): avc: denied { connectto } for pid=2481 exe=/usr/sbin/httpd path=/tmp/.s.PGSQL.5432 scontext=user_u:system_r:httpd_t tcontext=user_u:system_r:unconfined_t tclass=unix_stream_socke and ls -laZ /tmp/s.PGSQL.5432 show: srwxrwxrwx postgres postgres user_u:object_r:tmp_t /tmp/.s.PGSQL.5432 What can I do? What if I append line "can_unix_connect(httpd_php_t, unconfined_t)" in /etc/selinux/targeted/src/policy/domains/program/apache.te ? (What if I don't want that 'httpd' can connect to other socks?). Thanks in advance and excuse my english. Ricardo.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorton at redhat.com Wed Nov 17 11:29:19 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 17 Nov 2004 11:29:19 +0000 Subject: SELinux/httpd integration In-Reply-To: <419A64A5.9010302@redhat.com> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> <20041116203317.GB4356@redhat.com> <419A64A5.9010302@redhat.com> Message-ID: <20041117112919.GB20888@redhat.com> On Tue, Nov 16, 2004 at 03:35:49PM -0500, Daniel J Walsh wrote: > Joe Orton wrote: > >httpd_t *cannot* write to anything labelled with httpd_sys_content_t by > >default, surely - that's the whole problem? > > > >When I set up /var/www/svn as above, I get AVC messages like: > > > >audit(1100636258.341:0): avc: denied { write } for pid=21318 > >exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 > >scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t > >tclass=file > > Policy has been updated to allow this. Please update to > selinux-policy-targeted-1.17.30-2.26 or greater. The same using a fresh Raw Hide install from yesterday, selinux-policy-targeted-1.19.1-9: audit(1100690797.204:0): avc: denied { write } for pid=2388 exe=/usr/sbin/httpd name=__db.001 dev=md0 ino=1194146 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file joe From dwalsh at redhat.com Wed Nov 17 15:15:15 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 17 Nov 2004 10:15:15 -0500 Subject: SELinux/httpd integration In-Reply-To: <20041117112919.GB20888@redhat.com> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> <20041116203317.GB4356@redhat.com> <419A64A5.9010302@redhat.com> <20041117112919.GB20888@redhat.com> Message-ID: <419B6B03.3020102@redhat.com> Joe Orton wrote: >On Tue, Nov 16, 2004 at 03:35:49PM -0500, Daniel J Walsh wrote: > > >>Joe Orton wrote: >> >> >>>httpd_t *cannot* write to anything labelled with httpd_sys_content_t by >>>default, surely - that's the whole problem? >>> >>>When I set up /var/www/svn as above, I get AVC messages like: >>> >>>audit(1100636258.341:0): avc: denied { write } for pid=21318 >>>exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 >>>scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t >>>tclass=file >>> >>> >>Policy has been updated to allow this. Please update to >>selinux-policy-targeted-1.17.30-2.26 or greater. >> >> > >The same using a fresh Raw Hide install from yesterday, >selinux-policy-targeted-1.19.1-9: > >audit(1100690797.204:0): avc: denied { write } for pid=2388 >exe=/usr/sbin/httpd name=__db.001 dev=md0 ino=1194146 >scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file > > > If you label svn file httpd_sys_script_rw_t it should work, but this does expose a bug in httpd_unified boolean, that I fixed in selinux-policy-targeted-1.19.1-12 and selinux-policy-targeted-1.17.30-2.31 >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From walters at redhat.com Wed Nov 17 19:54:12 2004 From: walters at redhat.com (Colin Walters) Date: Wed, 17 Nov 2004 14:54:12 -0500 Subject: beta guide for using Apache and SELinux on Fedora Core 3 Message-ID: <1100721252.12098.35.camel@nexus.verbum.private> Hi, A beta version of a guide for using Apache and SELinux together on Fedora Core 3 is available here: http://fedora.redhat.com/docs/selinux-apache-fc3/ Feedback is appreciated; please send mail to fedora-selinux-list. I'd particularly like to get more canned solutions, such as running Squirrelmail, doing Subversion via mod_dav_svn, etc. Please report bugs here: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core&component=fedora-docs And make the bug block 136427. Thanks! From mayerf at tresys.com Thu Nov 18 16:45:27 2004 From: mayerf at tresys.com (Frank Mayer) Date: Thu, 18 Nov 2004 11:45:27 -0500 Subject: Agenda announced for Inaugural SELinux Symposium Message-ID: <018b01c4cd8e$02b03910$6701a8c0@columbia.tresys.com> The speakers and agenda for the inaugural SELinux Symposium have been announced, and early registration is now open. See www.selinux-symposium.org. We received a lot of good proposals on a variety of related topics. It looks good. Thanks to all the reviewers for your help in vetting the agenda. Frank From jorton at redhat.com Fri Nov 19 12:54:43 2004 From: jorton at redhat.com (Joe Orton) Date: Fri, 19 Nov 2004 12:54:43 +0000 Subject: libselinux tools location Message-ID: <20041119125443.GA22119@redhat.com> I noticed the tools moved from /usr/bin to /usr/sbin which broke the changes I'd made to apachectl to use /usr/bin/selinuxenabled. Are these going to stay in /usr/sbin now, and this location change will be in RHEL4 as well as FC4? Regards, joe From sds at epoch.ncsc.mil Fri Nov 19 13:37:06 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 19 Nov 2004 08:37:06 -0500 Subject: libselinux tools location In-Reply-To: <20041119125443.GA22119@redhat.com> References: <20041119125443.GA22119@redhat.com> Message-ID: <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-11-19 at 07:54, Joe Orton wrote: > I noticed the tools moved from /usr/bin to /usr/sbin which broke the > changes I'd made to apachectl to use /usr/bin/selinuxenabled. Are these > going to stay in /usr/sbin now, and this location change will be in > RHEL4 as well as FC4? Sorry, who changed this? Upstream libselinux still installs the utilities to /usr/bin (by default, unless you override the BINDIR definition). -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Nov 19 14:31:07 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 19 Nov 2004 09:31:07 -0500 Subject: libselinux tools location In-Reply-To: <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> References: <20041119125443.GA22119@redhat.com> <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <419E03AB.4090807@redhat.com> Stephen Smalley wrote: >On Fri, 2004-11-19 at 07:54, Joe Orton wrote: > > >>I noticed the tools moved from /usr/bin to /usr/sbin which broke the >>changes I'd made to apachectl to use /usr/bin/selinuxenabled. Are these >>going to stay in /usr/sbin now, and this location change will be in >>RHEL4 as well as FC4? >> >> > >Sorry, who changed this? Upstream libselinux still installs the >utilities to /usr/bin (by default, unless you override the BINDIR >definition). > > > Yes they will stay in /usr/sbin. We changed the location, as I felt these tools were not to be used by non admins. They will be there in all future versions of RHEL and FC. From tdiehl at rogueind.com Fri Nov 19 20:36:50 2004 From: tdiehl at rogueind.com (Tom Diehl) Date: Fri, 19 Nov 2004 15:36:50 -0500 (EST) Subject: libselinux tools location In-Reply-To: <419E03AB.4090807@redhat.com> References: <20041119125443.GA22119@redhat.com> <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> <419E03AB.4090807@redhat.com> Message-ID: On Fri, 19 Nov 2004, Daniel J Walsh wrote: > Stephen Smalley wrote: > > >On Fri, 2004-11-19 at 07:54, Joe Orton wrote: > > > > > >>I noticed the tools moved from /usr/bin to /usr/sbin which broke the > >>changes I'd made to apachectl to use /usr/bin/selinuxenabled. Are these > >>going to stay in /usr/sbin now, and this location change will be in > >>RHEL4 as well as FC4? > >> > >> > > > >Sorry, who changed this? Upstream libselinux still installs the > >utilities to /usr/bin (by default, unless you override the BINDIR > >definition). > > > > > > > Yes they will stay in /usr/sbin. We changed the location, as I felt > these tools were not to be used by non admins. > They will be there in all future versions of RHEL and FC. So much for the stated policy of following upstream as much as possible. If it is an important change why not get upstream to change it? It appears that every time someone outside of Red Hat wants a change the standard answer is to get it changed upstream. Why is this different? It is not like Fedora will stop working without it. :-) I actually agree with the change, but I am just trying to understand what the policy really is? Regards, Tom From mattdm at mattdm.org Fri Nov 19 20:42:25 2004 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 19 Nov 2004 15:42:25 -0500 Subject: libselinux tools location In-Reply-To: References: <20041119125443.GA22119@redhat.com> <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> <419E03AB.4090807@redhat.com> Message-ID: <20041119204225.GA18225@jadzia.bu.edu> On Fri, Nov 19, 2004 at 03:36:50PM -0500, Tom Diehl wrote: > So much for the stated policy of following upstream as much as possible. > If it is an important change why not get upstream to change it? > It appears that every time someone outside of Red Hat wants a change the > standard answer is to get it changed upstream. Why is this different? > It is not like Fedora will stop working without it. :-) > I actually agree with the change, but I am just trying to understand > what the policy really is? File location isn't really an upstream issue -- it's an installation issue and therefore a packaging one. Obviously SE Linux is rather Linux-focused, but in general, many programs packaged for Fedora are designed to be cross-platform, and other platforms may have other expectations about where files belong. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dragoran at feuerpokemon.de Sat Nov 20 08:51:22 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 20 Nov 2004 09:51:22 +0100 Subject: PHP cannot upload files Message-ID: <419F058A.8030106@feuerpokemon.de> I cannot upload files via php (selinux=enabled;policy=targeted). php shows this error: *Warning*: File upload error - unable to create a temporary file in *Unknown* on line *0 *And in dmesg I found this error: audit(1100940427.918:0): avc: denied { write } for pid=9202 exe=/usr/sbin/httpd name=tmp dev=hda3 ino=24 scontext=root:system_r:httpd_t tcontext=root:object_r:root_t tclass=dir From walters at redhat.com Sat Nov 20 17:34:46 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 20 Nov 2004 12:34:46 -0500 Subject: PHP cannot upload files In-Reply-To: <419F058A.8030106@feuerpokemon.de> References: <419F058A.8030106@feuerpokemon.de> Message-ID: <1100972086.3987.5.camel@nexus.verbum.private> On Sat, 2004-11-20 at 09:51 +0100, dragoran wrote: > I cannot upload files via php (selinux=enabled;policy=targeted). > php shows this error: > *Warning*: File upload error - unable to create a temporary file in > *Unknown* on line *0 > *And in dmesg I found this error: > audit(1100940427.918:0): avc: denied { write } for pid=9202 > exe=/usr/sbin/httpd name=tmp dev=hda3 ino=24 > scontext=root:system_r:httpd_t tcontext=root:object_r:root_t tclass=dir Do you have /tmp on a separate filesystem? What does: ls -Z /tmp show? From jim-cornette at insight.rr.com Sun Nov 21 01:54:13 2004 From: jim-cornette at insight.rr.com (Jim Cornette) Date: Sat, 20 Nov 2004 20:54:13 -0500 Subject: installation of selinux on non-selinux system Message-ID: <419FF545.3080904@insight.rr.com> After upgrading a computer from FC2 to FC3, I decided to give SELinux a shot and used up2date to retrieve the rpm for selinux-policy-targeted and expected for all needed deps to be pulled in. The other dependent ackages did not get pulled in with this selection. I ended up having system messages not being accessable and also httpd being damened with errors. I supposed that there was an abnormality on my particular system. Within recent days, I have noted others experiencing similar failures on the fedora-list. I then decided that this might e a more common prblem than first expected. Another Fedora user was asking questions regarding running fixfiles relabel. I noticed that I also did not have fixfiles installed. After several failures trying to install selinux-policy-targeted-sources using up2date, I tried using yum and was able to get the needed dependent programs that contained fixfiles. After relabeling the system for targeted using fixfiles relabel at a command prompt, I decided to go one step further and fixfiles relabel with selinux-policy-strict-1.17.30-2 installed, which did not pull in fixfiles either when using up2date. Attached is the AVC messages containing 11/19/04 when I ended up changing targeted / enforcing jn order to get system logs to diagnose another problem and finding out that there were no logs from 10/4 until 11/19. Messages after 8:00 PM are avc errors after relabeling the filesystem and rebooting. After trying to start X in runlevel 3 using startx and experiencing a failure, I ran setenforce 0 and decided to at least attempt to convey useful information to help improve SELinux installations for systems that are upgraded from non-selinux to selinux complient systems. Thanks, Jim Cornette -- You will give someone a piece of your mind, which you can ill afford. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: blocks-messages-no-fixfiles-then-relabel-enabled-strict URL: From dwalsh at redhat.com Sun Nov 21 04:24:12 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 20 Nov 2004 23:24:12 -0500 Subject: libselinux tools location In-Reply-To: References: <20041119125443.GA22119@redhat.com> <1100871425.15944.9.camel@moss-spartans.epoch.ncsc.mil> <419E03AB.4090807@redhat.com> Message-ID: <41A0186C.40008@redhat.com> Tom Diehl wrote: >On Fri, 19 Nov 2004, Daniel J Walsh wrote: > > > >>Stephen Smalley wrote: >> >> >> >>>On Fri, 2004-11-19 at 07:54, Joe Orton wrote: >>> >>> >>> >>> >>>>I noticed the tools moved from /usr/bin to /usr/sbin which broke the >>>>changes I'd made to apachectl to use /usr/bin/selinuxenabled. Are these >>>>going to stay in /usr/sbin now, and this location change will be in >>>>RHEL4 as well as FC4? >>>> >>>> >>>> >>>> >>>Sorry, who changed this? Upstream libselinux still installs the >>>utilities to /usr/bin (by default, unless you override the BINDIR >>>definition). >>> >>> >>> >>> >>> >>Yes they will stay in /usr/sbin. We changed the location, as I felt >>these tools were not to be used by non admins. >>They will be there in all future versions of RHEL and FC. >> >> > >So much for the stated policy of following upstream as much as possible. > >If it is an important change why not get upstream to change it? >It appears that every time someone outside of Red Hat wants a change the >standard answer is to get it changed upstream. Why is this different? >It is not like Fedora will stop working without it. :-) > >I actually agree with the change, but I am just trying to understand >what the policy really is? > > We screwed up, we should have sent the patch to upstream, but were rushing to get things cleaned up and done before a RHEL 4 Freeze. >Regards, > >Tom > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dwalsh at redhat.com Sun Nov 21 05:05:07 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 21 Nov 2004 00:05:07 -0500 Subject: installation of selinux on non-selinux system In-Reply-To: <419FF545.3080904@insight.rr.com> References: <419FF545.3080904@insight.rr.com> Message-ID: <41A02203.2040503@redhat.com> Jim Cornette wrote: > After upgrading a computer from FC2 to FC3, I decided to give SELinux > a shot and used up2date to retrieve the rpm for > selinux-policy-targeted and expected for all needed deps to be pulled > in. The other dependent ackages did not get pulled in with this > selection. I ended up having system messages not being accessable and > also httpd being damened with errors. I supposed that there was an > abnormality on my particular system. Within recent days, I have noted > others experiencing similar failures on the fedora-list. I then > decided that this might e a more common prblem than first expected. > > Another Fedora user was asking questions regarding running fixfiles > relabel. I noticed that I also did not have fixfiles installed. > > After several failures trying to install > selinux-policy-targeted-sources using up2date, I tried using yum and > was able to get the needed dependent programs that contained fixfiles. > After relabeling the system for targeted using fixfiles relabel at a > command prompt, I decided to go one step further and fixfiles relabel > with selinux-policy-strict-1.17.30-2 installed, which did not pull in > fixfiles either when using up2date. > Attached is the AVC messages containing 11/19/04 when I ended up > changing targeted / enforcing jn order to get system logs to diagnose > another problem and finding out that there were no logs from 10/4 > until 11/19. Messages after 8:00 PM are avc errors after relabeling > the filesystem and rebooting. > After trying to start X in runlevel 3 using startx and experiencing a > failure, I ran setenforce 0 and decided to at least attempt to convey > useful information to help improve SELinux installations for systems > that are upgraded from non-selinux to selinux complient systems. > > Thanks, > > Jim Cornette > >------------------------------------------------------------------------ > >Oct 4 23:50:13 localhost kernel: audit(1096948213.231:0): avc: denied { append } for pid=2632 exe=/usr/sbin/httpd path=/var/log/httpd/error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100907093.310:0): avc: denied { read write } for pid=606 exe=/sbin/minilogd name=console dev=tmpfs ino=930 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file >Nov 19 23:32:18 localhost kernel: audit(1100907093.311:0): avc: denied { write } for pid=606 exe=/sbin/minilogd name=/ dev=tmpfs ino=929 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:32:18 localhost kernel: audit(1100907093.311:0): avc: denied { add_name } for pid=606 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:32:18 localhost kernel: audit(1100907093.311:0): avc: denied { create } for pid=606 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:32:18 localhost kernel: audit(1100907093.312:0): avc: denied { getattr } for pid=612 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=1789 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:32:18 localhost kernel: audit(1100907098.255:0): avc: denied { write } for pid=612 exe=/sbin/minilogd name=log dev=tmpfs ino=1789 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:32:18 localhost kernel: audit(1100907102.090:0): avc: denied { remove_name } for pid=1182 exe=/sbin/minilogd name=log dev=tmpfs ino=1789 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:32:18 localhost kernel: audit(1100907102.090:0): avc: denied { unlink } for pid=1182 exe=/sbin/minilogd name=log dev=tmpfs ino=1789 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:32:18 localhost kernel: audit(1100925136.741:0): avc: denied { read } for pid=2086 exe=/sbin/syslogd name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100925136.741:0): avc: denied { getattr } for pid=2086 exe=/sbin/syslogd path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100925136.756:0): avc: denied { append } for pid=2086 exe=/sbin/syslogd name=messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100925136.756:0): avc: denied { ioctl } for pid=2086 exe=/sbin/syslogd path=/var/log/messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100925136.763:0): avc: denied { setattr } for pid=2086 exe=/sbin/syslogd name=log dev=tmpfs ino=4973 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:32:18 localhost kernel: audit(1100925137.499:0): avc: denied { search } for pid=2117 exe=/sbin/portmap name=/ dev=hda3 ino=2 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=dir >Nov 19 23:32:18 localhost kernel: audit(1100925137.531:0): avc: denied { search } for pid=2118 exe=/sbin/portmap name=/ dev=tmpfs ino=929 scontext=user_u:system_r:portmap_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:32:18 localhost kernel: audit(1100925137.566:0): avc: denied { read } for pid=2118 exe=/sbin/portmap name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:18 localhost kernel: audit(1100925137.566:0): avc: denied { getattr } for pid=2118 exe=/sbin/portmap path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:28 localhost kernel: audit(1100925148.288:0): avc: denied { search } for pid=2450 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 19 23:32:28 localhost kernel: audit(1100925148.288:0): avc: denied { read } for pid=2450 exe=/usr/sbin/httpd name=libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:28 localhost kernel: audit(1100925148.289:0): avc: denied { getattr } for pid=2450 exe=/usr/sbin/httpd path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:28 localhost kernel: audit(1100925148.289:0): avc: denied { execute } for pid=2450 path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:32:28 localhost kernel: audit(1100925148.331:0): avc: denied { read } for pid=2450 exe=/usr/sbin/httpd name=libaprutil-0.so.0 dev=hda3 ino=103404 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=lnk_file >Nov 19 23:32:29 localhost kernel: audit(1100925149.369:0): avc: denied { append } for pid=2450 exe=/usr/sbin/httpd name=error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:33:32 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 19 23:35:46 localhost kernel: audit(1100907302.257:0): avc: denied { read write } for pid=604 exe=/sbin/minilogd name=console dev=tmpfs ino=930 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file >Nov 19 23:35:46 localhost kernel: audit(1100907302.258:0): avc: denied { write } for pid=604 exe=/sbin/minilogd name=/ dev=tmpfs ino=929 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:35:46 localhost kernel: audit(1100907302.258:0): avc: denied { add_name } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:35:46 localhost kernel: audit(1100907302.258:0): avc: denied { create } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:35:46 localhost kernel: audit(1100907302.259:0): avc: denied { getattr } for pid=607 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:35:46 localhost kernel: audit(1100907307.244:0): avc: denied { write } for pid=607 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:35:46 localhost kernel: audit(1100907311.038:0): avc: denied { remove_name } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:35:46 localhost kernel: audit(1100907311.039:0): avc: denied { unlink } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:35:46 localhost kernel: audit(1100925344.632:0): avc: denied { read } for pid=2084 exe=/sbin/syslogd name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:46 localhost kernel: audit(1100925344.632:0): avc: denied { getattr } for pid=2084 exe=/sbin/syslogd path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:46 localhost kernel: audit(1100925344.648:0): avc: denied { append } for pid=2084 exe=/sbin/syslogd name=messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:46 localhost kernel: audit(1100925344.648:0): avc: denied { ioctl } for pid=2084 exe=/sbin/syslogd path=/var/log/messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:46 localhost kernel: audit(1100925344.655:0): avc: denied { setattr } for pid=2084 exe=/sbin/syslogd name=log dev=tmpfs ino=4970 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 19 23:35:46 localhost kernel: audit(1100925345.248:0): avc: denied { search } for pid=2115 exe=/sbin/portmap name=/ dev=hda3 ino=2 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=dir >Nov 19 23:35:46 localhost kernel: audit(1100925345.280:0): avc: denied { search } for pid=2116 exe=/sbin/portmap name=/ dev=tmpfs ino=929 scontext=user_u:system_r:portmap_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 19 23:35:46 localhost kernel: audit(1100925345.291:0): avc: denied { read } for pid=2116 exe=/sbin/portmap name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:46 localhost kernel: audit(1100925345.291:0): avc: denied { getattr } for pid=2116 exe=/sbin/portmap path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:56 localhost kernel: audit(1100925356.180:0): avc: denied { search } for pid=2448 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 19 23:35:56 localhost kernel: audit(1100925356.180:0): avc: denied { read } for pid=2448 exe=/usr/sbin/httpd name=libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:56 localhost kernel: audit(1100925356.180:0): avc: denied { getattr } for pid=2448 exe=/usr/sbin/httpd path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:56 localhost kernel: audit(1100925356.181:0): avc: denied { execute } for pid=2448 path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 19 23:35:56 localhost kernel: audit(1100925356.237:0): avc: denied { read } for pid=2448 exe=/usr/sbin/httpd name=libaprutil-0.so.0 dev=hda3 ino=103404 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=lnk_file >Nov 19 23:35:57 localhost kernel: audit(1100925357.204:0): avc: denied { append } for pid=2448 exe=/usr/sbin/httpd name=error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 02:37:05 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 20 07:23:08 localhost kernel: audit(1100935340.336:0): avc: denied { read write } for pid=604 exe=/sbin/minilogd name=console dev=tmpfs ino=930 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file >Nov 20 07:23:08 localhost kernel: audit(1100935340.337:0): avc: denied { write } for pid=604 exe=/sbin/minilogd name=/ dev=tmpfs ino=929 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 07:23:08 localhost kernel: audit(1100935340.337:0): avc: denied { add_name } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 07:23:08 localhost kernel: audit(1100935340.337:0): avc: denied { create } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 07:23:08 localhost kernel: audit(1100935340.338:0): avc: denied { getattr } for pid=607 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 07:23:08 localhost kernel: audit(1100935345.294:0): avc: denied { write } for pid=607 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 07:23:08 localhost kernel: audit(1100935349.114:0): avc: denied { remove_name } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 07:23:08 localhost kernel: audit(1100935349.114:0): avc: denied { unlink } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 07:23:08 localhost kernel: audit(1100953386.843:0): avc: denied { read } for pid=2081 exe=/sbin/syslogd name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:08 localhost kernel: audit(1100953386.844:0): avc: denied { getattr } for pid=2081 exe=/sbin/syslogd path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:08 localhost kernel: audit(1100953386.858:0): avc: denied { append } for pid=2081 exe=/sbin/syslogd name=messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:08 localhost kernel: audit(1100953386.858:0): avc: denied { ioctl } for pid=2081 exe=/sbin/syslogd path=/var/log/messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:08 localhost kernel: audit(1100953386.865:0): avc: denied { setattr } for pid=2081 exe=/sbin/syslogd name=log dev=tmpfs ino=4961 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 07:23:08 localhost kernel: audit(1100953387.587:0): avc: denied { search } for pid=2112 exe=/sbin/portmap name=/ dev=hda3 ino=2 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 07:23:08 localhost kernel: audit(1100953387.619:0): avc: denied { search } for pid=2113 exe=/sbin/portmap name=/ dev=tmpfs ino=929 scontext=user_u:system_r:portmap_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 07:23:08 localhost kernel: audit(1100953387.630:0): avc: denied { read } for pid=2113 exe=/sbin/portmap name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:08 localhost kernel: audit(1100953387.630:0): avc: denied { getattr } for pid=2113 exe=/sbin/portmap path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:17 localhost kernel: audit(1100953397.732:0): avc: denied { search } for pid=2445 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 07:23:17 localhost kernel: audit(1100953397.733:0): avc: denied { read } for pid=2445 exe=/usr/sbin/httpd name=libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:17 localhost kernel: audit(1100953397.733:0): avc: denied { getattr } for pid=2445 exe=/usr/sbin/httpd path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:17 localhost kernel: audit(1100953397.733:0): avc: denied { execute } for pid=2445 path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:17 localhost kernel: audit(1100953397.775:0): avc: denied { read } for pid=2445 exe=/usr/sbin/httpd name=libaprutil-0.so.0 dev=hda3 ino=103404 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=lnk_file >Nov 20 07:23:18 localhost kernel: audit(1100953398.728:0): avc: denied { append } for pid=2445 exe=/usr/sbin/httpd name=error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 07:23:47 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 20 09:30:32 localhost kernel: audit(1100942986.311:0): avc: denied { read write } for pid=604 exe=/sbin/minilogd name=console dev=tmpfs ino=930 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file >Nov 20 09:30:32 localhost kernel: audit(1100942986.311:0): avc: denied { write } for pid=604 exe=/sbin/minilogd name=/ dev=tmpfs ino=929 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 09:30:32 localhost kernel: audit(1100942986.311:0): avc: denied { add_name } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 09:30:32 localhost kernel: audit(1100942986.312:0): avc: denied { create } for pid=604 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 09:30:32 localhost kernel: audit(1100942986.312:0): avc: denied { getattr } for pid=607 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 09:30:32 localhost kernel: audit(1100942991.282:0): avc: denied { write } for pid=607 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 09:30:32 localhost kernel: audit(1100942995.091:0): avc: denied { remove_name } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 09:30:32 localhost kernel: audit(1100942995.091:0): avc: denied { unlink } for pid=1180 exe=/sbin/minilogd name=log dev=tmpfs ino=1785 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 09:30:32 localhost kernel: audit(1100961030.712:0): avc: denied { read } for pid=2081 exe=/sbin/syslogd name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:32 localhost kernel: audit(1100961030.713:0): avc: denied { getattr } for pid=2081 exe=/sbin/syslogd path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:32 localhost kernel: audit(1100961030.728:0): avc: denied { append } for pid=2081 exe=/sbin/syslogd name=messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:32 localhost kernel: audit(1100961030.728:0): avc: denied { ioctl } for pid=2081 exe=/sbin/syslogd path=/var/log/messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:32 localhost kernel: audit(1100961030.735:0): avc: denied { setattr } for pid=2081 exe=/sbin/syslogd name=log dev=tmpfs ino=4959 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 09:30:32 localhost kernel: audit(1100961031.842:0): avc: denied { search } for pid=2112 exe=/sbin/portmap name=/ dev=hda3 ino=2 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 09:30:32 localhost kernel: audit(1100961031.860:0): avc: denied { search } for pid=2113 exe=/sbin/portmap name=/ dev=tmpfs ino=929 scontext=user_u:system_r:portmap_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 09:30:32 localhost kernel: audit(1100961031.872:0): avc: denied { read } for pid=2113 exe=/sbin/portmap name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:32 localhost kernel: audit(1100961031.872:0): avc: denied { getattr } for pid=2113 exe=/sbin/portmap path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:42 localhost kernel: audit(1100961042.630:0): avc: denied { search } for pid=2445 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 09:30:42 localhost kernel: audit(1100961042.631:0): avc: denied { read } for pid=2445 exe=/usr/sbin/httpd name=libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:42 localhost kernel: audit(1100961042.631:0): avc: denied { getattr } for pid=2445 exe=/usr/sbin/httpd path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:42 localhost kernel: audit(1100961042.631:0): avc: denied { execute } for pid=2445 path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 09:30:42 localhost kernel: audit(1100961042.673:0): avc: denied { read } for pid=2445 exe=/usr/sbin/httpd name=libaprutil-0.so.0 dev=hda3 ino=103404 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=lnk_file >Nov 20 09:30:43 localhost kernel: audit(1100961043.683:0): avc: denied { append } for pid=2445 exe=/usr/sbin/httpd name=error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 13:45:28 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 20 15:49:58 localhost kernel: audit(1100965751.021:0): avc: denied { read write } for pid=606 exe=/sbin/minilogd name=console dev=tmpfs ino=930 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=chr_file >Nov 20 15:49:58 localhost kernel: audit(1100965751.021:0): avc: denied { write } for pid=606 exe=/sbin/minilogd name=/ dev=tmpfs ino=929 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 15:49:58 localhost kernel: audit(1100965751.021:0): avc: denied { add_name } for pid=606 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 15:49:58 localhost kernel: audit(1100965751.021:0): avc: denied { create } for pid=606 exe=/sbin/minilogd name=log scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 15:49:58 localhost kernel: audit(1100965751.022:0): avc: denied { getattr } for pid=609 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=1788 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 15:49:58 localhost kernel: audit(1100965756.006:0): avc: denied { write } for pid=609 exe=/sbin/minilogd name=log dev=tmpfs ino=1788 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 15:49:58 localhost kernel: audit(1100965759.815:0): avc: denied { remove_name } for pid=1182 exe=/sbin/minilogd name=log dev=tmpfs ino=1788 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 15:49:58 localhost kernel: audit(1100965759.815:0): avc: denied { unlink } for pid=1182 exe=/sbin/minilogd name=log dev=tmpfs ino=1788 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 15:49:58 localhost kernel: audit(1100983796.690:0): avc: denied { read } for pid=1910 exe=/sbin/syslogd name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:49:58 localhost kernel: audit(1100983796.690:0): avc: denied { getattr } for pid=1910 exe=/sbin/syslogd path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:49:58 localhost kernel: audit(1100983796.706:0): avc: denied { append } for pid=1910 exe=/sbin/syslogd name=messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:49:58 localhost kernel: audit(1100983796.706:0): avc: denied { ioctl } for pid=1910 exe=/sbin/syslogd path=/var/log/messages dev=hda3 ino=408316 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:49:58 localhost kernel: audit(1100983796.713:0): avc: denied { setattr } for pid=1910 exe=/sbin/syslogd name=log dev=tmpfs ino=4583 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:tmpfs_t tclass=sock_file >Nov 20 15:49:58 localhost kernel: audit(1100983797.605:0): avc: denied { search } for pid=1941 exe=/sbin/portmap name=/ dev=hda3 ino=2 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 15:49:58 localhost kernel: audit(1100983797.638:0): avc: denied { search } for pid=1942 exe=/sbin/portmap name=/ dev=tmpfs ino=929 scontext=user_u:system_r:portmap_t tcontext=user_u:object_r:tmpfs_t tclass=dir >Nov 20 15:49:58 localhost kernel: audit(1100983797.651:0): avc: denied { read } for pid=1942 exe=/sbin/portmap name=nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:49:58 localhost kernel: audit(1100983797.651:0): avc: denied { getattr } for pid=1942 exe=/sbin/portmap path=/etc/nsswitch.conf dev=hda3 ino=554920 scontext=user_u:system_r:portmap_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:50:08 localhost kernel: audit(1100983808.337:0): avc: denied { search } for pid=2274 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 15:50:08 localhost kernel: audit(1100983808.337:0): avc: denied { read } for pid=2274 exe=/usr/sbin/httpd name=libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:50:08 localhost kernel: audit(1100983808.338:0): avc: denied { getattr } for pid=2274 exe=/usr/sbin/httpd path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:50:08 localhost kernel: audit(1100983808.338:0): avc: denied { execute } for pid=2274 path=/lib/libpcre.so.0.0.1 dev=hda3 ino=685883 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 15:50:08 localhost kernel: audit(1100983808.380:0): avc: denied { read } for pid=2274 exe=/usr/sbin/httpd name=libaprutil-0.so.0 dev=hda3 ino=103404 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=lnk_file >Nov 20 15:50:09 localhost kernel: audit(1100983809.318:0): avc: denied { append } for pid=2274 exe=/usr/sbin/httpd name=error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 16:31:25 localhost kernel: audit(1100986285.045:0): avc: granted { load_policy } for pid=3190 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security >Nov 20 16:36:23 localhost kernel: audit(1100986583.107:0): avc: granted { load_policy } for pid=3322 exe=/usr/sbin/load_policy scontext=root:system_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security >Nov 20 16:37:17 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 20 16:37:25 localhost kernel: audit(1100986645.478:0): avc: denied { search } for pid=2275 exe=/usr/sbin/httpd name=/ dev=hda3 ino=2 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir >Nov 20 16:37:25 localhost kernel: audit(1100986645.515:0): avc: denied { append } for pid=2275 exe=/usr/sbin/httpd path=/var/log/httpd/error_log dev=hda3 ino=783426 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=file >Nov 20 16:53:12 localhost dbus: avc: 1 AV entries and 1/512 buckets used, longest chain length 1 >Nov 20 20:05:51 localhost kernel: audit(1100981107.146:0): avc: denied { ioctl } for pid=613 exe=/bin/bash path=/proc/ide/ide0/hda/media dev=proc ino=-268435122 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:proc_t tclass=file >Nov 20 20:05:51 localhost kernel: audit(1100981107.350:0): avc: denied { ioctl } for pid=613 exe=/bin/bash path=/proc/ide/ide1/hdc/media dev=proc ino=-268435110 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:proc_t tclass=file >Nov 20 20:05:51 localhost kernel: audit(1100999126.945:0): avc: denied { search } for pid=1576 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:05:51 localhost kernel: audit(1100999126.955:0): avc: denied { search } for pid=1583 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:05:51 localhost kernel: audit(1100999127.025:0): avc: denied { search } for pid=1588 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:05:51 localhost kernel: audit(1100999144.634:0): avc: denied { read } for pid=1646 exe=/usr/sbin/cpuspeed name=mtab dev=hda3 ino=557677 scontext=system_u:system_r:cpuspeed_t tcontext=system_u:object_r:etc_runtime_t tclass=file >Nov 20 20:05:51 localhost kernel: audit(1100999144.634:0): avc: denied { read } for pid=1646 exe=/usr/sbin/cpuspeed name=fstab dev=hda3 ino=555388 scontext=system_u:system_r:cpuspeed_t tcontext=system_u:object_r:etc_t tclass=file >Nov 20 20:05:58 localhost kernel: audit(1100999158.170:0): avc: denied { search } for pid=2197 exe=/usr/sbin/clamd name=clamav dev=hda3 ino=473684 scontext=system_u:system_r:clamd_t tcontext=system_u:object_r:freshclam_log_t tclass=dir >Nov 20 20:06:00 localhost kernel: audit(1100999160.614:0): avc: denied { fowner } for pid=2250 exe=/sbin/restorecon capability=3 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:restorecon_t tclass=capability >Nov 20 20:06:18 localhost kernel: audit(1100999178.145:0): avc: denied { getattr } for pid=2474 exe=/bin/mount path=/tos1 dev=hda3 ino=489601 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:default_t tclass=dir >Nov 20 20:06:20 localhost kernel: audit(1100999180.875:0): avc: denied { search } for pid=2456 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 20 20:06:20 localhost kernel: audit(1100999180.876:0): avc: denied { search } for pid=2456 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 20 20:06:20 localhost kernel: audit(1100999180.877:0): avc: denied { search } for pid=2456 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 20 20:06:20 localhost kernel: audit(1100999180.877:0): avc: denied { search } for pid=2456 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 20 20:14:21 localhost kernel: audit(1100999661.322:0): avc: denied { search } for pid=2959 exe=/usr/X11R6/bin/Xorg name=selinux dev=hda3 ino=603892 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=dir >Nov 20 20:14:21 localhost kernel: audit(1100999661.355:0): avc: denied { search } for pid=2959 exe=/usr/X11R6/bin/Xorg name=console dev=hda3 ino=408043 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:pam_var_console_t tclass=dir >Nov 20 20:15:03 localhost kernel: audit(1100999703.350:0): avc: granted { setenforce } for pid=2961 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security >Nov 20 20:15:14 localhost kernel: audit(1100999714.269:0): avc: denied { search } for pid=2974 exe=/usr/X11R6/bin/Xorg name=selinux dev=hda3 ino=603892 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=dir >Nov 20 20:15:14 localhost kernel: audit(1100999714.269:0): avc: denied { read } for pid=2974 exe=/usr/X11R6/bin/Xorg name=config dev=hda3 ino=603908 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 20 20:15:14 localhost kernel: audit(1100999714.270:0): avc: denied { getattr } for pid=2974 exe=/usr/X11R6/bin/Xorg path=/etc/selinux/config dev=hda3 ino=603908 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 20 20:15:14 localhost kernel: audit(1100999714.277:0): avc: denied { search } for pid=2974 exe=/usr/X11R6/bin/Xorg name=console dev=hda3 ino=408043 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:pam_var_console_t tclass=dir >Nov 20 20:15:22 localhost kernel: audit(1100999722.138:0): avc: denied { read } for pid=3050 exe=/usr/bin/ssh-agent name=config dev=hda3 ino=603908 scontext=user_u:user_r:user_ssh_agent_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 20 20:15:22 localhost kernel: audit(1100999722.139:0): avc: denied { getattr } for pid=3050 exe=/usr/bin/ssh-agent path=/etc/selinux/config dev=hda3 ino=603908 scontext=user_u:user_r:user_ssh_agent_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 20 20:15:32 localhost kernel: audit(1100999732.960:0): avc: denied { search } for pid=2974 exe=/usr/X11R6/bin/Xorg name=.gnome2 dev=hda3 ino=1338661 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=dir >Nov 20 20:15:32 localhost kernel: audit(1100999732.960:0): avc: denied { read } for pid=2974 exe=/usr/X11R6/bin/Xorg name=fonts.dir dev=hda3 ino=1338668 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=file >Nov 20 20:15:32 localhost kernel: audit(1100999732.960:0): avc: denied { getattr } for pid=2974 exe=/usr/X11R6/bin/Xorg path=/home/jim/.gnome2/share/cursor-fonts/fonts.dir dev=hda3 ino=1338668 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=file >Nov 20 20:15:41 localhost dbus: avc: received setenforce notice (enforcing=0) >Nov 20 20:15:42 localhost kernel: audit(1100999742.244:0): avc: denied { use } for pid=3110 exe=/bin/mount path=/dev/tty2 dev=tmpfs ino=1864 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:local_login_t tclass=fd >Nov 20 20:16:54 localhost kernel: audit(1100999814.959:0): avc: denied { write } for pid=3156 exe=/usr/sbin/userhelper name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_userhelper_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:54 localhost kernel: audit(1100999814.959:0): avc: denied { add_name } for pid=3156 exe=/usr/sbin/userhelper name=.xauthclDLiD scontext=user_u:user_r:user_userhelper_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:54 localhost kernel: audit(1100999814.959:0): avc: denied { create } for pid=3156 exe=/usr/sbin/userhelper name=.xauthclDLiD scontext=user_u:user_r:user_userhelper_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.027:0): avc: denied { setattr } for pid=3156 exe=/usr/sbin/userhelper name=.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_userhelper_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.035:0): avc: denied { search } for pid=3158 exe=/usr/X11R6/bin/xauth name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:55 localhost kernel: audit(1100999815.036:0): avc: denied { write } for pid=3158 exe=/usr/X11R6/bin/xauth name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:55 localhost kernel: audit(1100999815.036:0): avc: denied { add_name } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD-c scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:55 localhost kernel: audit(1100999815.036:0): avc: denied { create } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD-c scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.037:0): avc: denied { link } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD-c dev=hda3 ino=391918 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.037:0): avc: denied { write } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.038:0): avc: denied { read } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.038:0): avc: denied { getattr } for pid=3158 exe=/usr/X11R6/bin/xauth path=/root/.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:55 localhost kernel: audit(1100999815.040:0): avc: denied { remove_name } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 20 20:16:55 localhost kernel: audit(1100999815.040:0): avc: denied { unlink } for pid=3158 exe=/usr/X11R6/bin/xauth name=.xauthclDLiD dev=hda3 ino=391917 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 20 20:16:56 localhost kernel: audit(1100999816.429:0): avc: denied { connectto } for pid=3159 exe=/usr/bin/python path=/tmp/.X11-unix/X0 scontext=root:sysadm_r:sysadm_t tcontext=user_u:user_r:user_xserver_t tclass=unix_stream_socket >Nov 20 20:17:02 localhost kernel: audit(1100999822.827:0): avc: denied { unix_read unix_write } for pid=2974 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm >Nov 20 20:17:02 localhost kernel: audit(1100999822.827:0): avc: denied { read write } for pid=2974 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm >Nov 20 20:17:02 localhost kernel: audit(1100999822.827:0): avc: denied { use } for pid=2974 path=/SYSV00000000 (deleted) dev=tmpfs ino=557072 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=fd >Nov 20 20:17:02 localhost kernel: audit(1100999822.827:0): avc: denied { read write } for pid=2974 path=/SYSV00000000 (deleted) dev=tmpfs ino=557072 scontext=user_u:user_r:user_xserver_t tcontext=root:object_r:sysadm_tmpfs_t tclass=file >Nov 20 20:17:02 localhost kernel: audit(1100999822.827:0): avc: denied { getattr associate } for pid=2974 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > You need to install policycoreutils and relabel the file system. Dan From dragoran at feuerpokemon.de Sun Nov 21 07:06:23 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 21 Nov 2004 08:06:23 +0100 Subject: PHP cannot upload files In-Reply-To: <1100972086.3987.5.camel@nexus.verbum.private> References: <419F058A.8030106@feuerpokemon.de> <1100972086.3987.5.camel@nexus.verbum.private> Message-ID: <41A03E6F.3060706@feuerpokemon.de> Colin Walters schrieb: >On Sat, 2004-11-20 at 09:51 +0100, dragoran wrote: > > >>I cannot upload files via php (selinux=enabled;policy=targeted). >>php shows this error: >>*Warning*: File upload error - unable to create a temporary file in >>*Unknown* on line *0 >>*And in dmesg I found this error: >>audit(1100940427.918:0): avc: denied { write } for pid=9202 >>exe=/usr/sbin/httpd name=tmp dev=hda3 ino=24 >>scontext=root:system_r:httpd_t tcontext=root:object_r:root_t tclass=dir >> >> > >Do you have /tmp on a separate filesystem? What does: >ls -Z /tmp >show? > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > /tmp is on the root filesystem... ls -Z /tmp shows this: ------------------------------------------------------------------------------------------------ -rw-rw-r-- dragoran dragoran user_u:object_r:root_t Acro8ip1Sz drwx------ dragoran dragoran user_u:object_r:root_t gconfd-dragoran drwx------ root root root:object_r:root_t gconfd-root drwxr-xr-x dragoran dragoran user_u:object_r:root_t hsperfdata_dragoran drwx------ dragoran dragoran user_u:object_r:root_t keyring-1zTHrf drwx------ dragoran dragoran user_u:object_r:root_t keyring-59xIh9 drwx------ dragoran dragoran user_u:object_r:root_t keyring-OEkx5a drwx------ dragoran dragoran user_u:object_r:root_t keyring-YxzPaV -rw------- root root root:object_r:root_t libGL.la-8tPn7h srwxrwxr-x dragoran dragoran user_u:object_r:root_t mapping-dragoran -rw------- dragoran dragoran user_u:object_r:root_t nsmail.eml -rw------- dragoran dragoran user_u:object_r:root_t nsmail.html -rw------- dragoran dragoran user_u:object_r:root_t nsmail.tmp -rw------- root root root:object_r:root_t nv-5Lurw0 -rw-rw-r-- dragoran dragoran user_u:object_r:root_t nvclock drwx------ dragoran dragoran user_u:object_r:root_t orbit-dragoran drwx------ root root root:object_r:root_t orbit-root drwxr-xr-x root root root:object_r:root_t selfgz3945 drwxr-xr-x root root root:object_r:root_t selfgz4237 drwx------ dragoran dragoran user_u:object_r:root_t ssh-ICLNfV3471 drwx------ dragoran dragoran user_u:object_r:root_t ssh-lYueV15584 -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.66SRLi -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.7jh0Kd -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.bmLq1J -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.CBjOzp -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.IhxdpD -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.J6JXxG -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.JqB0Yr -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.mq2fk5 -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.niYKSn -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.nsJ6HX -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.Rl6HB6 -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.tIuAjd -rw------- dragoran dragoran user_u:object_r:root_t xses-dragoran.zAFUiz ----------------------------------------------------------------------------------------------------------- From dragoran at feuerpokemon.de Sun Nov 21 07:12:56 2004 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 21 Nov 2004 08:12:56 +0100 Subject: PHP cannot upload files In-Reply-To: <41A03E6F.3060706@feuerpokemon.de> References: <419F058A.8030106@feuerpokemon.de> <1100972086.3987.5.camel@nexus.verbum.private> <41A03E6F.3060706@feuerpokemon.de> Message-ID: <41A03FF8.5050306@feuerpokemon.de> dragoran schrieb: > Colin Walters schrieb: > >> On Sat, 2004-11-20 at 09:51 +0100, dragoran wrote: >> >> >>> I cannot upload files via php (selinux=enabled;policy=targeted). >>> php shows this error: >>> *Warning*: File upload error - unable to create a temporary file in >>> *Unknown* on line *0 >>> *And in dmesg I found this error: >>> audit(1100940427.918:0): avc: denied { write } for pid=9202 >>> exe=/usr/sbin/httpd name=tmp dev=hda3 ino=24 >>> scontext=root:system_r:httpd_t tcontext=root:object_r:root_t tclass=dir >>> >> >> >> Do you have /tmp on a separate filesystem? What does: >> ls -Z /tmp >> show? >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> > /tmp is on the root filesystem... > ls -Z /tmp shows this: > ------------------------------------------------------------------------------------------------ > > -rw-rw-r-- dragoran dragoran user_u:object_r:root_t Acro8ip1Sz > drwx------ dragoran dragoran user_u:object_r:root_t > gconfd-dragoran > drwx------ root root root:object_r:root_t > gconfd-root > drwxr-xr-x dragoran dragoran user_u:object_r:root_t > hsperfdata_dragoran > drwx------ dragoran dragoran user_u:object_r:root_t > keyring-1zTHrf > drwx------ dragoran dragoran user_u:object_r:root_t > keyring-59xIh9 > drwx------ dragoran dragoran user_u:object_r:root_t > keyring-OEkx5a > drwx------ dragoran dragoran user_u:object_r:root_t > keyring-YxzPaV > -rw------- root root root:object_r:root_t > libGL.la-8tPn7h > srwxrwxr-x dragoran dragoran user_u:object_r:root_t > mapping-dragoran > -rw------- dragoran dragoran user_u:object_r:root_t nsmail.eml > -rw------- dragoran dragoran user_u:object_r:root_t > nsmail.html > -rw------- dragoran dragoran user_u:object_r:root_t nsmail.tmp > -rw------- root root root:object_r:root_t nv-5Lurw0 > -rw-rw-r-- dragoran dragoran user_u:object_r:root_t nvclock > drwx------ dragoran dragoran user_u:object_r:root_t > orbit-dragoran > drwx------ root root root:object_r:root_t orbit-root > drwxr-xr-x root root root:object_r:root_t selfgz3945 > drwxr-xr-x root root root:object_r:root_t selfgz4237 > drwx------ dragoran dragoran user_u:object_r:root_t > ssh-ICLNfV3471 > drwx------ dragoran dragoran user_u:object_r:root_t > ssh-lYueV15584 > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.66SRLi > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.7jh0Kd > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.bmLq1J > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.CBjOzp > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.IhxdpD > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.J6JXxG > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.JqB0Yr > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.mq2fk5 > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.niYKSn > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.nsJ6HX > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.Rl6HB6 > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.tIuAjd > -rw------- dragoran dragoran user_u:object_r:root_t > xses-dragoran.zAFUiz > ----------------------------------------------------------------------------------------------------------- > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > /sbin/restorecon /tmp fixed the problem /tmp is now system_u:object_r:tmp_t From jim-cornette at insight.rr.com Sun Nov 21 13:40:40 2004 From: jim-cornette at insight.rr.com (Jim Cornette) Date: Sun, 21 Nov 2004 08:40:40 -0500 Subject: installation of selinux on non-selinux system In-Reply-To: <41A02203.2040503@redhat.com> References: <419FF545.3080904@insight.rr.com> <41A02203.2040503@redhat.com> Message-ID: <41A09AD8.20203@insight.rr.com> Daniel J Walsh wrote: > Jim Cornette wrote: > >> After upgrading a computer from FC2 to FC3, I decided to give SELinux >> a shot and used up2date to retrieve the rpm for >> selinux-policy-targeted and expected for all needed deps to be >> pulled in. The other dependent ackages did not get pulled in with >> this selection. I ended up having system messages not being >> accessable and also httpd being damened with errors. I supposed that >> there was an abnormality on my particular system. Within recent days, >> I have noted others experiencing similar failures on the fedora-list. >> I then decided that this might e a more common prblem than first >> expected. >> >> Another Fedora user was asking questions regarding running fixfiles >> relabel. I noticed that I also did not have fixfiles installed. >> <> > > You need to install policycoreutils and relabel the file system. > Thanks Dan for the name of the rpm that is needed for fixfiles so relabeling can be performed. My main question is for those systems that are upgraded from non-selinux to systems where selinux is desired to be added. If one was to install selinux-policy-targeted via a repository installation, up2date in my case. I would expect the inclusion of other deps being pulled in. Selinux gives sort of a working system when using system-config-securitylevel to enable selinux via the gui. I am not too sure if this would introduce "dep hell" if having policycoreutils pulled in when selinux-policy for targeted or strict is pulled from a repo. After relabeling my filesystem again in runlevel 1, I seem to get the same type of errors as experienced before. .mozilla related files seemed to be the major files that content was tried to be changed, when relabeling for strict. See attached avc for today. In order to bring up X, running setenforce 0 at a root shell was needed, in order to launch X successfully. If there is some lingering config file, either systemwide or hanging out in the per user directory that is blocking X, I don't know. Thanks, Jim > Dan -- Peers's Law: The solution to a problem changes the nature of the problem. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: after-relabel-no-X URL: From dwalsh at redhat.com Sun Nov 21 15:46:31 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sun, 21 Nov 2004 10:46:31 -0500 Subject: installation of selinux on non-selinux system In-Reply-To: <41A09AD8.20203@insight.rr.com> References: <419FF545.3080904@insight.rr.com> <41A02203.2040503@redhat.com> <41A09AD8.20203@insight.rr.com> Message-ID: <41A0B857.2090200@redhat.com> Jim Cornette wrote: > Daniel J Walsh wrote: > >> Jim Cornette wrote: >> >>> After upgrading a computer from FC2 to FC3, I decided to give >>> SELinux a shot and used up2date to retrieve the rpm for >>> selinux-policy-targeted and expected for all needed deps to be >>> pulled in. The other dependent ackages did not get pulled in with >>> this selection. I ended up having system messages not being >>> accessable and also httpd being damened with errors. I supposed that >>> there was an abnormality on my particular system. Within recent >>> days, I have noted others experiencing similar failures on the >>> fedora-list. I then decided that this might e a more common prblem >>> than first expected. >>> >>> Another Fedora user was asking questions regarding running fixfiles >>> relabel. I noticed that I also did not have fixfiles installed. >>> <> >> >> >> You need to install policycoreutils and relabel the file system. >> > Thanks Dan for the name of the rpm that is needed for fixfiles so > relabeling can be performed. My main question is for those systems > that are upgraded from non-selinux to systems where selinux is desired > to be added. > If one was to install selinux-policy-targeted via a repository > installation, up2date in my case. I would expect the inclusion of > other deps being pulled in. > Selinux gives sort of a working system when using > system-config-securitylevel to enable selinux via the gui. I am not > too sure if this would introduce "dep hell" if having policycoreutils > pulled in when selinux-policy for targeted or strict is pulled from a > repo. > I have changed selinux-policy-targeted to require policycoreutils so it will be pulled in in the future. Secondly from the looks of it you are running strict policy. Please either run system-config-securitylevel and select targeted policy and reboot. (/.autorelabel) should be created and or you can edit /etc/selinux/config and change SELINUXTYPE=strict to SELINUXTYPE=targeted and touch /.autorelabel then reboot. The init scripts will take care of relabeling. > After relabeling my filesystem again in runlevel 1, I seem to get the > same type of errors as experienced before. .mozilla related files > seemed to be the major files that content was tried to be changed, > when relabeling for strict. See attached avc for today. > In order to bring up X, running setenforce 0 at a root shell was > needed, in order to launch X successfully. If there is some lingering > config file, either systemwide or hanging out in the per user > directory that is blocking X, I don't know. > The strict policy you are running 1.17.30 is way out of date. If you want to run strict policy you need to grab the one off of Rawhide or my people page and update and relabel. Upgrades from not SELinux boxes are not supported for SELinux for the simple reason that relabeling is required. So your machine ended up in a rather strange state. > Thanks, > Jim > >> Dan > > >------------------------------------------------------------------------ > >Nov 21 00:29:59 localhost kernel: <3>audit(1101014999.006:0): avc: denied { remove_name } for pid=3156 exe=/usr/sbin/userhelper name=.xauthclDLiD dev=hda3 ino=391919 scontext=user_u:user_r:user_userhelper_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 00:29:59 localhost kernel: audit(1101014999.006:0): avc: denied { unlink } for pid=3156 exe=/usr/sbin/userhelper name=.xauthclDLiD dev=hda3 ino=391919 scontext=user_u:user_r:user_userhelper_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 00:30:05 localhost kernel: audit(1101015005.924:0): avc: denied { search } for pid=3032 exe=/usr/bin/gnome-session name=console dev=hda3 ino=408043 scontext=user_u:user_r:user_t tcontext=system_u:object_r:pam_var_console_t tclass=dir >Nov 21 00:30:33 localhost kernel: audit(1101015033.363:0): avc: denied { write } for pid=2973 exe=/usr/X11R6/bin/xinit path=/dev/tty2 dev=tmpfs ino=1864 scontext=user_u:user_r:user_t tcontext=system_u:object_r:tty_device_t tclass=chr_file >Nov 21 00:30:35 localhost dbus: avc: 7 AV entries and 6/512 buckets used, longest chain length 2 >Nov 21 08:00:19 localhost kernel: audit(1101023972.861:0): avc: denied { ioctl } for pid=613 exe=/bin/bash path=/proc/ide/ide0/hda/media dev=proc ino=-268435122 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:proc_t tclass=file >Nov 21 08:00:19 localhost kernel: audit(1101023973.069:0): avc: denied { ioctl } for pid=613 exe=/bin/bash path=/proc/ide/ide1/hdc/media dev=proc ino=-268435110 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:proc_t tclass=file >Nov 21 08:00:19 localhost kernel: audit(1101041993.110:0): avc: denied { search } for pid=1583 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:00:19 localhost kernel: audit(1101041993.180:0): avc: denied { search } for pid=1580 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:00:19 localhost kernel: audit(1101041993.191:0): avc: denied { search } for pid=1577 exe=/sbin/alsactl name=root dev=hda3 ino=424321 scontext=system_u:system_r:udev_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:00:19 localhost kernel: audit(1101042010.642:0): avc: denied { read } for pid=1646 exe=/usr/sbin/cpuspeed name=mtab dev=hda3 ino=557700 scontext=system_u:system_r:cpuspeed_t tcontext=system_u:object_r:etc_runtime_t tclass=file >Nov 21 08:00:19 localhost kernel: audit(1101042010.642:0): avc: denied { read } for pid=1646 exe=/usr/sbin/cpuspeed name=fstab dev=hda3 ino=555388 scontext=system_u:system_r:cpuspeed_t tcontext=system_u:object_r:etc_t tclass=file >Nov 21 08:00:25 localhost kernel: audit(1101042025.563:0): avc: denied { search } for pid=2197 exe=/usr/sbin/clamd name=clamav dev=hda3 ino=473684 scontext=system_u:system_r:clamd_t tcontext=system_u:object_r:freshclam_log_t tclass=dir >Nov 21 08:00:27 localhost kernel: audit(1101042027.875:0): avc: denied { fowner } for pid=2250 exe=/sbin/restorecon capability=3 scontext=system_u:system_r:restorecon_t tcontext=system_u:system_r:restorecon_t tclass=capability >Nov 21 08:00:35 localhost kernel: audit(1101042035.247:0): avc: denied { getattr } for pid=2406 exe=/bin/mount path=/tos1 dev=hda3 ino=489601 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:default_t tclass=dir >Nov 21 08:00:38 localhost kernel: audit(1101042038.076:0): avc: denied { search } for pid=2388 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 21 08:00:38 localhost kernel: audit(1101042038.076:0): avc: denied { search } for pid=2388 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 21 08:00:38 localhost kernel: audit(1101042038.077:0): avc: denied { search } for pid=2388 exe=/usr/sbin/hald name=lib dev=hda3 ino=408002 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:var_lib_t tclass=dir >Nov 21 08:04:09 localhost kernel: audit(1101042249.690:0): avc: denied { search } for pid=2894 exe=/usr/X11R6/bin/Xorg name=selinux dev=hda3 ino=603892 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=dir >Nov 21 08:04:09 localhost kernel: audit(1101042249.731:0): avc: denied { search } for pid=2894 exe=/usr/X11R6/bin/Xorg name=console dev=hda3 ino=408043 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:pam_var_console_t tclass=dir >Nov 21 08:04:51 localhost kernel: audit(1101042291.658:0): avc: granted { setenforce } for pid=2896 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security >Nov 21 08:05:08 localhost kernel: audit(1101042308.913:0): avc: denied { search } for pid=2910 exe=/usr/X11R6/bin/Xorg name=selinux dev=hda3 ino=603892 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=dir >Nov 21 08:05:08 localhost kernel: audit(1101042308.913:0): avc: denied { read } for pid=2910 exe=/usr/X11R6/bin/Xorg name=config dev=hda3 ino=603908 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 21 08:05:08 localhost kernel: audit(1101042308.914:0): avc: denied { getattr } for pid=2910 exe=/usr/X11R6/bin/Xorg path=/etc/selinux/config dev=hda3 ino=603908 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 21 08:05:08 localhost kernel: audit(1101042308.922:0): avc: denied { search } for pid=2910 exe=/usr/X11R6/bin/Xorg name=console dev=hda3 ino=408043 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:pam_var_console_t tclass=dir >Nov 21 08:05:17 localhost kernel: audit(1101042317.967:0): avc: denied { read } for pid=2986 exe=/usr/bin/ssh-agent name=config dev=hda3 ino=603908 scontext=user_u:user_r:user_ssh_agent_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 21 08:05:17 localhost kernel: audit(1101042317.968:0): avc: denied { getattr } for pid=2986 exe=/usr/bin/ssh-agent path=/etc/selinux/config dev=hda3 ino=603908 scontext=user_u:user_r:user_ssh_agent_t tcontext=system_u:object_r:selinux_config_t tclass=file >Nov 21 08:05:28 localhost kernel: audit(1101042328.992:0): avc: denied { search } for pid=2910 exe=/usr/X11R6/bin/Xorg name=.gnome2 dev=hda3 ino=1338661 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=dir >Nov 21 08:05:28 localhost kernel: audit(1101042328.992:0): avc: denied { read } for pid=2910 exe=/usr/X11R6/bin/Xorg name=fonts.dir dev=hda3 ino=1338668 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=file >Nov 21 08:05:28 localhost kernel: audit(1101042328.992:0): avc: denied { getattr } for pid=2910 exe=/usr/X11R6/bin/Xorg path=/home/jim/.gnome2/share/cursor-fonts/fonts.dir dev=hda3 ino=1338668 scontext=user_u:user_r:user_xserver_t tcontext=system_u:object_r:user_home_t tclass=file >Nov 21 08:05:38 localhost dbus: avc: received setenforce notice (enforcing=0) >Nov 21 08:05:38 localhost kernel: audit(1101042338.848:0): avc: denied { use } for pid=3046 exe=/bin/mount path=/dev/tty2 dev=tmpfs ino=1864 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:local_login_t tclass=fd >Nov 21 08:09:29 localhost kernel: audit(1101042569.604:0): avc: denied { write } for pid=3093 exe=/usr/sbin/userhelper name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_userhelper_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.604:0): avc: denied { add_name } for pid=3093 exe=/usr/sbin/userhelper name=.xauthDMglgN scontext=user_u:user_r:user_userhelper_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.604:0): avc: denied { create } for pid=3093 exe=/usr/sbin/userhelper name=.xauthDMglgN scontext=user_u:user_r:user_userhelper_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.630:0): avc: denied { setattr } for pid=3093 exe=/usr/sbin/userhelper name=.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_userhelper_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.641:0): avc: denied { search } for pid=3095 exe=/usr/X11R6/bin/xauth name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.642:0): avc: denied { write } for pid=3095 exe=/usr/X11R6/bin/xauth name=root dev=hda3 ino=424321 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.642:0): avc: denied { add_name } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN-c scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.642:0): avc: denied { create } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN-c scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.655:0): avc: denied { link } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN-c dev=hda3 ino=425338 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.656:0): avc: denied { write } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.657:0): avc: denied { read } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.657:0): avc: denied { getattr } for pid=3095 exe=/usr/X11R6/bin/xauth path=/root/.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:29 localhost kernel: audit(1101042569.660:0): avc: denied { remove_name } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_xauth_t tcontext=root:object_r:staff_home_dir_t tclass=dir >Nov 21 08:09:29 localhost kernel: audit(1101042569.660:0): avc: denied { unlink } for pid=3095 exe=/usr/X11R6/bin/xauth name=.xauthDMglgN dev=hda3 ino=424711 scontext=user_u:user_r:user_xauth_t tcontext=user_u:object_r:staff_home_dir_t tclass=file >Nov 21 08:09:30 localhost kernel: audit(1101042570.492:0): avc: denied { connectto } for pid=3096 exe=/usr/bin/python path=/tmp/.X11-unix/X0 scontext=root:sysadm_r:sysadm_t tcontext=user_u:user_r:user_xserver_t tclass=unix_stream_socket >Nov 21 08:09:35 localhost kernel: audit(1101042575.295:0): avc: denied { unix_read unix_write } for pid=2910 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm >Nov 21 08:09:35 localhost kernel: audit(1101042575.295:0): avc: denied { read write } for pid=2910 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm >Nov 21 08:09:35 localhost kernel: audit(1101042575.295:0): avc: denied { use } for pid=2910 path=/SYSV00000000 (deleted) dev=tmpfs ino=557072 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=fd >Nov 21 08:09:35 localhost kernel: audit(1101042575.295:0): avc: denied { read write } for pid=2910 path=/SYSV00000000 (deleted) dev=tmpfs ino=557072 scontext=user_u:user_r:user_xserver_t tcontext=root:object_r:sysadm_tmpfs_t tclass=file >Nov 21 08:09:35 localhost kernel: audit(1101042575.295:0): avc: denied { getattr associate } for pid=2910 exe=/usr/X11R6/bin/Xorg key=0 scontext=user_u:user_r:user_xserver_t tcontext=root:sysadm_r:sysadm_t tclass=shm > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From cra at WPI.EDU Sun Nov 21 16:08:43 2004 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 21 Nov 2004 11:08:43 -0500 Subject: installation of selinux on non-selinux system In-Reply-To: <41A0B857.2090200@redhat.com> References: <419FF545.3080904@insight.rr.com> <41A02203.2040503@redhat.com> <41A09AD8.20203@insight.rr.com> <41A0B857.2090200@redhat.com> Message-ID: <20041121160843.GA810@angus.ind.WPI.EDU> On Sun, Nov 21, 2004 at 10:46:31AM -0500, Daniel J Walsh wrote: > I have changed selinux-policy-targeted to require policycoreutils so it > will be pulled in in the future. How about a comps.xml group called 'SELinux' so you can: yum groupinstall 'SELinux' From himainu-ynakam at miomio.jp Sun Nov 21 23:11:15 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Sun, 21 Nov 2004 18:11:15 -0500 Subject: SELinux/httpd integration In-Reply-To: <419A64A5.9010302@redhat.com> References: <419A64A5.9010302@redhat.com> Message-ID: <200411212312.iALNBwBo024647@mms-r00.iijmio.jp> Daniel J Walsh wrote: > >audit(1100636258.341:0): avc: denied { write } for pid=21318 > >exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 > >scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file > Policy has been updated to allow this. Please update to > selinux-policy-targeted-1.17.30-2.26 or greater. I looked selinux-policy-strict|targeted-sources-1.19.4-1, and found following statements. if (httpd_enable_cgi && httpd_unified ) { ... allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; .. } I think it is allowing too much. It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents". Separete boolean like "httpd_content_writable" should be prepared. # I am not sure the name is good.. And I think, like "httpd_sys_script_rw_t", "httpd_rw_t" would be useful in using PHP(such as wiki,xoops). Users can allow write permission only by modifying types. Please look at attached diffs. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/ -------------- next part -------------- A non-text attachment was scrubbed... Name: apache_macros.te.diff Type: application/octet-stream Size: 820 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: apache.te.diff Type: application/octet-stream Size: 599 bytes Desc: not available URL: From jim-cornette at insight.rr.com Mon Nov 22 01:26:26 2004 From: jim-cornette at insight.rr.com (Jim Cornette) Date: Sun, 21 Nov 2004 20:26:26 -0500 Subject: installation of selinux on non-selinux system In-Reply-To: <41A0B857.2090200@redhat.com> References: <419FF545.3080904@insight.rr.com> <41A02203.2040503@redhat.com> <41A09AD8.20203@insight.rr.com> <41A0B857.2090200@redhat.com> Message-ID: <41A14042.5020502@insight.rr.com> Daniel J Walsh wrote: >> >> Selinux gives sort of a working system when using >> system-config-securitylevel to enable selinux via the gui.(without >> policycoreutils being installed) I am not too sure if this would >> introduce "dep hell" if having policycoreutils pulled in when >> selinux-policy for targeted or strict is pulled from a repo. >> > I have changed selinux-policy-targeted to require policycoreutils so > it will be pulled in in the future. Secondly from the looks of it you > are running strict policy. Please either run > system-config-securitylevel and select targeted policy and reboot. > (/.autorelabel) should be created and > or you can edit /etc/selinux/config and change SELINUXTYPE=strict to > SELINUXTYPE=targeted and touch /.autorelabel then reboot. > > The init scripts will take care of relabeling. Thanks for pulling in this package when installing selinux-policy-targeted. This sounds like it will help reduce the problem with httpd and system logs not being written when installing the policy and activating selinux. I changed to targeted using system-config-securitylevel and I liked the warning that the system would relabel on next boot. Also, on the system when rebooted, I liked the warning that relabeling might take some time. Checking the log for avc errors after the system was relabled shows no avc errors. I'll keep in mind that strict policy is more current within rawhide. I was not aware that the strict policy within FC3 would not be current. Since FC3 was setup for targeted policy as default, I'll stay clear of strict policy for awhile. >> After relabeling my filesystem again in runlevel 1, I seem to get the >> same type of errors as experienced before. .mozilla related files >> seemed to be the major files that content was tried to be changed, >> when relabeling for strict. See attached avc for today. >> In order to bring up X, running setenforce 0 at a root shell was >> needed, in order to launch X successfully. If there is some >> lingering config file, either systemwide or hanging out in the per >> user directory that is blocking X, I don't know. >> > The strict policy you are running 1.17.30 is way out of date. If you > want to run strict policy you need to grab the one off of Rawhide or > my people page and update and relabel. Upgrades from not SELinux > boxes are not supported for SELinux for the simple reason that > relabeling is required. So your machine ended up in a rather strange > state. > I have another computer with rawhide repositories. I'll try strict on this system later on down the road. Rawhide was a little bit mongrelized on the day after FC3 came out. In a week, it might be a little more in tune. Regarding the need for relabeling being a roadblock for non-selinux systems. It might allow the system to choose this at either anaconda for install, but not activate selinux until either questions at firstboot or when selecting policy from s-c-securitylevel. Thanks for the helpful information. Jim >> Dan >> -- A prohibitionist is the sort of man one wouldn't care to drink with -- even if he drank. -- H.L. Mencken From dwalsh at redhat.com Mon Nov 22 15:03:14 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Nov 2004 10:03:14 -0500 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <104149609.1092487211@[10.11.52.51]> References: <104149609.1092487211@[10.11.52.51]> Message-ID: <41A1FFB2.9060909@redhat.com> Bill McCarty wrote: > Hi all, > > I've run into an architectural headache that someone else must already > have visited, and perhaps solved. But, I find no mention of the > problem in list archives or elsewhere. > > I have several Python scripts that run under Cron. Some of these > scripts access or modify sensitive data, and so I'd like to define one > or more domains by means of which to limit their privileges. However, > the exe name associated with such scripts is /usr/bin/python2.3, > rather than the name of the script. Consistent with the principle of > least privilege, I'd prefer to define distinct domains for each > script, rather than an overly broad python_t domain, for instance. > > Has anyone else been here already? What techniques are useful for > constraining the privileges given to scripts? > Instead of running python script Change script to start with #! /usr/bin/python And you can set context on the script > One idea: Would it be a good thing to modify Run-parts to transition > to a domain named for the Cron script it launches? Doing so would seem > to solve my problem, but it might create others . > > Thanks, > From walters at redhat.com Mon Nov 22 18:05:53 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 22 Nov 2004 13:05:53 -0500 Subject: SELinux/httpd integration In-Reply-To: <200411212312.iALNBwBo024647@mms-r00.iijmio.jp> References: <419A64A5.9010302@redhat.com> <200411212312.iALNBwBo024647@mms-r00.iijmio.jp> Message-ID: <1101146753.28164.12.camel@nexus.verbum.private> On Sun, 2004-11-21 at 18:11 -0500, Yuichi Nakamura wrote: > Daniel J Walsh wrote: > > >audit(1100636258.341:0): avc: denied { write } for pid=21318 > > >exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 > > >scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file > > Policy has been updated to allow this. Please update to > > selinux-policy-targeted-1.17.30-2.26 or greater. > > I looked selinux-policy-strict|targeted-sources-1.19.4-1, > and found following statements. > if (httpd_enable_cgi && httpd_unified ) { > ... > allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; > .. > } > > I think it is allowing too much. You think the boolean should not exist? Or just think it should grant fewer permissions? > It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents". My hope is that anyone who wants to do SELinux/Apache work on Fedora will either 1) Read the Fedora Apache/SELinux guide, where this is documented 2) Understand enough about SELinux to understand what the union of a permission set means. > Separete boolean like "httpd_content_writable" should be prepared. > # I am not sure the name is good.. A different boolean? I don't think that's all that useful because most users will either: 1) Want CGI scripts to execute as well 2) Understand enough about labeling to turn the boolean off and label things with the stronger types (httpd_sys_script_exec_t, httpd_sys_script_rw_t). > And I think, like "httpd_sys_script_rw_t", > "httpd_rw_t" would be useful in using PHP(such as wiki,xoops). > Users can allow write permission only by modifying types. Well, this is certainly arguable, but my feeling is that the current default Fedora Apache policy configuration hits a kind of sweet spot where a lot of things should be able to work out of the box, without users having to necessarily understand "chcon". If every user, even one just serving static files or doing simple CGI scripts had to learn about relabeling, we might have more users turning the Apache enforcement off. In the future though, once FC3 and experience with SELinux has percolated into the experience of the general community, we have better documentation, etc., we could consider turning the httpd_unified boolean off by default for FC4. From himainu-ynakam at miomio.jp Mon Nov 22 22:30:58 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 22 Nov 2004 17:30:58 -0500 Subject: SELinux/httpd integration In-Reply-To: <1101146753.28164.12.camel@nexus.verbum.private> References: <1101146753.28164.12.camel@nexus.verbum.private> Message-ID: <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> Colin Walters wrote: > On Sun, 2004-11-21 at 18:11 -0500, Yuichi Nakamura wrote: > > Daniel J Walsh wrote: > > > >audit(1100636258.341:0): avc: denied { write } for pid=21318 > > > >exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 > > > >scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file > > > Policy has been updated to allow this. Please update to > > > selinux-policy-targeted-1.17.30-2.26 or greater. > > > > I looked selinux-policy-strict|targeted-sources-1.19.4-1, > > and found following statements. > > if (httpd_enable_cgi && httpd_unified ) { > > ... > > allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; > > .. > > } > > > > I think it is allowing too much. > You think the boolean should not exist? Or just think it should grant > fewer permissions? I think it should grant fewer permissions. Why httpd_t should write all contents in httpd_unified ? In my understanding, "httpd_unified" means unifying domain transition's entry points of CGI. So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) ??http://www.selinux.gr.jp/ From dwalsh at redhat.com Mon Nov 22 22:37:12 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Nov 2004 17:37:12 -0500 Subject: SELinux/httpd integration In-Reply-To: <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> Message-ID: <41A26A18.9090707@redhat.com> Our view of httpd_unified, is allow all httpd executables to have full access to all httpd content. So we are locking up apache to only change apache, but not preventing parts of apache from effecting other parts. From himainu-ynakam at miomio.jp Mon Nov 22 22:42:18 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Mon, 22 Nov 2004 17:42:18 -0500 Subject: SELinux/httpd integration In-Reply-To: <41A26A18.9090707@redhat.com> References: <41A26A18.9090707@redhat.com> Message-ID: <200411222242.iAMMgQ9r005991@mms-r00.iijmio.jp> Daniel J Walsh wrote: > Our view of httpd_unified, is allow all httpd executables to have full > access to all httpd content. So we are locking up apache to only change > apache, but not preventing parts of apache from effecting other parts. Thank you. I think it is a big change, notifying users meaning of httpd_unified will become more important. From Valdis.Kletnieks at vt.edu Mon Nov 22 22:57:27 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 22 Nov 2004 17:57:27 -0500 Subject: SELinux/httpd integration In-Reply-To: Your message of "Mon, 22 Nov 2004 13:05:53 EST." <1101146753.28164.12.camel@nexus.verbum.private> References: <419A64A5.9010302@redhat.com> <200411212312.iALNBwBo024647@mms-r00.iijmio.jp> <1101146753.28164.12.camel@nexus.verbum.private> Message-ID: <200411222257.iAMMvRdY016479@turing-police.cc.vt.edu> On Mon, 22 Nov 2004 13:05:53 EST, Colin Walters said: > > It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents". > > My hope is that anyone who wants to do SELinux/Apache work on Fedora > will either > 1) Read the Fedora Apache/SELinux guide, where this is documented > 2) Understand enough about SELinux to understand what the union of a > permission set means. Idiot me - at first glance, I assumed that 'httpd_unified' was the policy file that allowed for differences in file locations across Fedora/debian/gentoo. ;) Yes, I know what the union of a permission set is (at least when I've had enough caffeine - but didn't see that "unified" referred to a union of permission sets.... Yuichi is correct - it's not an incredibly intuitive name. And remember that a *lot* of people will be installing SELinux under future Fedora Core and RHEL releases who are *NOT* SELinux experts - they will know "I'm running SELinux, and I have these services, so I need to install the policies they need" - and that's the limit of their in-depth understanding... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From walters at redhat.com Mon Nov 22 22:59:10 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 22 Nov 2004 17:59:10 -0500 Subject: SELinux/httpd integration In-Reply-To: <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> Message-ID: <1101164350.21584.15.camel@nexus.verbum.private> On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote: > I think it should grant fewer permissions. > Why httpd_t should write all contents in httpd_unified ? Ah, I see what you're saying now. Right. Dan added that recently for PHP scripts, I believe. > So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified. I agree now. Conceptually they are separate things. A new boolean like httpd_content_writable sounds good to me. Sorry about misunderstanding you originally. What do you think, Dan? From walters at redhat.com Mon Nov 22 23:01:24 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 22 Nov 2004 18:01:24 -0500 Subject: SELinux/httpd integration In-Reply-To: <1101164350.21584.15.camel@nexus.verbum.private> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> <1101164350.21584.15.camel@nexus.verbum.private> Message-ID: <1101164484.21584.18.camel@nexus.verbum.private> On Mon, 2004-11-22 at 17:59 -0500, Colin Walters wrote: > On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote: > > > I think it should grant fewer permissions. > > Why httpd_t should write all contents in httpd_unified ? > > Ah, I see what you're saying now. Right. Dan added that recently for > PHP scripts, I believe. > > > So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified. > > I agree now. Conceptually they are separate things. A new boolean like > httpd_content_writable sounds good to me. Sorry about misunderstanding > you originally. Maybe "httpd_can_write_content" to give it a more active name. From walters at redhat.com Tue Nov 23 00:15:03 2004 From: walters at redhat.com (Colin Walters) Date: Mon, 22 Nov 2004 19:15:03 -0500 Subject: SELinux/httpd integration In-Reply-To: <41A26A18.9090707@redhat.com> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> <41A26A18.9090707@redhat.com> Message-ID: <1101168903.21584.45.camel@nexus.verbum.private> On Mon, 2004-11-22 at 17:37 -0500, Daniel J Walsh wrote: > Our view of httpd_unified, is allow all httpd executables to have full > access to all httpd content. Hm. Well, this changes the scenarios in the Apache guide. The guide had assumed that if you turned off httpd_enable_cgi, then httpd_t couldn't change any files in the static file serving case. That's not true if httpd_unified stays the way it is. I guess what's kind of throwing a wrench into this whole thing is PHP, since it runs in-process. So broadly there are two cases: 1) Without PHP/mod_python/etc., but using specific CGI scripts 2) With PHP/mod_python/etc. Perhaps then what we want is a boolean to distinguish between these cases, say httpd_builtin_scripting. When httpd_builtin_scripting is enabled, we grant to httpd_t all the permissions that we were granting to CGI scripts. We keep httpd_unified, and it means the same thing it meant before: that httpd_sys_content_t is equivalent to httpd_sys_script_rw_t and httpd_sys_script_exec_t. Then if you enable both httpd_builtin_scripting and httpd_unified, your Apache setup will likely work with most crazy PHP apps. They'll be able to read/write all of the content. The case of static files and external CGI scripts works with httpd_unified enabled and httpd_builtin_scripting disabled. And finally, the static file serving case works well with httpd_builtin_scripting and httpd_enable_cgi disabled. Does that make sense? Incidentally, why do we have httpd_php_t? It looks rather vestigial. From russell at coker.com.au Tue Nov 23 00:48:00 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 23 Nov 2004 11:48:00 +1100 Subject: Domains, interpreted languages, and Cron scripts In-Reply-To: <41A1FFB2.9060909@redhat.com> References: <104149609.1092487211@[10.11.52.51]> <41A1FFB2.9060909@redhat.com> Message-ID: <200411231148.02529.russell@coker.com.au> On Tuesday 23 November 2004 02:03, Daniel J Walsh wrote: > Instead of running > python script > > Change script to start with > #! /usr/bin/python > > And you can set context on the script This also saves space on the command-line. Replacing "python script" with "script" makes the command easier to read which is a good idea even when not using SE Linux. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Tue Nov 23 04:11:25 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 23 Nov 2004 15:11:25 +1100 Subject: kudzu (kmodule) and /dev/zero: latest rawhide issues.... In-Reply-To: <4c4ba15304110808406094d287@mail.gmail.com> References: <4c4ba15304110808406094d287@mail.gmail.com> Message-ID: <200411231511.26805.russell@coker.com.au> On Tuesday 09 November 2004 03:40, Tom London wrote: > Adding > allow kudzu_t memory_device_t:chr_file { read write }; > produces > > /usr/bin/checkpolicy: loading policy configuration from policy.conf > security: 5 users, 6 roles, 1323 types, 31 bools > security: 53 classes, 313479 rules > assertion on line 269956 violated by allow kudzu_t > memory_device_t:chr_file { read write }; "head -269956 policy.conf |tail -1" gives the following: neverallow { domain -privmem } memory_device_t:{ chr_file blk_file } { read write append }; The solution is to add the privmem attribute to the declaration of kudzu_t: daemon_base_domain(kudzu, `, etc_writer, privmodule, sysctl_kernel_writer, fs_domain, privmem') -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at gmail.com Tue Nov 23 14:12:15 2004 From: selinux at gmail.com (Tom London) Date: Tue, 23 Nov 2004 06:12:15 -0800 Subject: kudzu (kmodule) and /dev/zero: latest rawhide issues.... In-Reply-To: <200411231511.26805.russell@coker.com.au> References: <4c4ba15304110808406094d287@mail.gmail.com> <200411231511.26805.russell@coker.com.au> Message-ID: <4c4ba153041123061279b3c25a@mail.gmail.com> On Tue, 23 Nov 2004 15:11:25 +1100, Russell Coker wrote: > "head -269956 policy.conf |tail -1" gives the following: > neverallow { domain -privmem } memory_device_t:{ chr_file blk_file } { read > write append }; > > The solution is to add the privmem attribute to the declaration of kudzu_t: > daemon_base_domain(kudzu, `, etc_writer, privmodule, sysctl_kernel_writer, > fs_domain, privmem') > Thanks, but this seems not to quite get it all: Nov 23 06:05:21 fedora kernel: audit(1101189873.496:0): avc: denied { execute } for pid=824 path=/dev/zero dev=tmpfs ino=3517 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:zero_device_t tclass=chr_file Nov 23 06:05:21 fedora kernel: audit(1101189873.497:0): avc: denied { execute } for pid=824 path=/dev/zero dev=tmpfs ino=3517 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:zero_device_t tclass=chr_file Is this mmap() again? tom -- Tom London From jorton at redhat.com Tue Nov 23 15:48:22 2004 From: jorton at redhat.com (Joe Orton) Date: Tue, 23 Nov 2004 15:48:22 +0000 Subject: SELinux/httpd integration In-Reply-To: <1101164350.21584.15.camel@nexus.verbum.private> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> <1101164350.21584.15.camel@nexus.verbum.private> Message-ID: <20041123154822.GA911@redhat.com> On Mon, Nov 22, 2004 at 05:59:10PM -0500, Colin Walters wrote: > On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote: > > > I think it should grant fewer permissions. > > Why httpd_t should write all contents in httpd_unified ? > > Ah, I see what you're saying now. Right. Dan added that recently for > PHP scripts, I believe. > > > So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified. > > I agree now. Conceptually they are separate things. A new boolean like > httpd_content_writable sounds good to me. Sorry about misunderstanding > you originally. But this is boolean is going to be on by default? I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it (currently :) works out-of-the-box: is the terminology "labelled with a context" correct? # # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. # From kwade at redhat.com Tue Nov 23 23:32:06 2004 From: kwade at redhat.com (Karsten Wade) Date: Tue, 23 Nov 2004 15:32:06 -0800 Subject: SELinux/httpd integration In-Reply-To: <20041123154822.GA911@redhat.com> References: <1101146753.28164.12.camel@nexus.verbum.private> <200411222231.iAMMV59r005629@mms-r00.iijmio.jp> <1101164350.21584.15.camel@nexus.verbum.private> <20041123154822.GA911@redhat.com> Message-ID: <1101252726.16858.5910.camel@erato.phig.org> On Tue, 2004-11-23 at 07:48, Joe Orton wrote: > I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it > (currently :) works out-of-the-box: is the terminology "labelled with a > context" correct? Yes. > # > # Example configuration to enable HTTP access for a directory > # containing Subversion repositories, "/var/www/svn". Each repository > # must be readable and writable by the 'apache' user. Note that if > # SELinux is enabled, the repositories must be labelled with a context > # which httpd can write to; this will happen by default for > # directories created in /var/www. > # Do you want to consider what to do if a user has an existing SVN repository that they want to drop into /var/www? If the directory already has SELinux xattrs and you mv or cp it to the location, it will have the wrong label. A simple 'restorecon -R /var/www' will take care of this, recursively giving /var/www/svn the parent context. - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From daz at planetnz.com Tue Nov 23 23:06:19 2004 From: daz at planetnz.com (Daryn Hanright) Date: Wed, 24 Nov 2004 12:06:19 +1300 Subject: Issue with SELinux on FC3 - No policies Message-ID: <20041123230619.GA5245@localhost.localdomain> Hi - I've experienced something weird with SeLinux. When I first installed FC3 I chose targeted & noticed loads of different options under the SELinux tab in system-config-securitylevel, basically a twisty-tie list of different apps that are targeted. But I think when I reinstalled FC3 the other day I chose to disable SELinux, and now none of those options appear. When I choose to enable, those options I first saw don't reappear. Have tried reinstalling the relevent rpm's with no luck. Anyone have any idea what might have happened, or at least some idea on how I can reconfigure it? Having had a read of the SELinux FAQ for FC3, I should see a whole range of policies in "/etc/selinux/targeted/policy/", but when I go there I see only one policy Any ideas? cheers Daryn From dwalsh at redhat.com Wed Nov 24 11:55:55 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Nov 2004 06:55:55 -0500 Subject: Issue with SELinux on FC3 - No policies In-Reply-To: <20041123230619.GA5245@localhost.localdomain> References: <20041123230619.GA5245@localhost.localdomain> Message-ID: <41A476CB.9020302@redhat.com> Daryn Hanright wrote: >Hi - I've experienced something weird with SeLinux. When I first installed >FC3 I chose targeted & noticed loads of different options under the SELinux tab >in system-config-securitylevel, basically a twisty-tie list of different apps >that are targeted. But I think when I reinstalled FC3 the other day >I chose to disable SELinux, and now none of those options appear. When I choose >to enable, those options I first saw don't reappear. Have tried reinstalling the >relevent rpm's with no luck. Anyone have any idea what might have happened, or >at least some idea on how I can reconfigure it? > >Having had a read of the SELinux FAQ for FC3, I should see a whole range of >policies in "/etc/selinux/targeted/policy/", but when I go there I see only one >policy > >Any ideas? > > > Not sure what you are asking. By default in FC3 with SELinux enabled, you get the following: rpm -q -l selinux-policy-targeted /etc/selinux/ /etc/selinux/targeted/ /etc/selinux/targeted/booleans # Booleans file containing list of overrides to policy booleans /etc/selinux/targeted/contexts/ # Contains a the context files that tell different apps how to transition to different contexts /etc/selinux/targeted/contexts/dbus_contexts /etc/selinux/targeted/contexts/default_contexts /etc/selinux/targeted/contexts/default_type /etc/selinux/targeted/contexts/failsafe_context /etc/selinux/targeted/contexts/files/ /etc/selinux/targeted/contexts/files/file_contexts # Regular expession File contexts used by restorecon, setfilescon, fixfiles to determine each files context. /etc/selinux/targeted/contexts/files/media # File contexts for special device files /etc/selinux/targeted/contexts/initrc_context /etc/selinux/targeted/contexts/removable_context /etc/selinux/targeted/contexts/userhelper_context /etc/selinux/targeted/contexts/users/ #directory contains override values for roles. IE If the root user logins in locally, give him this role. /etc/selinux/targeted/contexts/users/root /etc/selinux/targeted/policy /etc/selinux/targeted/policy/policy.18 # The actual compiled context. >> If you install selinux-policy-targeted-sources you get an additional directory tree under /etc/selinux/targeted/src/ >> If you install selinux-policy-strict you get a similar tree under /etc/selinux/strict/ >> system-config-securitylevel examines /etc/selinux/config to determine which policy is running (targeted, strict or other future ones) and whether selinux is enabled, Permissive or disabled (/usr/sbin/getenforce tells you this). system-config-securitylevel then lists all subdirectories of /etc/selinux/ as possible policies choices. In order to put up the Modify SELinux Policy listbox, the tool lists all booleans using the tool getsebool -a and if the selinux-policy-*-sources directory is installed, it examines the /etc/selinux/SELINUXTYPE/src/policy/tunables/ directory for all tunable entries. It then uses the /usr/share/system-config-securitylevel/selinux.tbl to make translate the booleans/tunables into a more descriptive representation. So depending on which policy is loaded and which policy and policy-sources are installed, the display of system-config-securitylevel will change. I hope this helps. Dan >cheers >Daryn > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From jorton at redhat.com Wed Nov 24 14:43:15 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 24 Nov 2004 14:43:15 +0000 Subject: rpm -V selinux-policy-targeted Message-ID: <20041124144315.GA31199@redhat.com> Should I expect output like this from rpm -V from a fresh install, even if I haven't touched the policy myself? [root at blane ~]# rpm -V selinux-policy-targeted .......TC c /etc/selinux/targeted/contexts/default_contexts .......TC c /etc/selinux/targeted/contexts/default_type .......TC c /etc/selinux/targeted/contexts/failsafe_context ..5....TC c /etc/selinux/targeted/contexts/files/file_contexts .......TC c /etc/selinux/targeted/contexts/files/media .......TC c /etc/selinux/targeted/contexts/initrc_context .......TC c /etc/selinux/targeted/contexts/removable_context .......TC c /etc/selinux/targeted/contexts/userhelper_context .......TC c /etc/selinux/targeted/contexts/users/root ..5....T. c /etc/selinux/targeted/policy/policy.18 Since policy/policy.18 is marked %config(noreplace) the new policy.18 file is installed as policy.18.rpmnew and hence it seems manual intervention is needed to load the new policy, it's not a simple rpm -U or up2date run away - is this desirable? joe From dwalsh at redhat.com Wed Nov 24 15:05:55 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Nov 2004 10:05:55 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <20041124144315.GA31199@redhat.com> References: <20041124144315.GA31199@redhat.com> Message-ID: <41A4A353.2060404@redhat.com> Joe Orton wrote: >Should I expect output like this from rpm -V from a fresh install, even >if I haven't touched the policy myself? > >[root at blane ~]# rpm -V selinux-policy-targeted >.......TC c /etc/selinux/targeted/contexts/default_contexts >.......TC c /etc/selinux/targeted/contexts/default_type >.......TC c /etc/selinux/targeted/contexts/failsafe_context >..5....TC c /etc/selinux/targeted/contexts/files/file_contexts >.......TC c /etc/selinux/targeted/contexts/files/media >.......TC c /etc/selinux/targeted/contexts/initrc_context >.......TC c /etc/selinux/targeted/contexts/removable_context >.......TC c /etc/selinux/targeted/contexts/userhelper_context >.......TC c /etc/selinux/targeted/contexts/users/root >..5....T. c /etc/selinux/targeted/policy/policy.18 > >Since policy/policy.18 is marked %config(noreplace) the new policy.18 >file is installed as policy.18.rpmnew and hence it seems manual >intervention is needed to load the new policy, it's not a simple rpm -U >or up2date run away - is this desirable? > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > This means that you modified the file_context/policy.18 file by using selinux-policy-targeted-sources file. The upgrade of selinux-policy-targeted-sources should do a make reload when it completes, causing the policy.18 and file_contexts file to be replaced. This way if you made local changes they will be maintained. (There was/is a bug with the moving of the /usr/bin files to /usr/sbin that is causing certain *sources rpms not to do a make load. make -C /etc/selinux/targeted/src/policy load will force a load from sources. Dan From jorton at redhat.com Wed Nov 24 16:14:43 2004 From: jorton at redhat.com (Joe Orton) Date: Wed, 24 Nov 2004 16:14:43 +0000 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4A353.2060404@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> Message-ID: <20041124161443.GA27400@redhat.com> On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote: > Joe Orton wrote: ... > >..5....T. c /etc/selinux/targeted/policy/policy.18 > > > >Since policy/policy.18 is marked %config(noreplace) the new policy.18 > >file is installed as policy.18.rpmnew and hence it seems manual > >intervention is needed to load the new policy, it's not a simple rpm -U > >or up2date run away - is this desirable? > > This means that you modified the file_context/policy.18 file by using > selinux-policy-targeted-sources file. > The upgrade of selinux-policy-targeted-sources should do a make reload > when it completes, causing the policy.18 and file_contexts file > to be replaced. This way if you made local changes they will be > maintained. (There was/is a bug with the moving of the /usr/bin files > to /usr/sbin that is causing certain *sources rpms not to do a make load. No, I didn't make any local changes, I haven't touched the files, this was on a fresh kickstart. Ah, it looks like the %post script for selinux-policy-targeted-sources will reload the policy the first time it's installed too, i.e. by anaconda. So it's doomed from the out. That could be changed to really only happen on upgrades, but I'd question whether -sources should automatically reload the policy at all. Getting so easily into a state where "up2date selinux-targeted-policy" doesn't automatically apply policy updates (given no local modifications to the sources) is bad. joe From dwalsh at redhat.com Wed Nov 24 16:40:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Nov 2004 11:40:11 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <20041124161443.GA27400@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> Message-ID: <41A4B96B.1060706@redhat.com> Joe Orton wrote: >On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote: > > >>Joe Orton wrote: >> >> >... > > >>>..5....T. c /etc/selinux/targeted/policy/policy.18 >>> >>>Since policy/policy.18 is marked %config(noreplace) the new policy.18 >>>file is installed as policy.18.rpmnew and hence it seems manual >>>intervention is needed to load the new policy, it's not a simple rpm -U >>>or up2date run away - is this desirable? >>> >>> >>This means that you modified the file_context/policy.18 file by using >>selinux-policy-targeted-sources file. >>The upgrade of selinux-policy-targeted-sources should do a make reload >>when it completes, causing the policy.18 and file_contexts file >>to be replaced. This way if you made local changes they will be >>maintained. (There was/is a bug with the moving of the /usr/bin files >>to /usr/sbin that is causing certain *sources rpms not to do a make load. >> >> > >No, I didn't make any local changes, I haven't touched the files, this >was on a fresh kickstart. Ah, it looks like the %post script for >selinux-policy-targeted-sources will reload the policy the first time >it's installed too, i.e. by anaconda. So it's doomed from the out. > >That could be changed to really only happen on upgrades, but I'd >question whether -sources should automatically reload the policy at all. >Getting so easily into a state where "up2date selinux-targeted-policy" >doesn't automatically apply policy updates (given no local modifications >to the sources) is bad. > > > Ok we can turn off automatic update of policy from selinux-policy-*sources, but then the user will need to manually update the policy if he has manipulated it. >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From n3npq at nc.rr.com Wed Nov 24 17:11:15 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 24 Nov 2004 12:11:15 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4B96B.1060706@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> Message-ID: <41A4C0B3.30008@nc.rr.com> Daniel J Walsh wrote: > Joe Orton wrote: > >> On Wed, Nov 24, 2004 at 10:05:55AM -0500, Daniel J Walsh wrote: >> >> >>> Joe Orton wrote: >>> >> >> ... >> >> >>>> ..5....T. c /etc/selinux/targeted/policy/policy.18 >>>> >>>> Since policy/policy.18 is marked %config(noreplace) the new policy.18 >>>> file is installed as policy.18.rpmnew and hence it seems manual >>>> intervention is needed to load the new policy, it's not a simple >>>> rpm -U >>>> or up2date run away - is this desirable? >>>> >>> >>> This means that you modified the file_context/policy.18 file by >>> using selinux-policy-targeted-sources file. >>> The upgrade of selinux-policy-targeted-sources should do a make >>> reload when it completes, causing the policy.18 and file_contexts file >>> to be replaced. This way if you made local changes they will be >>> maintained. (There was/is a bug with the moving of the /usr/bin files >>> to /usr/sbin that is causing certain *sources rpms not to do a make >>> load. >>> >> >> >> No, I didn't make any local changes, I haven't touched the files, this >> was on a fresh kickstart. Ah, it looks like the %post script for >> selinux-policy-targeted-sources will reload the policy the first time >> it's installed too, i.e. by anaconda. So it's doomed from the out. >> >> That could be changed to really only happen on upgrades, but I'd >> question whether -sources should automatically reload the policy at >> all. Getting so easily into a state where "up2date >> selinux-targeted-policy" >> doesn't automatically apply policy updates (given no local modifications >> to the sources) is bad. >> >> >> > Ok we can turn off automatic update of policy from > selinux-policy-*sources, but then > the user will need to manually update the policy if he has manipulated > it. A more seamless mechanism to upgrade policy is gonna be needed eventually. I know of several problem areas, ready to attempt better upgrade if/when you are, if you wish to attempt through rpm. A distribution mechanism outside rpm is a quite sane alternative implementation as well. 73 de Jeff From aoliva at redhat.com Wed Nov 24 18:53:18 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Nov 2004 16:53:18 -0200 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4B96B.1060706@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> Message-ID: On Nov 24, 2004, Daniel J Walsh wrote: > Ok we can turn off automatic update of policy from > selinux-policy-*sources, but then > the user will need to manually update the policy if he has manipulated it. Can't we find a middle ground, like: update policy automatically if there have been changes, and leave it alone otherwise since the non-sources policy update will have already taken care of it? -- Alexandre Oliva http://www.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 dwalsh at redhat.com Wed Nov 24 18:55:37 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Nov 2004 13:55:37 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> Message-ID: <41A4D929.9060309@redhat.com> Alexandre Oliva wrote: >On Nov 24, 2004, Daniel J Walsh wrote: > > > >>Ok we can turn off automatic update of policy from >>selinux-policy-*sources, but then >>the user will need to manually update the policy if he has manipulated it. >> >> > >Can't we find a middle ground, like: update policy automatically if >there have been changes, and leave it alone otherwise since the >non-sources policy update will have already taken care of it? > > > Sure, but how can I tell in the post install section of the sources package? Dan From n3npq at nc.rr.com Wed Nov 24 19:03:48 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 24 Nov 2004 14:03:48 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4D929.9060309@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> <41A4D929.9060309@redhat.com> Message-ID: <41A4DB14.5090101@nc.rr.com> Daniel J Walsh wrote: > Alexandre Oliva wrote: > >> On Nov 24, 2004, Daniel J Walsh wrote: >> >> >> >>> Ok we can turn off automatic update of policy from >>> selinux-policy-*sources, but then >>> the user will need to manually update the policy if he has >>> manipulated it. >>> >> >> >> Can't we find a middle ground, like: update policy automatically if >> there have been changes, and leave it alone otherwise since the >> non-sources policy update will have already taken care of it? >> >> >> > Sure, but how can I tell in the post install section of the sources > package? One way is for rpm to supply a hint, like an envvar, based on a more global context than available in %post. However the hack would need some design. Hint: I'd look seriously at using %post -p if I were you, there is a global and persistent variable space that shares state with rpm that will be much more convenient than impedance matching through envvar's. 73 de Jeff From dwalsh at redhat.com Wed Nov 24 20:39:11 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Nov 2004 15:39:11 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4DB14.5090101@nc.rr.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> <41A4D929.9060309@redhat.com> <41A4DB14.5090101@nc.rr.com> Message-ID: <41A4F16F.4020402@redhat.com> How about something like the following. if [ -x /usr/sbin/selinuxenabled -a -f /etc/selinux/config ]; then . /etc/selinux/config POLICYFILE=/etc/selinux/%{type}/policy/policy.18 RPMPOLICYFILE=$POLICYFILE.rpmnew if [ "${SELINUXTYPE}" = "%{type}" -a /usr/sbin/selinuxenabled -a \ -e $RPMPOLICYFILE -a \ $RPMPOLICYFILE -nt $POLICYFILE ]; then diff -q $RPMPOLICYFILE $POLICYFILE > /dev/null || make -C /etc/selinux/%{type}/src/policy load > /dev/null 2>&1 fi fi From n3npq at nc.rr.com Wed Nov 24 21:13:05 2004 From: n3npq at nc.rr.com (Jeff Johnson) Date: Wed, 24 Nov 2004 16:13:05 -0500 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4F16F.4020402@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> <41A4D929.9060309@redhat.com> <41A4DB14.5090101@nc.rr.com> <41A4F16F.4020402@redhat.com> Message-ID: <41A4F961.9030206@nc.rr.com> Daniel J Walsh wrote: > How about something like the following. > > if [ -x /usr/sbin/selinuxenabled -a -f /etc/selinux/config ]; then > . /etc/selinux/config > POLICYFILE=/etc/selinux/%{type}/policy/policy.18 > RPMPOLICYFILE=$POLICYFILE.rpmnew > if [ "${SELINUXTYPE}" = "%{type}" -a /usr/sbin/selinuxenabled -a \ > -e $RPMPOLICYFILE -a \ > $RPMPOLICYFILE -nt $POLICYFILE ]; then > diff -q $RPMPOLICYFILE $POLICYFILE > /dev/null || > make -C /etc/selinux/%{type}/src/policy load > /dev/null 2>&1 > fi > fi *.rpmnew exists iff the original file was locally modified wrto the md5 contained within the old package metadata is what to watch out for. Left over *.rpmnew can/will exist from previous upgrades, nuking *.rpmnew is recommended and perhaps will simplify some logic, and avoid clock skew issues. inter-package existence tests like "-x /usr/sbin/selinuxenabled" are tricky because when and where the scriptlet is run needs to be considered. You might just as well add a Requires: and rely on the transaction being ordered correctly, that is likelier to work predictably, and is a simpler script to write. The whole scheme assumes that ${SELINUXTYPE} changes rarely, but wot's a girl to do? HTH Isn't rpm annoying? ;-) 73 de Jeff From kwade at redhat.com Wed Nov 24 23:47:47 2004 From: kwade at redhat.com (Karsten Wade) Date: Wed, 24 Nov 2004 15:47:47 -0800 Subject: init labeling question for targeted policy Message-ID: <1101340066.16858.7497.camel@erato.phig.org> My question about the targeted policy presumes that init re-execs itself after loading the policy, whereby it picks up the unconfined_t domain from the policy, as defined by a rule in /etc/selinux/targeted/src/policy/domains/unconfined.te. role system_r types unconfined_t; What rule tells init to re-exec itself in the targeted policy? Or is init doing something differently now? Here is how far I've gotten in figuring this out. In the strict policy there is an explicit transition rule for init. The file programs/misc/kernel.te has this rule: domain_auto_trans(kernel_t, init_exec_t, init_t) In the targeted policy, kernel.te is in domains/misc/unused, so is not called into play. Correct? The transition behavior certainly isn't used, i.e., init transitions to unconfined_t instead of init_t. Therefore, I'm looking for a default behavior that init falls back on since it doesn't have specific SELinux coverage. In macros/global_macros.te the macro domain_auto_trans(init_t, $1_exec_t, $1_t) is defined. However, I don't find that macro used, i.e., domain_auto_trans(init_t) or somesuch. In addition, I'm not even sure that init would be in the domain init_t to qualify for this macro since in targeted it's in unconfined_t. In define(`unconfined_domain', there is this rule: allow $1 self:process transition; That says that init is allowed to transition to itself, but it doesn't tell init to do the transition and seems otherwise unrelated. Which one of these paths, if any, is leading in the right direction? thx - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From himainu-ynakam at miomio.jp Thu Nov 25 01:58:04 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Wed, 24 Nov 2004 20:58:04 -0500 Subject: SELinux/httpd integration In-Reply-To: <20041123154822.GA911@redhat.com> References: <20041123154822.GA911@redhat.com> Message-ID: <200411250158.iAP1w94L008964@mms-r01.iijmio.jp> Joe Orton wrote: > I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it > (currently :) works out-of-the-box: is the terminology "labelled with a > context" correct? > # > # Example configuration to enable HTTP access for a directory > # containing Subversion repositories, "/var/www/svn". Each repository > # must be readable and writable by the 'apache' user. Note that if > # SELinux is enabled, the repositories must be labelled with a context > # which httpd can write to; this will happen by default for > # directories created in /var/www. > # As far as I know, context writable by httpd is not prepared. So I think type like httpd_rw_t I suggested before will be necessary. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/ From walters at redhat.com Thu Nov 25 05:28:43 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 25 Nov 2004 00:28:43 -0500 Subject: init labeling question for targeted policy In-Reply-To: <1101340066.16858.7497.camel@erato.phig.org> References: <1101340066.16858.7497.camel@erato.phig.org> Message-ID: <1101360523.1543.53.camel@nexus.verbum.private> On Wed, 2004-11-24 at 15:47 -0800, Karsten Wade wrote: > My question about the targeted policy presumes that init re-execs itself > after loading the policy, whereby it picks up the unconfined_t domain > from the policy, as defined by a rule in > /etc/selinux/targeted/src/policy/domains/unconfined.te. > > role system_r types unconfined_t; This just authorizes a role for a type, it doesn't define anything related to init. > What rule tells init to re-exec itself in the targeted policy? Nothing in the policy tells init to re-exec itself; the code just does it. Do you mean, how does init get the unconfined_t type? See: > In the strict policy there is an explicit transition rule for init. The > file programs/misc/kernel.te has this rule: > > domain_auto_trans(kernel_t, init_exec_t, init_t) > > In the targeted policy, kernel.te is in domains/misc/unused, so is not > called into play. Correct? Well, kernel_t is actually an alias for init_t in targeted policy, according to apol. The kernel starts out as unconfined_t, in my reading of initial_sid_contexts: sid kernel user_u:system_r:unconfined_t Thus there is no transition at all in targeted policy. From jorton at redhat.com Thu Nov 25 09:24:04 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 25 Nov 2004 09:24:04 +0000 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4F16F.4020402@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> <41A4D929.9060309@redhat.com> <41A4DB14.5090101@nc.rr.com> <41A4F16F.4020402@redhat.com> Message-ID: <20041125092404.GA19702@redhat.com> On Wed, Nov 24, 2004 at 03:39:11PM -0500, Daniel J Walsh wrote: > How about something like the following. Why not just have the Makefile touch some file as a side-effect of loading a modified policy, and then the %post script for -sources can automatically reload policy in %post run iff that file exists? joe From jorton at redhat.com Thu Nov 25 09:47:46 2004 From: jorton at redhat.com (Joe Orton) Date: Thu, 25 Nov 2004 09:47:46 +0000 Subject: SELinux/httpd integration In-Reply-To: <200411250158.iAP1w94L008964@mms-r01.iijmio.jp> References: <20041123154822.GA911@redhat.com> <200411250158.iAP1w94L008964@mms-r01.iijmio.jp> Message-ID: <20041125094746.GA20905@redhat.com> On Wed, Nov 24, 2004 at 08:58:04PM -0500, Yuichi Nakamura wrote: > Joe Orton wrote: > > I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it > > (currently :) works out-of-the-box: is the terminology "labelled with a > > context" correct? > > # > > # Example configuration to enable HTTP access for a directory > > # containing Subversion repositories, "/var/www/svn". Each repository > > # must be readable and writable by the 'apache' user. Note that if > > # SELinux is enabled, the repositories must be labelled with a context > > # which httpd can write to; this will happen by default for > > # directories created in /var/www. > > # > > As far as I know, context writable by httpd is not prepared. > So I think type like httpd_rw_t I suggested before will be necessary. With the current policy, system_u:object_r:httpd_sys_content_t *is* writable by httpd_t by default. If this changes or is going to change this text will need to be updated, yup. joe From gandharv at fastmail.fm Thu Nov 25 11:14:56 2004 From: gandharv at fastmail.fm (gandharv at fastmail.fm) Date: Thu, 25 Nov 2004 16:44:56 +0530 Subject: test Message-ID: <20041125160447.GAb6505.vikram@comp1.prvnet.com> test -- From aoliva at redhat.com Thu Nov 25 19:05:00 2004 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Nov 2004 17:05:00 -0200 Subject: rpm -V selinux-policy-targeted In-Reply-To: <41A4D929.9060309@redhat.com> References: <20041124144315.GA31199@redhat.com> <41A4A353.2060404@redhat.com> <20041124161443.GA27400@redhat.com> <41A4B96B.1060706@redhat.com> <41A4D929.9060309@redhat.com> Message-ID: On Nov 24, 2004, Daniel J Walsh wrote: > Alexandre Oliva wrote: >> On Nov 24, 2004, Daniel J Walsh wrote: >>> Ok we can turn off automatic update of policy from >>> selinux-policy-*sources, but then >>> the user will need to manually update the policy if he has manipulated it. >> Can't we find a middle ground, like: update policy automatically if >> there have been changes, and leave it alone otherwise since the >> non-sources policy update will have already taken care of it? > Sure, but how can I tell in the post install section of the sources package? One relatively simple way is to have make rules that use move-if-changed after attempting to update the policy files into a temporary name. If the policy update is a no-op, you'll keep the old timestamp and rpm won't complain any more. -- Alexandre Oliva http://www.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 parklee_sel at yahoo.com Fri Nov 26 18:50:18 2004 From: parklee_sel at yahoo.com (Park Lee) Date: Fri, 26 Nov 2004 10:50:18 -0800 (PST) Subject: Issue on getting security context of socket and message In-Reply-To: <1100014761.408.112.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20041126185018.56868.qmail@web51503.mail.yahoo.com> On Tue, 09 Nov 2004 at 10:39, Stephen Smalley wrote: > In the kernel, you can obtain the security context of a socket via the > security field of its associated inode. Look at socket_has_perm() > and selinux_socket_sock_rcv_skb() in security/selinux/hooks.c for > examples. I'm now trying to do something on integrating IPsec with SELinux. Now I need to get the security context of a socket and the socket itself. Would you please tell me further that when an outbound packet is going to be send, How can we get the struct socket itself (i.e. the socket that is related to the outbound packet. it refers that when we want to send the packet, we should first set up the socket )? And, in kernel-space, How can we transfer a SID to a security context? Is there any function can we use to achieve it? Thank you. -- Best Regards, Park Lee __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwade at redhat.com Sat Nov 27 13:03:56 2004 From: kwade at redhat.com (Karsten Wade) Date: Sat, 27 Nov 2004 05:03:56 -0800 Subject: init labeling question for targeted policy In-Reply-To: <1101360523.1543.53.camel@nexus.verbum.private> References: <1101340066.16858.7497.camel@erato.phig.org> <1101360523.1543.53.camel@nexus.verbum.private> Message-ID: <1101560636.30388.1380.camel@erato.phig.org> On Wed, 2004-11-24 at 21:28, Colin Walters wrote: > On Wed, 2004-11-24 at 15:47 -0800, Karsten Wade wrote: > > My question about the targeted policy presumes that init re-execs itself > > after loading the policy, whereby it picks up the unconfined_t domain > > from the policy, as defined by a rule in > > /etc/selinux/targeted/src/policy/domains/unconfined.te. > > > > role system_r types unconfined_t; > > This just authorizes a role for a type, it doesn't define anything > related to init. I was looking for a blanket (default) rule that covered everything not covered by policy in domains/program/*.te. > > What rule tells init to re-exec itself in the targeted policy? > > Nothing in the policy tells init to re-exec itself; the code just does > it. I got started down this pathway from this paragraph in Russell's article: from http://www.redhat.com/magazine/001nov04/features/selinux/ "After the policy is loaded every running process (only init and kernel threads as the policy is loaded early in the boot) will be assigned the security context system_u:system_r:kernel_t (NB all kernel threads started at any time will get that context). Once init has loaded the policy it will re-exec itself. The policy contains the rule domain_auto_trans(kernel_t, init_exec_t, init_t). This means that when the kernel_t domain executes a file of type init_exec_t (for example, /sbin/init) then the domain will automatically transition to init_t (the correct domain for /sbin/init). After that init does its usual job and the system boots. The kernel threads continue running as kernel_t." This doesn't describe the targeted policy, I get that. I found the domain_auto_trans in kernel.te and found kernel.te in domains/misc/unused in the targeted sources, so I drew the conclusion that the behavior of init is as Russell says but the way it gets it's context is different. > Do you mean, how does init get the unconfined_t type? See: [snip ref. to initial_sid_contexts] This was a part of my question > > > In the strict policy there is an explicit transition rule for init. The > > file programs/misc/kernel.te has this rule: > > > > domain_auto_trans(kernel_t, init_exec_t, init_t) > > > > In the targeted policy, kernel.te is in domains/misc/unused, so is not > > called into play. Correct? > > Well, kernel_t is actually an alias for init_t in targeted policy, > according to apol. >From domains/unconfined.te: typealias unconfined_t alias { kernel_t init_t initrc_t sysadm_t rpm_t rpm_script_t logrotate_t }; Obviously I need to commit a little more time with apol. :) > The kernel starts out as unconfined_t, in my reading > of initial_sid_contexts: > > sid kernel user_u:system_r:unconfined_t > > Thus there is no transition at all in targeted policy. init is started with the unconfined_t context? Was this behavior that changed between FC2 and FC3, or am I missing something fundamental here? thx - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From walters at redhat.com Sat Nov 27 17:30:44 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 27 Nov 2004 12:30:44 -0500 Subject: init labeling question for targeted policy In-Reply-To: <1101560636.30388.1380.camel@erato.phig.org> References: <1101340066.16858.7497.camel@erato.phig.org> <1101360523.1543.53.camel@nexus.verbum.private> <1101560636.30388.1380.camel@erato.phig.org> Message-ID: <1101576644.19983.8.camel@nexus.verbum.private> On Sat, 2004-11-27 at 05:03 -0800, Karsten Wade wrote: > init is started with the unconfined_t context? Was this behavior that > changed between FC2 and FC3, or am I missing something fundamental here? I think the distinction is just targeted vs. strict policy; FC2 didn't have targeted. So basically everything just starts out as unconfined, including the kernel, and then transitions happen for a few specific domains like httpd_t. For strict policy, I think it's pretty much as Russell described it. Does that answer your question? From selinux at gmail.com Sat Nov 27 19:30:39 2004 From: selinux at gmail.com (Tom London) Date: Sat, 27 Nov 2004 11:30:39 -0800 Subject: systat needs perms for proc_net_t? Message-ID: <4c4ba15304112711306cc5f56c@mail.gmail.com> Running strict/enforcing off of latest Rawhide: I get: Nov 27 11:10:01 fedora kernel: audit(1101582601.882:0): avc: denied { search } for pid=8407 exe=/usr/lib/sa/sadc name=net dev=proc ino=-268435434 scontext=system_u:system_r:sysstat_t tcontext=system_u:object_r:proc_net_t tclass=dir Nov 27 11:10:01 fedora kernel: audit(1101582601.884:0): avc: denied { search } for pid=8407 exe=/usr/lib/sa/sadc name=net dev=proc ino=-268435434 scontext=system_u:system_r:sysstat_t tcontext=system_u:object_r:proc_net_t tclass=dir every 10 minutes or so... I made the following patch to sysstat.te to add read perms for proc_net_t. That right? tom --- SAVE/sysstat.te 2004-11-27 11:19:14.988551119 -0800 +++ ./sysstat.te 2004-11-27 11:20:08.235155773 -0800 @@ -51,8 +51,8 @@ allow sysstat_t fs_t:filesystem getattr; # get info from /proc -allow sysstat_t { proc_t sysctl_kernel_t sysctl_t sysctl_fs_t sysctl_rpc_t }:dir r_dir_perms; -allow sysstat_t { proc_t sysctl_kernel_t sysctl_t sysctl_fs_t sysctl_rpc_t }:file { read getattr }; +allow sysstat_t { proc_t proc_net_t sysctl_kernel_t sysctl_t sysctl_fs_t sysctl_rpc_t }:dir r_dir_perms; +allow sysstat_t { proc_t proc_net_t sysctl_kernel_t sysctl_t sysctl_fs_t sysctl_rpc_t }:file { read getattr }; domain_auto_trans(initrc_t, sysstat_exec_t, sysstat_t) allow sysstat_t init_t:fd use; -- Tom London From kwade at redhat.com Sat Nov 27 23:56:55 2004 From: kwade at redhat.com (Karsten Wade) Date: Sat, 27 Nov 2004 15:56:55 -0800 Subject: init labeling question for targeted policy In-Reply-To: <1101576644.19983.8.camel@nexus.verbum.private> References: <1101340066.16858.7497.camel@erato.phig.org> <1101360523.1543.53.camel@nexus.verbum.private> <1101560636.30388.1380.camel@erato.phig.org> <1101576644.19983.8.camel@nexus.verbum.private> Message-ID: <1101599815.30388.2039.camel@erato.phig.org> On Sat, 2004-11-27 at 09:30, Colin Walters wrote: > On Sat, 2004-11-27 at 05:03 -0800, Karsten Wade wrote: > > > init is started with the unconfined_t context? Was this behavior that > > changed between FC2 and FC3, or am I missing something fundamental here? > > I think the distinction is just targeted vs. strict policy; FC2 didn't > have targeted. So basically everything just starts out as unconfined, > including the kernel, and then transitions happen for a few specific > domains like httpd_t. For strict policy, I think it's pretty much as > Russell described it. Does that answer your question? Almost, as we work backwards. :) When the kernel starts, it doesn't know anything about the status of SELinux until init mounts /proc and checks for the selinuxfs type. Right? Once the kernel knows that SELinux is enabled, init is coded to rexec itself under whatever default domain it has. Is that right? And the strict policy has a rule to tell make sure init doesn't come back as kernel_t but as init_t? Where the targeted policy aliases unconfined_t to a whole group that includes kernel_t and init_t. thx - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From walters at redhat.com Sun Nov 28 04:18:25 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 27 Nov 2004 23:18:25 -0500 Subject: init labeling question for targeted policy In-Reply-To: <1101599815.30388.2039.camel@erato.phig.org> References: <1101340066.16858.7497.camel@erato.phig.org> <1101360523.1543.53.camel@nexus.verbum.private> <1101560636.30388.1380.camel@erato.phig.org> <1101576644.19983.8.camel@nexus.verbum.private> <1101599815.30388.2039.camel@erato.phig.org> Message-ID: <1101615505.2360.11.camel@nexus.verbum.private> On Sat, 2004-11-27 at 15:56 -0800, Karsten Wade wrote: > When the kernel starts, it doesn't know anything about the status of > SELinux until init mounts /proc and checks for the selinuxfs type. > Right? Well, no; SELinux is enabled as far as the kernel is aware (unless selinux=0 was specified on the grub boot line), but no policy is loaded until init starts and loads it. > Once the kernel knows that SELinux is enabled, init is coded to rexec > itself under whatever default domain it has. Is that right? init reexecutes itself if it determines SELinux is enabled and loading the initial policy worked, and in the strict policy that will cause a domain transition. > And the strict policy has a rule to tell make sure init doesn't come > back as kernel_t but as init_t? Right, because of the domain_auto_trans you posted originally. > Where the targeted policy aliases unconfined_t to a whole group that > includes kernel_t and init_t. Right. From kwade at redhat.com Sun Nov 28 16:23:16 2004 From: kwade at redhat.com (Karsten Wade) Date: Sun, 28 Nov 2004 08:23:16 -0800 Subject: SELinux/httpd integration In-Reply-To: <419A64A5.9010302@redhat.com> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> <20041116203317.GB4356@redhat.com> <419A64A5.9010302@redhat.com> Message-ID: <1101658996.30388.3981.camel@erato.phig.org> On Tue, 2004-11-16 at 12:35, Daniel J Walsh wrote: > Joe Orton wrote: > > >httpd_t *cannot* write to anything labelled with httpd_sys_content_t by > >default, surely - that's the whole problem? > > Policy has been updated to allow this. Please update to > selinux-policy-targeted-1.17.30-2.26 or greater. I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail. Before I post a very long message detailing everything I did, can someone tell me how httpd_t has gained write allow for httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and recompiled policy, but still can't find the write. thx - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From selinux at gmail.com Sun Nov 28 19:51:23 2004 From: selinux at gmail.com (Tom London) Date: Sun, 28 Nov 2004 11:51:23 -0800 Subject: cups-config-daemon ? Message-ID: <4c4ba153041128115177c696b8@mail.gmail.com> Running strict/enforcing, latest Rawhide. I think the following is coming from cups-config-daemon I'm always a bit suspicious of fd denials.... these are to /dev/null... Is this an open file leaking across an exec? Help welcomed..... tom Nov 28 10:12:25 fedora cups: cupsd shutdown succeeded Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs ino=3516 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:system_crond_t tclass=fd Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs ino=3516 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:logrotate_t tclass=fd Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs ino=3516 scontext=system_u:system_r:cupsd_config_t tcontext=system_u:system_r:logrotate_t tclass=fd Nov 28 10:12:25 fedora kernel: audit(1101665545.232:0): avc: denied { use } for pid=4226 exe=/usr/sbin/cupsd path=/dev/null dev=tmpfs ino=3516 scontext=system_u:system_r:cupsd_t tcontext=system_u:system_r:system_crond_t tclass=fd Nov 28 10:12:25 fedora cups: cupsd startup succeeded -- Tom London From himainu-ynakam at miomio.jp Sun Nov 28 20:10:12 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Sun, 28 Nov 2004 15:10:12 -0500 Subject: SELinux/httpd integration In-Reply-To: <1101658996.30388.3981.camel@erato.phig.org> References: <1101658996.30388.3981.camel@erato.phig.org> Message-ID: <200411282010.iASKAY6v002921@mms-r00.iijmio.jp> Karsten Wade wrote: > > >httpd_t *cannot* write to anything labelled with httpd_sys_content_t by > > >default, surely - that's the whole problem? > I can't find this allow rule in 1.17.30-2.34. I've used apol direct and > transitive information flow analysis and good ol' grep to no avail. > Before I post a very long message detailing everything I did, can > someone tell me how httpd_t has gained write allow for > httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and > recompiled policy, but still can't find the write. It is in macros/program/apache_macros.te. I pick up related part in following. --- 113 if (httpd_enable_cgi) && (httpd_unified) ifdef(`targeted_policy', ` && ! (httpd_disable_trans)') { 114 ifelse($1, sys, ` 115 domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t) 116 domain_auto_trans(httpd_suexec_t, httpdcontent, httpd_sys_script_t) 117 domain_auto_trans(sysadm_t, httpdcontent, httpd_sys_script_t) 118 create_dir_file(httpd_t, httpdcontent) 119 ', ` 120 create_dir_file(httpd_$1_script_t, httpdcontent) 121 can_exec(httpd_$1_script_t, httpdcontent ) 122 domain_auto_trans($1_t, httpdcontent, httpd_$1_script_t) 123 ') 124 } --- Line 118 and line 120 are what you are looking for. In policy.conf I found 3 rules, too. type httpd_sys_content_t, file_type, homedirfile, httpdcontent, sysadmfile; allow httpd_t httpdcontent:dir { create read getattr lock setattr ioctl link unlink rename search add_name remove_name reparent write rmdir }; allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; > I can't find this allow rule in 1.17.30-2.34. I've used apol direct and > transitive information flow analysis and good ol' grep to no avail. I tried apol now, but I could not find the rule, either. apol information flow may not support attributes or booleans, but I am not sure. --- Yuichi Nakamura Japan SELinux Users Group(JSELUG) ??http://www.selinux.gr.jp/ From selinux at gmail.com Sun Nov 28 22:07:15 2004 From: selinux at gmail.com (Tom London) Date: Sun, 28 Nov 2004 14:07:15 -0800 Subject: proc_net .... kudzu.te, rpcd.te, mozilla_macros.te Message-ID: <4c4ba15304112814074502f60e@mail.gmail.com> Running strict/enforcing, latest Rawhide. Looks like some changes to policy for proc_net_t is causing some denials. Nov 28 09:06:51 fedora kernel: audit(1101661600.402:0): avc: denied { search } for pid=1520 exe=/usr/sbin/kudzu name=net dev=proc ino=-268435434 scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:proc_net_t tclass=dir Nov 28 10:28:12 fedora kernel: audit(1101666486.919:0): avc: denied { search } for pid=1843 exe=/usr/sbin/rpc.idmapd name=net dev=proc ino=-268435434 scontext=system_u:system_r:rpcd_t tcontext=system_u:object_r:proc_net_t tclass=dir Nov 28 10:29:38 fedora kernel: audit(1101666578.571:0): avc: denied { read } for pid=3146 exe=/bin/netstat name=net dev=proc ino=-268435434 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:proc_net_t tclass=dir Nov 28 10:29:39 fedora kernel: audit(1101666579.074:0): avc: denied { search } for pid=3146 exe=/bin/netstat name=net dev=proc ino=-268435434 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:proc_net_t tclass=dir Made the following changes to kudzu.te, rpcd.te and mozilla_macros.te Please correct as needed.... tom --- SAVE/kudzu.te 2004-11-28 10:23:18.000000000 -0800 +++ ./kudzu.te 2004-11-28 10:25:43.000000000 -0800 @@ -18,7 +18,8 @@ allow kudzu_t modules_object_t:dir r_dir_perms; allow kudzu_t { modules_object_t modules_dep_t }:file { getattr read }; allow kudzu_t mouse_device_t:chr_file { read write }; -allow kudzu_t proc_t:file { getattr read }; +allow kudzu_t proc_net_t:dir r_dir_perms; +allow kudzu_t { proc_t proc_net_t }:file { getattr read }; allow kudzu_t { fixed_disk_device_t removable_device_t }:blk_file rw_file_perms; allow kudzu_t scsi_generic_device_t:chr_file r_file_perms; allow kudzu_t { bin_t sbin_t }:dir { getattr search }; --- SAVE/rpcd.te 2004-11-28 10:43:20.801436658 -0800 +++ ./rpcd.te 2004-11-28 10:45:04.285886135 -0800 @@ -126,3 +126,4 @@ r_dir_file(rpcd_t, rpc_pipefs_t) allow rpcd_t rpc_pipefs_t:sock_file { read write }; dontaudit rpcd_t selinux_config_t:dir { search }; +allow rpcd_t proc_net_t:dir search; --- SAVE/mozilla_macros.te 2004-11-28 10:47:54.527909494 -0800 +++ ./mozilla_macros.te 2004-11-28 10:47:57.741626903 -0800 @@ -48,6 +48,7 @@ # for bash allow $1_mozilla_t device_t:dir r_dir_perms; allow $1_mozilla_t devpts_t:dir r_dir_perms; +allow $1_mozilla_t proc_net_t:dir r_dir_perms; +allow $1_mozilla_t proc_net_t:file r_file_perms; allow $1_mozilla_t proc_t:file { getattr read }; dontaudit $1_mozilla_t tty_device_t:chr_file getattr; -- Tom London From walters at redhat.com Sun Nov 28 18:35:52 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 28 Nov 2004 13:35:52 -0500 Subject: SELinux/httpd integration In-Reply-To: <1101658996.30388.3981.camel@erato.phig.org> References: <20041116132110.GA32134@redhat.com> <1100631416.26494.27.camel@nexus.verbum.private> <20041116203317.GB4356@redhat.com> <419A64A5.9010302@redhat.com> <1101658996.30388.3981.camel@erato.phig.org> Message-ID: <1101666952.2360.15.camel@nexus.verbum.private> On Sun, 2004-11-28 at 08:23 -0800, Karsten Wade wrote: > On Tue, 2004-11-16 at 12:35, Daniel J Walsh wrote: > > Joe Orton wrote: > > > > >httpd_t *cannot* write to anything labelled with > httpd_sys_content_t by > > >default, surely - that's the whole problem? > > > > Policy has been updated to allow this. Please update to > > selinux-policy-targeted-1.17.30-2.26 or greater. > > I can't find this allow rule in 1.17.30-2.34. I've used apol direct and > transitive information flow analysis and good ol' grep to no avail. > Before I post a very long message detailing everything I did, can > someone tell me how httpd_t has gained write allow for > httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and > recompiled policy, but still can't find the write. It's this section: if (httpd_enable_cgi && httpd_unified ifdef(`targeted_policy', ` && ! httpd_disable_trans')) { ifelse($1, sys, ` domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t) domain_auto_trans(httpd_suexec_t, httpdcontent, httpd_sys_script_t) domain_auto_trans(sysadm_t, httpdcontent, httpd_sys_script_t) create_dir_file(httpd_t, httpdcontent) ', ` can_exec(httpd_$1_script_t, httpdcontent ) domain_auto_trans($1_t, httpdcontent, httpd_$1_script_t) ') create_dir_file(httpd_$1_script_t, httpdcontent) } Specifically: create_dir_file(httpd_, httpdcontent) httpdcontent is an attribute that all of the various httpd types such as httpd_sys_content_t has. From russell at coker.com.au Mon Nov 29 08:04:52 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 29 Nov 2004 19:04:52 +1100 Subject: cups-config-daemon ? In-Reply-To: <4c4ba153041128115177c696b8@mail.gmail.com> References: <4c4ba153041128115177c696b8@mail.gmail.com> Message-ID: <200411291904.56706.russell@coker.com.au> On Monday 29 November 2004 06:51, Tom London wrote: > Running strict/enforcing, latest Rawhide. > > I think the following is coming from cups-config-daemon > > I'm always a bit suspicious of fd denials.... > these are to /dev/null... > Is this an open file leaking across an exec? I don't think that this is a problem. Granting access to /dev/null is not an issue. For cron jobs this sort of thing is common. The attached patch should do the job. > Help welcomed..... > tom > > > Nov 28 10:12:25 fedora cups: cupsd shutdown succeeded > Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied > { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs > ino=3516 scontext=system_u:system_r:cupsd_config_t > tcontext=system_u:system_r:system_crond_t tclass=fd > Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied > { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs > ino=3516 scontext=system_u:system_r:cupsd_config_t > tcontext=system_u:system_r:logrotate_t tclass=fd > Nov 28 10:12:25 fedora kernel: audit(1101665545.088:0): avc: denied > { use } for pid=4223 exe=/usr/bin/python path=/dev/null dev=tmpfs > ino=3516 scontext=system_u:system_r:cupsd_config_t > tcontext=system_u:system_r:logrotate_t tclass=fd > Nov 28 10:12:25 fedora kernel: audit(1101665545.232:0): avc: denied > { use } for pid=4226 exe=/usr/sbin/cupsd path=/dev/null dev=tmpfs > ino=3516 scontext=system_u:system_r:cupsd_t > tcontext=system_u:system_r:system_crond_t tclass=fd > Nov 28 10:12:25 fedora cups: cupsd startup succeeded -- 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 Type: text/x-diff Size: 801 bytes Desc: not available URL: From sstrong at crwash.org Mon Nov 29 02:27:42 2004 From: sstrong at crwash.org (Steve Strong) Date: Sun, 28 Nov 2004 20:27:42 -0600 Subject: SELinux changes from Fedora 2 to Fedora 3 Message-ID: <1101695262.3891.2.camel@birdseye.strongs.org> So, I bought a book to learn how to configure selinux (Bill McCarty from O'Reilly) and it appears that selinux has changed between Fedora 2 and 3. Has anyone else found differences? Has anyone set up a live server using policies written for SELinux? steve From sds at epoch.ncsc.mil Mon Nov 29 14:28:18 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 29 Nov 2004 09:28:18 -0500 Subject: init labeling question for targeted policy In-Reply-To: <1101340066.16858.7497.camel@erato.phig.org> References: <1101340066.16858.7497.camel@erato.phig.org> Message-ID: <1101738497.13948.29.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-11-24 at 18:47, Karsten Wade wrote: > Which one of these paths, if any, is leading in the right direction? There are a set of predefined SIDs (called initial SIDs) used for bootstrapping prior to initial policy load. When SELinux first initializes (during kernel initialization, well before policy load), the kernel assigns the initial task the "kernel" initial SID. Later, when the policy is loaded, the initial SIDs are mapped to security contexts in the policy via the initial_sid_contexts configuration, and the kernel can begin to get SIDs dynamically from the security server. In the strict policy, the "kernel" initial SID maps to kernel_t, and the policy defines a transition from kernel_t to init_t upon execution of init_exec_t, so when /sbin/init re-executes itself after loading policy, it transitions to init_t. In the targeted policy, the "kernel" initial SID maps to unconfined_t, and there is no transition defined in the targeted policy upon executing init_exec_t, so /sbin/init remains in unconfined_t even after the re-exec. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Nov 29 16:52:06 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Nov 2004 11:52:06 -0500 Subject: proc_net .... kudzu.te, rpcd.te, mozilla_macros.te In-Reply-To: <4c4ba15304112814074502f60e@mail.gmail.com> References: <4c4ba15304112814074502f60e@mail.gmail.com> Message-ID: <41AB53B6.7060206@redhat.com> Tom London wrote: >Running strict/enforcing, latest Rawhide. > >Looks like some changes to policy >for proc_net_t is causing some denials. > >Nov 28 09:06:51 fedora kernel: audit(1101661600.402:0): avc: denied >{ search } for pid=1520 exe=/usr/sbin/kudzu name=net dev=proc >ino=-268435434 scontext=system_u:system_r:kudzu_t >tcontext=system_u:object_r:proc_net_t tclass=dir >Nov 28 10:28:12 fedora kernel: audit(1101666486.919:0): avc: denied >{ search } for pid=1843 exe=/usr/sbin/rpc.idmapd name=net dev=proc >ino=-268435434 scontext=system_u:system_r:rpcd_t >tcontext=system_u:object_r:proc_net_t tclass=dir >Nov 28 10:29:38 fedora kernel: audit(1101666578.571:0): avc: denied >{ read } for pid=3146 exe=/bin/netstat name=net dev=proc >ino=-268435434 scontext=user_u:user_r:user_mozilla_t >tcontext=system_u:object_r:proc_net_t tclass=dir >Nov 28 10:29:39 fedora kernel: audit(1101666579.074:0): avc: denied >{ search } for pid=3146 exe=/bin/netstat name=net dev=proc >ino=-268435434 scontext=user_u:user_r:user_mozilla_t >tcontext=system_u:object_r:proc_net_t tclass=dir > >Made the following changes to >kudzu.te, rpcd.te and mozilla_macros.te > >Please correct as needed.... > tom > >--- SAVE/kudzu.te 2004-11-28 10:23:18.000000000 -0800 >+++ ./kudzu.te 2004-11-28 10:25:43.000000000 -0800 >@@ -18,7 +18,8 @@ > allow kudzu_t modules_object_t:dir r_dir_perms; > allow kudzu_t { modules_object_t modules_dep_t }:file { getattr read }; > allow kudzu_t mouse_device_t:chr_file { read write }; >-allow kudzu_t proc_t:file { getattr read }; >+allow kudzu_t proc_net_t:dir r_dir_perms; >+allow kudzu_t { proc_t proc_net_t }:file { getattr read }; > allow kudzu_t { fixed_disk_device_t removable_device_t }:blk_file >rw_file_perms; > allow kudzu_t scsi_generic_device_t:chr_file r_file_perms; > allow kudzu_t { bin_t sbin_t }:dir { getattr search }; >--- SAVE/rpcd.te 2004-11-28 10:43:20.801436658 -0800 >+++ ./rpcd.te 2004-11-28 10:45:04.285886135 -0800 >@@ -126,3 +126,4 @@ > r_dir_file(rpcd_t, rpc_pipefs_t) > allow rpcd_t rpc_pipefs_t:sock_file { read write }; > dontaudit rpcd_t selinux_config_t:dir { search }; >+allow rpcd_t proc_net_t:dir search; >--- SAVE/mozilla_macros.te 2004-11-28 10:47:54.527909494 -0800 >+++ ./mozilla_macros.te 2004-11-28 10:47:57.741626903 -0800 >@@ -48,6 +48,7 @@ > # for bash > allow $1_mozilla_t device_t:dir r_dir_perms; > allow $1_mozilla_t devpts_t:dir r_dir_perms; >+allow $1_mozilla_t proc_net_t:dir r_dir_perms; >+allow $1_mozilla_t proc_net_t:file r_file_perms; > allow $1_mozilla_t proc_t:file { getattr read }; > dontaudit $1_mozilla_t tty_device_t:chr_file getattr; > > > Added to policy-1.19.6-1 From kwade at redhat.com Mon Nov 29 18:12:37 2004 From: kwade at redhat.com (Karsten Wade) Date: Mon, 29 Nov 2004 10:12:37 -0800 Subject: init labeling question for targeted policy In-Reply-To: <1101738497.13948.29.camel@moss-spartans.epoch.ncsc.mil> References: <1101340066.16858.7497.camel@erato.phig.org> <1101738497.13948.29.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1101751957.3646.815.camel@erato.phig.org> On Mon, 2004-11-29 at 06:28, Stephen Smalley wrote: > On Wed, 2004-11-24 at 18:47, Karsten Wade wrote: > > Which one of these paths, if any, is leading in the right direction? > > There are a set of predefined SIDs (called initial SIDs) used for > bootstrapping prior to initial policy load. When SELinux first > initializes (during kernel initialization, well before policy load), the > kernel assigns the initial task the "kernel" initial SID. Later, when > the policy is loaded, the initial SIDs are mapped to security contexts > in the policy via the initial_sid_contexts configuration, and the kernel > can begin to get SIDs dynamically from the security server. In the > strict policy, the "kernel" initial SID maps to kernel_t, and the policy > defines a transition from kernel_t to init_t upon execution of > init_exec_t, so when /sbin/init re-executes itself after loading policy, > it transitions to init_t. In the targeted policy, the "kernel" initial > SID maps to unconfined_t, and there is no transition defined in the > targeted policy upon executing init_exec_t, so /sbin/init remains in > unconfined_t even after the re-exec. Excellent, thank you, that makes perfect sense. - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From astephens at ptera.net Mon Nov 29 20:54:15 2004 From: astephens at ptera.net (Arthur Stephens) Date: Mon, 29 Nov 2004 12:54:15 -0800 Subject: httpd avc denied problem References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker><1101754789.22761.319.camel@serendipity.dogma.lan><003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> Message-ID: <006d01c4d655$968db4d0$c600a8c0@tyliteworker> >> I am new to SELinux and Fedora 3 - setting up a replacement server for the one that got hacked >> I transfered our websites over and discovered I had to have them all under /usr/www/ >>Who or what does tell you this should be this way? /usr/ is the wrong >>place. Ok I moved everything under /var/www.. ran fixfiles changed everything under httpd.conf to point to /var/www/... I got the same error messages just different directories Being desperate to get this working I copied the error_log from a directory that was working ran fixfiles and got avc: denied { append } (13)Permission denied: httpd: could not open error log file /var/www/spokanewines.com/logs/error_log. Unable to open logs [root at webmail ~]# cd /var/www/spokanewines.com/logs/ [root at webmail logs]# ls -alZ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. -rw-r--r-- root root system_u:object_r:httpd_sys_content_t access_log -rw-r--r-- root root system_u:object_r:httpd_sys_content_t error_log I tried to run system-config-securitylevel but there are no references to Boolean options for Apache HTTP just firewall options. Arthur Stephens Sales Technician Ptera Wireless Internet astephens at ptera.net 509-927-Ptera ----- Original Message ----- From: "Alexander Dalloz" To: "For users of Fedora Core releases" Sent: Monday, November 29, 2004 11:25 AM Subject: Re: httpd avc denied problem > -- > fedora-list mailing list > fedora-list at redhat.com > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list From rpjday at mindspring.com Mon Nov 29 21:47:52 2004 From: rpjday at mindspring.com (Robert P. J. Day) Date: Mon, 29 Nov 2004 16:47:52 -0500 (EST) Subject: /etc/rc.sysinit: restorecon being run even when selinux disabled Message-ID: this might be irrelevant, but in FC3's /etc/rc.sysinit, right near the top, there's some shell code that handles selinux: ===== # Check SELinux status selinuxfs=`awk '/ selinuxfs / { print $2 }' /proc/mounts` SELINUX= if [ -n "$selinuxfs" ] && [ "`cat /proc/self/attr/current`" != "kernel" ]; then if [ -r $selinuxfs/enforce ] ; then SELINUX=`cat $selinuxfs/enforce` else # assume enforcing if you can't read it SELINUX=1 fi fi ===== so far, so good. if selinux is disabled, i'm assuming there won't be any entry with "selinuxfs" in the output of /proc/mounts. but the very next check is: ===== if [ -x /sbin/restorecon ] && LC_ALL=C fgrep -q " /dev " /proc/mounts ; then /sbin/restorecon -R /dev 2>/dev/null fi ===== which will *apparently* be run regardless of whether or not selinux is enabled or not. if selinux is disabled, is there any point in even checking whether or not to run restorecon? (from what i read, the "rectorecon" program is clearly related to selinux.) rday From notting at redhat.com Mon Nov 29 23:00:19 2004 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Nov 2004 18:00:19 -0500 Subject: /etc/rc.sysinit: restorecon being run even when selinux disabled In-Reply-To: References: Message-ID: <20041129230019.GA4703@nostromo.devel.redhat.com> Robert P. J. Day (rpjday at mindspring.com) said: > ===== > if [ -x /sbin/restorecon ] && LC_ALL=C fgrep -q " /dev " /proc/mounts ; then > /sbin/restorecon -R /dev 2>/dev/null > fi > ===== > > which will *apparently* be run regardless of whether or not selinux is > enabled or not. if selinux is disabled, is there any point in even > checking whether or not to run restorecon? (from what i read, the > "rectorecon" program is clearly related to selinux.) restorecon will check whether selinux is enabled and immediately exit, so it's not a huge saving to bail in the !SELinux case. But fixed in CVS anyway. :) Bill From kwade at redhat.com Mon Nov 29 23:11:20 2004 From: kwade at redhat.com (Karsten Wade) Date: Mon, 29 Nov 2004 15:11:20 -0800 Subject: httpd avc denied problem In-Reply-To: <006d01c4d655$968db4d0$c600a8c0@tyliteworker> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker> <1101754789.22761.319.camel@serendipity.dogma.lan> <003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> <006d01c4d655$968db4d0$c600a8c0@tyliteworker> Message-ID: <1101769879.3646.1529.camel@erato.phig.org> On Mon, 2004-11-29 at 12:54, Arthur Stephens wrote: > >> I am new to SELinux and Fedora 3 - setting up a replacement server for > the one that got hacked > >> I transfered our websites over and discovered I had to have them all > under /usr/www/ > > >>Who or what does tell you this should be this way? /usr/ is the wrong > >>place. This convention has been in place for a while, it's just more challengin now to have Web files other than in /var/www/. If you haven't seen this, it might help some more: http://fedora.redhat.com/docs/selinux-apache-fc3/ Read on for some suggestions. If you are still stuck, drop by #fedora-selinux on irc.freenode.net. > Ok I moved everything under /var/www.. > ran fixfiles > changed everything under httpd.conf to point to /var/www/... > I got the same error messages just different directories > > Being desperate to get this working I copied the error_log from a directory > that was working > ran fixfiles This should have worked if you ran 'fixfiles relabel'. However, 'restorecon -R /var/www/' should achieve the same thing, but much more quickly. Still, that will just set the files to the file type set for /var/www/, as defined in /etc/selinux/targeted/src/policy/file_contexts/file_contexts: /var/www(/.*)? system_u:object_r:httpd_sys_content_t It looks as if the httpd policy needs the logs to be a different type: allow httpd_t httpd_runtime_t : file { create ioctl read getattr lock write setattr append link unlink rename }; ^^^^^^ <- that's what we want to see e.g: ls /var/log/httpd/ -Z -rw-r--r-- root root root:object_r:httpd_runtime_t access_log -rw-r--r-- root root root:object_r:httpd_runtime_t access_log.1 -rw-r--r-- root root root:object_r:httpd_runtime_t access_log.2 -rw-r--r-- root root root:object_r:httpd_runtime_t error_log -rw-r--r-- root root root:object_r:httpd_runtime_t error_log.1 -rw-r--r-- root root root:object_r:httpd_runtime_t error_log.2 ... You can try: chcon -R -t httpd_runtime_t /var/www/*/logs However, this labeling will likely get wiped out the next time restorecon or fixfiles relabel is run. If your intention is to make the logs viewable via public HTTP, you might try moving them to /var/log/httpd/ and then symlinking the files to /var/www/*/logs. The symlinks should be created with httpd_sys_content_t, which is easily readable (just not neccesarily writable or appendable) by httpd. Running restorecon on the moved logs should make it Just Work (TM). > and got avc: denied { append } > (13)Permission denied: httpd: could not open error log file > /var/www/spokanewines.com/logs/error_log. > Unable to open logs > > [root at webmail ~]# cd /var/www/spokanewines.com/logs/ > [root at webmail logs]# ls -alZ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > access_log > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > error_log > > I tried to run > system-config-securitylevel > but there are no references to Boolean options for Apache HTTP > just firewall options. Which version of s-c-sl do you have? AIUI, the SELinux tab is automatically populated depending on what is in your policy. I have 1.4.18-2, fwiw. Regardless, you can set the Booleans on the command line: setsebool httpd_unified true That is a troubleshooting Boolean you can try. Still, your setup should work, if it's just httpd trying to append to the httpd logs, and they are labeled correctly and/or in the correct location. Still, I'm certain that httpd_t can't append to a file that is set to httpd_sys_content_t unless httpd_unified is enabled. This makes me think that your log files are still labeled incorrectly. If all of this fails, you can turn off the SELinux protection for just Apache by using: setsebool httpd_disable_trans true That will disable the transition for httpd, so it will run in the unconfined_t domain like the rest of the non-SELinux protected daemons. If you do that, please don't give up troubleshooting! Your situation should work, and if it doesn't, we all want to figure out why. :) - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From astephens at ptera.net Tue Nov 30 00:53:54 2004 From: astephens at ptera.net (Arthur Stephens) Date: Mon, 29 Nov 2004 16:53:54 -0800 Subject: httpd avc denied problem References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker><1101754789.22761.319.camel@serendipity.dogma.lan><003801c4d647$c3350370$c600a8c0@tyliteworker><1101756300.22761.321.camel@serendipity.dogma.lan><006d01c4d655$968db4d0$c600a8c0@tyliteworker> <1101769879.3646.1529.camel@erato.phig.org> Message-ID: <00c201c4d677$11ca2810$c600a8c0@tyliteworker> >If you haven't seen this, it might help some more: >http://fedora.redhat.com/docs/selinux-apache-fc3/ I was here but nothing there explained what was going on. > /var/www/, as defined in > /etc/selinux/targeted/src/policy/file_contexts/file_contexts: OK Mine is located someplace different /etc/selinux/targeted/context/files/file_contexts > > /var/www(/.*)? system_u:object_r:httpd_sys_content_t > > It looks as if the httpd policy needs the logs to be a different type: Mine says the same... But there is a /etc/httpd/logs system_u:object_r:httpd_log_t But what puzzles me is why only this one log directory....all the others like it work... EXAMPLES /var/www/arthurstephens.com/logs [root at webmail arthurstephens.com]# ls -alZ logs/ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. -rw-r--r-- root root system_u:object_r:httpd_sys_content_t access_log -rw-r--r-- root root system_u:object_r:httpd_sys_content_t error_log /var/www/cvafoundation.org/logs [root at webmail cvafoundation.org]# ls -alZ logs/ drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. -rw-r--r-- root root system_u:object_r:httpd_sys_content_t access_log -rw-r--r-- root root system_u:object_r:httpd_sys_content_t error_log But this one fails... /var/www/spokanewines.com/logs [root at webmail spokanewines.com]# ls -alZ logs drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. -rw-r--r-- root root system_u:object_r:httpd_sys_content_t access_log -rw-r--r-- root root system_u:object_r:httpd_sys_content_t error_log > If all of this fails, you can turn off the SELinux protection for just > Apache by using: > > setsebool httpd_disable_trans true > > That will disable the transition for httpd, so it will run in the > unconfined_t domain like the rest of the non-SELinux protected daemons. > If you do that, please don't give up troubleshooting! Your situation > should work, and if it doesn't, we all want to figure out why. :) > This would be the quickie fix but the main reason I am rebuilding these system is because they keep getting rootkit/hacked I am under pressure from above to lock these things down. Arthur Stephens Sales Technician Ptera Wireless Internet astephens at ptera.net 509-927-Ptera From kwade at redhat.com Tue Nov 30 13:03:51 2004 From: kwade at redhat.com (Karsten Wade) Date: Tue, 30 Nov 2004 05:03:51 -0800 Subject: httpd avc denied problem In-Reply-To: <00c201c4d677$11ca2810$c600a8c0@tyliteworker> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker> <1101754789.22761.319.camel@serendipity.dogma.lan> <003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> <006d01c4d655$968db4d0$c600a8c0@tyliteworker> <1101769879.3646.1529.camel@erato.phig.org> <00c201c4d677$11ca2810$c600a8c0@tyliteworker> Message-ID: <1101819830.3646.4548.camel@erato.phig.org> On Mon, 2004-11-29 at 16:53, Arthur Stephens wrote: > > /var/www/, as defined in > > /etc/selinux/targeted/src/policy/file_contexts/file_contexts: > > OK Mine is located someplace different > /etc/selinux/targeted/context/files/file_contexts Yeah, it's the same file as the one in the policy sources (targeted/src/policy), which comes from the selinux-policy-targeted-sources directory. You shouldn't need that unless you have to customize the policy, which doesn't sound necessary yet. > > /var/www(/.*)? system_u:object_r:httpd_sys_content_t > > > > It looks as if the httpd policy needs the logs to be a different type: > > Mine says the same... > But there is a > /etc/httpd/logs system_u:object_r:httpd_log_t And this: /var/log/httpd(/.*)? system_u:object_r:httpd_log_t I suppose either would work, since httpd_t can append to httpd_log_t and httpd_runtime_t. httpd_log_t looks like the proper one to use. > But what puzzles me is why only this one log directory....all the others > like it work... This is with httpd_unified set to true? AIUI, it must be set to true, if httpd_t can append to httpd_sys_content_t. For 'ls -Z /var/www' are all the directories essentially the same permissions? I'm not thinking the problem is regular UNIX permissions because you got an AVC denial ... something is fishy. Does it error if you change the type of the log files to httpd_log_t? I.e., chcon -R -t httpd_log_t /var/www/spokanewines.com/logs/* Can you send in the avc: denied errors that you are getting? I can't imagine how this would be a policy bug, but it's worth looking into. - Karsten > EXAMPLES > /var/www/arthurstephens.com/logs > [root at webmail arthurstephens.com]# ls -alZ logs/ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > access_log > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > error_log > > /var/www/cvafoundation.org/logs > [root at webmail cvafoundation.org]# ls -alZ logs/ > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > access_log > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > error_log > > But this one fails... > /var/www/spokanewines.com/logs > [root at webmail spokanewines.com]# ls -alZ logs > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > access_log > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > error_log -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From astephens at ptera.net Tue Nov 30 19:02:59 2004 From: astephens at ptera.net (Arthur Stephens) Date: Tue, 30 Nov 2004 11:02:59 -0800 Subject: httpd avc denied problem References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker><1101754789.22761.319.camel@serendipity.dogma.lan><003801c4d647$c3350370$c600a8c0@tyliteworker><1101756300.22761.321.camel@serendipity.dogma.lan><006d01c4d655$968db4d0$c600a8c0@tyliteworker><1101769879.3646.1529.camel@erato.phig.org><00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org> Message-ID: <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> ----- Original Message ----- From: "Karsten Wade" To: "Fedora SELinux support list for users & developers." Sent: Tuesday, November 30, 2004 5:03 AM Subject: Re: httpd avc denied problem > On Mon, 2004-11-29 at 16:53, Arthur Stephens wrote: > > > /var/www/, as defined in > > > /etc/selinux/targeted/src/policy/file_contexts/file_contexts: > > > > OK Mine is located someplace different > > /etc/selinux/targeted/context/files/file_contexts > > Yeah, it's the same file as the one in the policy sources > (targeted/src/policy), which comes from the > selinux-policy-targeted-sources directory. You shouldn't need that > unless you have to customize the policy, which doesn't sound necessary > yet. > > > > /var/www(/.*)? system_u:object_r:httpd_sys_content_t > > > > > > It looks as if the httpd policy needs the logs to be a different type: > > > > Mine says the same... > > But there is a > > /etc/httpd/logs system_u:object_r:httpd_log_t > > And this: > > /var/log/httpd(/.*)? system_u:object_r:httpd_log_t > > I suppose either would work, since httpd_t can append to httpd_log_t and > httpd_runtime_t. httpd_log_t looks like the proper one to use. > > > But what puzzles me is why only this one log directory....all the others > > like it work... > > This is with httpd_unified set to true? Yes actually mine says "active" AIUI, it must be set to true, > if httpd_t can append to httpd_sys_content_t. > > For 'ls -Z /var/www' are all the directories essentially the same > permissions? I'm not thinking the problem is regular UNIX permissions > because you got an AVC denial ... something is fishy. ls -Z /var/www drwxrwxrwx root root system_u:object_r:httpd_sys_content_t aha drwxr-xr-x root root system_u:object_r:httpd_sys_content_t arthurstephens.com drwxr-xr-x root root system_u:object_r:httpd_sys_content_t birdshield.com drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t cgi-bin drwxr-xr-x root root system_u:object_r:httpd_sys_content_t charlieh drwxrwxrwx root root system_u:object_r:httpd_sys_content_t cvafoundation.org drwxrwxrwx root root system_u:object_r:httpd_sys_content_t davidh drwxrwxrwx root root system_u:object_r:httpd_sys_content_t digitalcreations drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons drwxrwxrwx root root system_u:object_r:httpd_sys_content_t jjakober drwxrwxrwx root root system_u:object_r:httpd_sys_content_t kodiaks drwxr-xr-x root root system_u:object_r:httpd_sys_content_t lindarosephoto.com drwxr-xr-x root root system_u:object_r:httpd_sys_content_t lwccspokane.org drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual drwxr-xr-x root root system_u:object_r:httpd_sys_content_t pteraweb drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ptootie drwxrwxrwx root root system_u:object_r:httpd_sys_content_t punisher drwxrwxrwx root root system_u:object_r:httpd_sys_content_t spokanewines.com drwxrwxrwx root root system_u:object_r:httpd_sys_content_t stevefm drwxrwxrwx root root system_u:object_r:httpd_sys_content_t suetkr drwxr-xr-x root root system_u:object_r:httpd_sys_content_t tangleheart.com drwxr-xr-x webalize root system_u:object_r:httpd_sys_content_t usage drwxrwxrwx apache apache system_u:object_r:httpd_sys_content_t wag1designs > > Does it error if you change the type of the log files to httpd_log_t? > I.e., > > chcon -R -t httpd_log_t /var/www/spokanewines.com/logs/* Issued the above command and then service httpd start Nov 30 13:31:29 webmail kernel: audit(1101850289.759:0): avc: denied { append } for pid=2585 exe=/usr/sbin/httpd name=error_log dev=dm-0 ino=552157 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file Nov 30 13:31:29 webmail httpd: httpd startup failed ls -Z /var/www/spokanewines.com/logs -rw-r--r-- root root system_u:object_r:httpd_log_t access_log -rw-r--r-- root root system_u:object_r:httpd_log_t error_log > Can you send in the avc: denied errors that you are getting? I can't > imagine how this would be a policy bug, but it's worth looking into. > > - Karsten > > EXAMPLES > > /var/www/arthurstephens.com/logs > > [root at webmail arthurstephens.com]# ls -alZ logs/ > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > access_log > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > error_log > > > > /var/www/cvafoundation.org/logs > > [root at webmail cvafoundation.org]# ls -alZ logs/ > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > access_log > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > error_log > > > > But this one fails... > > /var/www/spokanewines.com/logs > > [root at webmail spokanewines.com]# ls -alZ logs > > drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > access_log > > -rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > error_log > > -- > Karsten Wade, RHCE, Tech Writer > a lemon is just a melon in disguise > http://people.redhat.com/kwade/ > gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Nov 30 19:25:35 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 30 Nov 2004 14:25:35 -0500 Subject: httpd avc denied problem In-Reply-To: <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker><1101754789.22761.319.camel@serendipity.dogma.lan><003801c4d647$c3350370$c600a8c0@tyliteworker><1101756300.22761.321.camel@serendipity.dogma.lan><006d01c4d655$968db4d0$c600a8c0@tyliteworker><1101769879.3646.1529.camel@erato.phig.org><00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org> <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> Message-ID: <41ACC92F.2000102@redhat.com> Arthur Stephens wrote: >----- Original Message ----- >From: "Karsten Wade" >To: "Fedora SELinux support list for users & developers." > >Sent: Tuesday, November 30, 2004 5:03 AM >Subject: Re: httpd avc denied problem > > > > >>On Mon, 2004-11-29 at 16:53, Arthur Stephens wrote: >> >> >>>>/var/www/, as defined in >>>>/etc/selinux/targeted/src/policy/file_contexts/file_contexts: >>>> >>>> >>>OK Mine is located someplace different >>> /etc/selinux/targeted/context/files/file_contexts >>> >>> >>Yeah, it's the same file as the one in the policy sources >>(targeted/src/policy), which comes from the >>selinux-policy-targeted-sources directory. You shouldn't need that >>unless you have to customize the policy, which doesn't sound necessary >>yet. >> >> >> >>>>/var/www(/.*)? system_u:object_r:httpd_sys_content_t >>>> >>>>It looks as if the httpd policy needs the logs to be a different type: >>>> >>>> >>>Mine says the same... >>>But there is a >>>/etc/httpd/logs system_u:object_r:httpd_log_t >>> >>> >>And this: >> >>/var/log/httpd(/.*)? system_u:object_r:httpd_log_t >> >>I suppose either would work, since httpd_t can append to httpd_log_t and >>httpd_runtime_t. httpd_log_t looks like the proper one to use. >> >> >> >>>But what puzzles me is why only this one log directory....all the others >>>like it work... >>> >>> >>This is with httpd_unified set to true? >> >> > >Yes actually mine says "active" > >AIUI, it must be set to true, > > >>if httpd_t can append to httpd_sys_content_t. >> >>For 'ls -Z /var/www' are all the directories essentially the same >>permissions? I'm not thinking the problem is regular UNIX permissions >>because you got an AVC denial ... something is fishy. >> >> > >ls -Z /var/www >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t aha >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t >arthurstephens.com >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t >birdshield.com >drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t >cgi-bin >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t charlieh >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t >cvafoundation.org >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t davidh >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t >digitalcreations >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t jjakober >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t kodiaks >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t >lindarosephoto.com >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t >lwccspokane.org >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t pteraweb >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ptootie >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t punisher >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t >spokanewines.com >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t stevefm >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t suetkr >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t >tangleheart.com >drwxr-xr-x webalize root system_u:object_r:httpd_sys_content_t usage >drwxrwxrwx apache apache system_u:object_r:httpd_sys_content_t >wag1designs > > > >>Does it error if you change the type of the log files to httpd_log_t? >>I.e., >> >> chcon -R -t httpd_log_t /var/www/spokanewines.com/logs/* >> >> > >Issued the above command and then service httpd start > >Nov 30 13:31:29 webmail kernel: audit(1101850289.759:0): avc: denied { >append } for pid=2585 exe=/usr/sbin/httpd name=error_log dev=dm-0 >ino=552157 scontext=root:system_r:httpd_t >tcontext=system_u:object_r:httpd_sys_content_t tclass=file >Nov 30 13:31:29 webmail httpd: httpd startup failed > >ls -Z /var/www/spokanewines.com/logs >-rw-r--r-- root root system_u:object_r:httpd_log_t access_log >-rw-r--r-- root root system_u:object_r:httpd_log_t error_log > > Are you sure this error_log is the one represented by ino=552157??? > > >>Can you send in the avc: denied errors that you are getting? I can't >>imagine how this would be a policy bug, but it's worth looking into. >> >>- Karsten >> >> >>>EXAMPLES >>>/var/www/arthurstephens.com/logs >>>[root at webmail arthurstephens.com]# ls -alZ logs/ >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>access_log >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>error_log >>> >>>/var/www/cvafoundation.org/logs >>>[root at webmail cvafoundation.org]# ls -alZ logs/ >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>access_log >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>error_log >>> >>>But this one fails... >>>/var/www/spokanewines.com/logs >>>[root at webmail spokanewines.com]# ls -alZ logs >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>access_log >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t >>>error_log >>> >>> >>-- >>Karsten Wade, RHCE, Tech Writer >>a lemon is just a melon in disguise >>http://people.redhat.com/kwade/ >>gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From astephens at ptera.net Tue Nov 30 19:41:52 2004 From: astephens at ptera.net (Arthur Stephens) Date: Tue, 30 Nov 2004 11:41:52 -0800 Subject: httpd avc denied problem References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker><1101754789.22761.319.camel@serendipity.dogma.lan><003801c4d647$c3350370$c600a8c0@tyliteworker><1101756300.22761.321.camel@serendipity.dogma.lan><006d01c4d655$968db4d0$c600a8c0@tyliteworker><1101769879.3646.1529.camel@erato.phig.org><00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org><012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> <41ACC92F.2000102@redhat.com> Message-ID: <013501c4d714$a49e6be0$c600a8c0@tyliteworker> opps.. I forgot to check /var/log/httpd/error_log Before (13)Permission denied: httpd: could not open error log file /var/www/spokanewines.com/logs/error_log. Unable to open logs After (13)Permission denied: httpd: could not open error log file /var/www/tangleheart.com/logs/error_log. Unable to open logs Looks like it just switched to another directory....hmmmm ----- Original Message ----- From: "Daniel J Walsh" To: "Fedora SELinux support list for users & developers." Sent: Tuesday, November 30, 2004 11:25 AM Subject: Re: httpd avc denied problem > Arthur Stephens wrote: > > >----- Original Message ----- > >From: "Karsten Wade" > >To: "Fedora SELinux support list for users & developers." > > > >Sent: Tuesday, November 30, 2004 5:03 AM > >Subject: Re: httpd avc denied problem > > > > > > > > > >>On Mon, 2004-11-29 at 16:53, Arthur Stephens wrote: > >> > >> > >>>>/var/www/, as defined in > >>>>/etc/selinux/targeted/src/policy/file_contexts/file_contexts: > >>>> > >>>> > >>>OK Mine is located someplace different > >>> /etc/selinux/targeted/context/files/file_contexts > >>> > >>> > >>Yeah, it's the same file as the one in the policy sources > >>(targeted/src/policy), which comes from the > >>selinux-policy-targeted-sources directory. You shouldn't need that > >>unless you have to customize the policy, which doesn't sound necessary > >>yet. > >> > >> > >> > >>>>/var/www(/.*)? system_u:object_r:httpd_sys_content_t > >>>> > >>>>It looks as if the httpd policy needs the logs to be a different type: > >>>> > >>>> > >>>Mine says the same... > >>>But there is a > >>>/etc/httpd/logs system_u:object_r:httpd_log_t > >>> > >>> > >>And this: > >> > >>/var/log/httpd(/.*)? system_u:object_r:httpd_log_t > >> > >>I suppose either would work, since httpd_t can append to httpd_log_t and > >>httpd_runtime_t. httpd_log_t looks like the proper one to use. > >> > >> > >> > >>>But what puzzles me is why only this one log directory....all the others > >>>like it work... > >>> > >>> > >>This is with httpd_unified set to true? > >> > >> > > > >Yes actually mine says "active" > > > >AIUI, it must be set to true, > > > > > >>if httpd_t can append to httpd_sys_content_t. > >> > >>For 'ls -Z /var/www' are all the directories essentially the same > >>permissions? I'm not thinking the problem is regular UNIX permissions > >>because you got an AVC denial ... something is fishy. > >> > >> > > > >ls -Z /var/www > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t aha > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > >arthurstephens.com > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > >birdshield.com > >drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t > >cgi-bin > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t charlieh > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > >cvafoundation.org > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t davidh > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > >digitalcreations > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t jjakober > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t kodiaks > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > >lindarosephoto.com > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > >lwccspokane.org > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t manual > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t pteraweb > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t ptootie > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t punisher > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > >spokanewines.com > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t stevefm > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t suetkr > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > >tangleheart.com > >drwxr-xr-x webalize root system_u:object_r:httpd_sys_content_t usage > >drwxrwxrwx apache apache system_u:object_r:httpd_sys_content_t > >wag1designs > > > > > > > >>Does it error if you change the type of the log files to httpd_log_t? > >>I.e., > >> > >> chcon -R -t httpd_log_t /var/www/spokanewines.com/logs/* > >> > >> > > > >Issued the above command and then service httpd start > > > >Nov 30 13:31:29 webmail kernel: audit(1101850289.759:0): avc: denied { > >append } for pid=2585 exe=/usr/sbin/httpd name=error_log dev=dm-0 > >ino=552157 scontext=root:system_r:httpd_t > >tcontext=system_u:object_r:httpd_sys_content_t tclass=file > >Nov 30 13:31:29 webmail httpd: httpd startup failed > > > >ls -Z /var/www/spokanewines.com/logs > >-rw-r--r-- root root system_u:object_r:httpd_log_t access_log > >-rw-r--r-- root root system_u:object_r:httpd_log_t error_log > > > > > > Are you sure this error_log is the one represented by ino=552157??? > > > > > > >>Can you send in the avc: denied errors that you are getting? I can't > >>imagine how this would be a policy bug, but it's worth looking into. > >> > >>- Karsten > >> > >> > >>>EXAMPLES > >>>/var/www/arthurstephens.com/logs > >>>[root at webmail arthurstephens.com]# ls -alZ logs/ > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>access_log > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>error_log > >>> > >>>/var/www/cvafoundation.org/logs > >>>[root at webmail cvafoundation.org]# ls -alZ logs/ > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>access_log > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>error_log > >>> > >>>But this one fails... > >>>/var/www/spokanewines.com/logs > >>>[root at webmail spokanewines.com]# ls -alZ logs > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>access_log > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > >>>error_log > >>> > >>> > >>-- > >>Karsten Wade, RHCE, Tech Writer > >>a lemon is just a melon in disguise > >>http://people.redhat.com/kwade/ > >>gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 > >> > >>-- > >>fedora-selinux-list mailing list > >>fedora-selinux-list at redhat.com > >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> > >> > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From kwade at redhat.com Tue Nov 30 21:12:27 2004 From: kwade at redhat.com (Karsten Wade) Date: Tue, 30 Nov 2004 13:12:27 -0800 Subject: httpd avc denied problem In-Reply-To: <013501c4d714$a49e6be0$c600a8c0@tyliteworker> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker> <1101754789.22761.319.camel@serendipity.dogma.lan> <003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> <006d01c4d655$968db4d0$c600a8c0@tyliteworker> <1101769879.3646.1529.camel@erato.phig.org> <00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org> <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> <41ACC92F.2000102@redhat.com> <013501c4d714$a49e6be0$c600a8c0@tyliteworker> Message-ID: <1101849147.3646.6228.camel@erato.phig.org> On Tue, 2004-11-30 at 11:41, Arthur Stephens wrote: > opps.. I forgot to check /var/log/httpd/error_log > Before > (13)Permission denied: httpd: could not open error log file > /var/www/spokanewines.com/logs/error_log. > Unable to open logs > After > (13)Permission denied: httpd: could not open error log file > /var/www/tangleheart.com/logs/error_log. I think I know what is going on When httpd is starting, it tries to write to the logs, fails on the first one, issues an error, and quits. Since you fixed the labeling, it actually passed spokanewines.com/logs/error_log and went to the next one, where it errors again. I'd reckon that it's going through your domains in the order they appear in httpd.conf. Try this: chcon -R -t httpd_log_t /var/www/*/logs/* service httpd start - Karsten > Unable to open logs > > Looks like it just switched to another directory....hmmmm > > ----- Original Message ----- > From: "Daniel J Walsh" > To: "Fedora SELinux support list for users & developers." > > Sent: Tuesday, November 30, 2004 11:25 AM > Subject: Re: httpd avc denied problem > > > > Arthur Stephens wrote: > > > > >----- Original Message ----- > > >From: "Karsten Wade" > > >To: "Fedora SELinux support list for users & developers." > > > > > >Sent: Tuesday, November 30, 2004 5:03 AM > > >Subject: Re: httpd avc denied problem > > > > > > > > > > > > > > >>On Mon, 2004-11-29 at 16:53, Arthur Stephens wrote: > > >> > > >> > > >>>>/var/www/, as defined in > > >>>>/etc/selinux/targeted/src/policy/file_contexts/file_contexts: > > >>>> > > >>>> > > >>>OK Mine is located someplace different > > >>> /etc/selinux/targeted/context/files/file_contexts > > >>> > > >>> > > >>Yeah, it's the same file as the one in the policy sources > > >>(targeted/src/policy), which comes from the > > >>selinux-policy-targeted-sources directory. You shouldn't need that > > >>unless you have to customize the policy, which doesn't sound necessary > > >>yet. > > >> > > >> > > >> > > >>>>/var/www(/.*)? system_u:object_r:httpd_sys_content_t > > >>>> > > >>>>It looks as if the httpd policy needs the logs to be a different type: > > >>>> > > >>>> > > >>>Mine says the same... > > >>>But there is a > > >>>/etc/httpd/logs system_u:object_r:httpd_log_t > > >>> > > >>> > > >>And this: > > >> > > >>/var/log/httpd(/.*)? system_u:object_r:httpd_log_t > > >> > > >>I suppose either would work, since httpd_t can append to httpd_log_t and > > >>httpd_runtime_t. httpd_log_t looks like the proper one to use. > > >> > > >> > > >> > > >>>But what puzzles me is why only this one log directory....all the > others > > >>>like it work... > > >>> > > >>> > > >>This is with httpd_unified set to true? > > >> > > >> > > > > > >Yes actually mine says "active" > > > > > >AIUI, it must be set to true, > > > > > > > > >>if httpd_t can append to httpd_sys_content_t. > > >> > > >>For 'ls -Z /var/www' are all the directories essentially the same > > >>permissions? I'm not thinking the problem is regular UNIX permissions > > >>because you got an AVC denial ... something is fishy. > > >> > > >> > > > > > >ls -Z /var/www > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t aha > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > > >arthurstephens.com > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > > >birdshield.com > > >drwxr-xr-x root root system_u:object_r:httpd_sys_script_exec_t > > >cgi-bin > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > charlieh > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > > >cvafoundation.org > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > davidh > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > > >digitalcreations > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t error > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t html > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t icons > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > jjakober > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > kodiaks > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > > >lindarosephoto.com > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > > >lwccspokane.org > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > manual > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > pteraweb > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > ptootie > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > punisher > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > > >spokanewines.com > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > stevefm > > >drwxrwxrwx root root system_u:object_r:httpd_sys_content_t > suetkr > > >drwxr-xr-x root root system_u:object_r:httpd_sys_content_t > > >tangleheart.com > > >drwxr-xr-x webalize root system_u:object_r:httpd_sys_content_t usage > > >drwxrwxrwx apache apache system_u:object_r:httpd_sys_content_t > > >wag1designs > > > > > > > > > > > >>Does it error if you change the type of the log files to httpd_log_t? > > >>I.e., > > >> > > >> chcon -R -t httpd_log_t /var/www/spokanewines.com/logs/* > > >> > > >> > > > > > >Issued the above command and then service httpd start > > > > > >Nov 30 13:31:29 webmail kernel: audit(1101850289.759:0): avc: denied { > > >append } for pid=2585 exe=/usr/sbin/httpd name=error_log dev=dm-0 > > >ino=552157 scontext=root:system_r:httpd_t > > >tcontext=system_u:object_r:httpd_sys_content_t tclass=file > > >Nov 30 13:31:29 webmail httpd: httpd startup failed > > > > > >ls -Z /var/www/spokanewines.com/logs > > >-rw-r--r-- root root system_u:object_r:httpd_log_t access_log > > >-rw-r--r-- root root system_u:object_r:httpd_log_t error_log > > > > > > > > > > Are you sure this error_log is the one represented by ino=552157??? > > > > > > > > > > >>Can you send in the avc: denied errors that you are getting? I can't > > >>imagine how this would be a policy bug, but it's worth looking into. > > >> > > >>- Karsten > > >> > > >> > > >>>EXAMPLES > > >>>/var/www/arthurstephens.com/logs > > >>>[root at webmail arthurstephens.com]# ls -alZ logs/ > > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t .. > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>access_log > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>error_log > > >>> > > >>>/var/www/cvafoundation.org/logs > > >>>[root at webmail cvafoundation.org]# ls -alZ logs/ > > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>access_log > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>error_log > > >>> > > >>>But this one fails... > > >>>/var/www/spokanewines.com/logs > > >>>[root at webmail spokanewines.com]# ls -alZ logs > > >>>drwxr-xr-x root root system_u:object_r:httpd_sys_content_t . > > >>>drwxrwxrwx root root system_u:object_r:httpd_sys_content_t .. > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>access_log > > >>>-rw-r--r-- root root system_u:object_r:httpd_sys_content_t > > >>>error_log > > >>> > > >>> > > >>-- > > >>Karsten Wade, RHCE, Tech Writer > > >>a lemon is just a melon in disguise > > >>http://people.redhat.com/kwade/ > > >>gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 > > >> > > >>-- > > >>fedora-selinux-list mailing list > > >>fedora-selinux-list at redhat.com > > >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > >> > > >> > > > > > >-- > > >fedora-selinux-list mailing list > > >fedora-selinux-list at redhat.com > > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From kwade at redhat.com Tue Nov 30 22:01:19 2004 From: kwade at redhat.com (Karsten Wade) Date: Tue, 30 Nov 2004 14:01:19 -0800 Subject: httpd avc denied problem In-Reply-To: <1101849147.3646.6228.camel@erato.phig.org> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker> <1101754789.22761.319.camel@serendipity.dogma.lan> <003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> <006d01c4d655$968db4d0$c600a8c0@tyliteworker> <1101769879.3646.1529.camel@erato.phig.org> <00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org> <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> <41ACC92F.2000102@redhat.com> <013501c4d714$a49e6be0$c600a8c0@tyliteworker> <1101849147.3646.6228.camel@erato.phig.org> Message-ID: <1101852079.3646.6425.camel@erato.phig.org> On Tue, 2004-11-30 at 13:12, Karsten Wade wrote: > chcon -R -t httpd_log_t /var/www/*/logs/* > service httpd start BTW, if this works, you'll want to do something to make the change permanent. Otherwise, the next running of restorecon will hose your configuration. Two options jump to mind: * Move the logs into a path that will receive httpd_log_t, i.e., /var/logs/httpd/ * Install the policy sources (yum install selinux-policy-targeted-sources), and do the following: 1. Edit /etc/selinux/targeted/src/policy/file_contexts/file_contexts 2. Add this line: /var/www/.*/logs(/.*)? system_u:object_r:httpd_log_t Feel free to correct my regexp, but I think it's right. :) 3. In /etc/selinux/targeted/src/policy rebuild the policy with 'make load'. This will build and load the new policy directly into memory. 4. If you now do restorecon, the /var/www/*/logs directories should get the proper context. Be aware that if you make another change to SELinux, especially using system-config-securitylevel, the file /.autorelabel may get created. That triggers a relabeling on reboot, and may hose any manual customizations not fixed in policy. - Karsten -- Karsten Wade, RHCE, Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From dwalsh at redhat.com Tue Nov 30 22:05:24 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 30 Nov 2004 17:05:24 -0500 Subject: httpd avc denied problem In-Reply-To: <1101852079.3646.6425.camel@erato.phig.org> References: <001701c4d642$e8bb4870$c600a8c0@tyliteworker> <1101754789.22761.319.camel@serendipity.dogma.lan> <003801c4d647$c3350370$c600a8c0@tyliteworker> <1101756300.22761.321.camel@serendipity.dogma.lan> <006d01c4d655$968db4d0$c600a8c0@tyliteworker> <1101769879.3646.1529.camel@erato.phig.org> <00c201c4d677$11ca2810$c600a8c0@tyliteworker> <1101819830.3646.4548.camel@erato.phig.org> <012901c4d70f$35d1a6f0$c600a8c0@tyliteworker> <41ACC92F.2000102@redhat.com> <013501c4d714$a49e6be0$c600a8c0@tyliteworker> <1101849147.3646.6228.camel@erato.phig.org> <1101852079.3646.6425.camel@erato.phig.org> Message-ID: <41ACEEA4.8070708@redhat.com> Karsten Wade wrote: >On Tue, 2004-11-30 at 13:12, Karsten Wade wrote: > > > >> chcon -R -t httpd_log_t /var/www/*/logs/* >> service httpd start >> >> > >BTW, if this works, you'll want to do something to make the change >permanent. Otherwise, the next running of restorecon will hose your >configuration. > >Two options jump to mind: > >* Move the logs into a path that will receive httpd_log_t, i.e., >/var/logs/httpd/ > >* Install the policy sources (yum install >selinux-policy-targeted-sources), and do the following: > >1. Edit /etc/selinux/targeted/src/policy/file_contexts/file_contexts > >2. Add this line: >/var/www/.*/logs(/.*)? system_u:object_r:httpd_log_t > >Feel free to correct my regexp, but I think it's right. :) > >3. In /etc/selinux/targeted/src/policy rebuild the policy with 'make >load'. This will build and load the new policy directly into memory. > >4. If you now do restorecon, the /var/www/*/logs directories should get >the proper context. > >Be aware that if you make another change to SELinux, especially using >system-config-securitylevel, the file /.autorelabel may get created. >That triggers a relabeling on reboot, and may hose any manual >customizations not fixed in policy. > >- Karsten > > /.autorelabel will only get created when switching from one type of policy to another (strict <--> targeted) Looking back on this chain, it seems that if he had httpd_unified set it should have been able to write to the log files anyways, This might be a bug in policy?