From russell at coker.com.au Wed Sep 1 06:17:50 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 1 Sep 2004 16:17:50 +1000 Subject: hald/hal-hotplug-map In-Reply-To: <4132465C.6080806@comcast.net> References: <41323F6B.4020701@comcast.net> <4132465C.6080806@comcast.net> Message-ID: <200409011617.50445.russell@coker.com.au> On Mon, 30 Aug 2004 07:10, Tom London wrote: > Oops.... hald.fc should be > # hald - hardware informationd daemon > /usr/sbin/hald -- system_u:object_r:hald_exec_t > /usr/libexec/hal-hotplug-map -- system_u:object_r:hald_exec_t > > Otherwise hal.dev and hal.hotplug get erroneously relabeled. It's a difficult decision about whether to allow hald_t to execute bin_t or to label the file as hald_exec_t. At this time I think that labelling it as hald_exec_t is better as it prevents hald from executing many different program files. I've attached a little patch which implements this. -- 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: hald.diff Type: text/x-diff Size: 1032 bytes Desc: not available URL: From russell at coker.com.au Wed Sep 1 06:37:41 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 1 Sep 2004 16:37:41 +1000 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <41322F5E.90409@comcast.net> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41322F5E.90409@comcast.net> Message-ID: <200409011637.41952.russell@coker.com.au> On Mon, 30 Aug 2004 05:32, Tom London wrote: > --- /root/src.package/policy/domains/program/dbusd.te 2004-08-29 > 11:38:27.000000000 -0700 > +++ dbusd.te 2004-08-29 12:19:25.000000000 -0700 > @@ -32,3 +32,7 @@ > > # SE-DBus specific permissions > allow { dbus_client_domain userdomain } { dbusd_t self }:dbus { send_msg > }; + > +allow user_t etc_dbusd_t:dir { search }; > +allow user_t etc_dbusd_t:file { getattr read }; > +allow user_t user_t:netlink_selinux_socket { bind create }; One thing to remember is that any time you see user_t in policy it's a local customisation or a bug. In this case it seems to me that one correct way of writing policy for this is the following: allow { dbus_client_domain userdomain } etc_dbusd_t:dir { search }; allow { dbus_client_domain userdomain } etc_dbusd_t:file { getattr read }; allow { dbus_client_domain userdomain } user_t:netlink_selinux_socket { bind create }; But then we are granting almost every domain that has any significance in the security of the system read access. So why not just label the files as etc_t and remove the etc_dbusd_t type entirely? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Wed Sep 1 11:33:24 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 01 Sep 2004 07:33:24 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <200409011637.41952.russell@coker.com.au> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41322F5E.90409@comcast.net> <200409011637.41952.russell@coker.com.au> Message-ID: <1094038404.13328.5.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-09-01 at 02:37, Russell Coker wrote: > One thing to remember is that any time you see user_t in policy it's a local > customisation or a bug. > > In this case it seems to me that one correct way of writing policy for this is > the following: > allow { dbus_client_domain userdomain } etc_dbusd_t:dir { search }; > allow { dbus_client_domain userdomain } etc_dbusd_t:file { getattr read }; > allow { dbus_client_domain userdomain } user_t:netlink_selinux_socket { bind > create }; > > But then we are granting almost every domain that has any significance in the > security of the system read access. So why not just label the files as etc_t > and remove the etc_dbusd_t type entirely? These permissions shouldn't be granted directly to the user domains. We need per-userdomain dbusd domains defined via a macro for the per-session message bus. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Sep 1 11:52:10 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 01 Sep 2004 07:52:10 -0400 Subject: Progress! .532 boots! -- but dbus/hotplug/udev problems remain? In-Reply-To: <1094038404.13328.5.camel@moss-spartans.epoch.ncsc.mil> References: <4130CF1B.3090909@comcast.net> <200408291737.17497.russell@coker.com.au> <41322F5E.90409@comcast.net> <200409011637.41952.russell@coker.com.au> <1094038404.13328.5.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1094039529.13328.20.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-09-01 at 07:33, Stephen Smalley wrote: > These permissions shouldn't be granted directly to the user domains. We > need per-userdomain dbusd domains defined via a macro for the > per-session message bus. BTW, note that in the rawhide policy, Dan (or someone) has added a domain_auto_trans(userdomain, dbusd_exec_t, dbusd_t) to dbusd.te as a workaround so that the per-session bus daemons also run in dbusd_t, but that isn't truly what we want in the long term. -- Stephen Smalley National Security Agency From walters at verbum.org Wed Sep 1 14:29:34 2004 From: walters at verbum.org (Colin Walters) Date: Wed, 01 Sep 2004 10:29:34 -0400 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040831224447.GA4964@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> Message-ID: <1094048975.11084.9.camel@nexus.verbum.private> [ The CC list here is rather nuts, someone needs to trim it...] On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote: > Every now and then, I look at SELinux, and I get scared away by its > complexity. It is actually not that complicated, but if you're unfamiliar with mandatory access control (as I was when I first started learning about SELinux), it does require understanding some theory before you dive in. > This complexity makes it very hard to audit, and assure > oneself that its actually providing any real security, as opposed to > the illusion of security. During this email thread, there are > references to mysterious rules that neither party in the conversation > fully understands; this scares me. Because two people in a thread don't understand SELinux, that means that it's too complex? I can certainly find plenty of examples of people not understanding Linux on linux-kernel; does that imply Linux is too complex? > Compare this to less complex security provided by e.g. the Linux > VServer project. VServer is intended to allow an ISP to pretend they > have a rack of 100 cpu's all running linux, when in fact they have just > one. VServer isn't solving the same problem as SELinux. VServer is really a virtualization solution. For example, it would make sense to run *both* a virtualization solution like VServer (or Xen, which looks more promising), and SELinux at the same time. That way, if e.g. the bind daemon running in one of the virtualized servers gets cracked, it doesn't mean a compromise of the whole virtual server. Now, you can use a virtualization technology as a primitive form of separation by running e.g. your MTA in one virtual server, your name server in another, etc. But that's rather painful, and is only an approximation to least privilege. > Another example: Way back in the kernel-2.2 timeframe, I hacked on > something neat: 'LOMAC': if you came in from a network connection, > you lost permission to do almost anything, other than to e.g. webserve. > The system was simple, worked well, the kernel patches were easy to audit, > you could go home without worrying about priveledge escalation. That's also a rather blunt tool; SELinux is much more flexible. > Compare that to this thread, where we are talking about atomic vs. > non-atomic restoration of context for udev-mounted temp file systems. > Shudder. This seems to be begging for an exploit to be discovered. I doubt it. Files created in /dev should have a default type like device_t which most domains will not have access to. > Are we sure that SELinux is really on the right track here? Given the amount of research behind SELinux, and the amount of work being done on it, I think so, yes. From rtroth at bmc.com Wed Sep 1 14:23:42 2004 From: rtroth at bmc.com (Richard Troth) Date: Wed, 1 Sep 2004 09:23:42 -0500 (CDT) Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040831224447.GA4964@austin.ibm.com> References: <20040831224447.GA4964@austin.ibm.com> Message-ID: On Tue, 31 Aug 2004, Linas Vepstas wrote: > Every now and then, I look at SELinux, and I get scared away by its > complexity. This complexity makes it very hard to audit, and assure > oneself that its actually providing any real security, as opposed to > the illusion of security. ... Tough questions. Good questions! Still, I do believe MAC has value in contrast to DAC. But the opposing "flying buttress" to this is that it all boils down to binary ... somewhere. And is THAT part isolated? > Compare this to less complex security provided by e.g. the Linux > VServer project. VServer is intended to allow an ISP to pretend they > have a rack of 100 cpu's all running linux, when in fact they have just > one. The fact that it provides security is a side-effect; but its > far simpler, far easier to audit, and allows me to sleep at night. Ahhh... virtual machines. (And I don't mean Java.) I'm thinking VMware and (esp) z/VM (IBM style mainframe). Been using both or years, VMware since 1.0 beta and mainframe since ... well ... I was pretty young at the time. But not for security per-se, they have other interesting features. Linas' mention of VServer and its side-effect security reminds me of something I read in the anals of VM hisory: http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE (Stephen, Howard, and the rest and friends at the NSA please take no offense. I found this terribly entertaining.) Even from its earliest days, VM (CP) isolated each user, so: "On another occasion we almost had an in-house protest. Among the early users of CP-67/CMS were both the National Security Agency and the CIA; the fact that the DAT hardware isolated each user in his own address space was viewed as a powerful system security feature. One time in 1970, I think, the CIA sent two of their people to Cambridge to talk about something that Ed Hendricks had developed or was working on. In the atmosphere of the time, none of the technical people at CSC, especially Ed, wanted to talk to them at all! Ed stormed around the halls muttering "damned spooks!" for half an hour or more before Craig Johnson and Norm Rasmussen were able to coerce him into the meeting. Even more amazing is that they were spooks; there was a man and a woman, both of slightly below-average height, average build, average everything! You could stand and talk directly to them or study them for five minutes or more, but if you turned around there was nothing to remember and nothing to describe; they were effectively invisible." Thanks to Lynn Wheeler for helping me dig this up. -- R; From russell at coker.com.au Thu Sep 2 12:15:20 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 2 Sep 2004 22:15:20 +1000 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040831224447.GA4964@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> Message-ID: <200409022215.20830.russell@coker.com.au> On Wed, 1 Sep 2004 08:44, Linas Vepstas wrote: > Every now and then, I look at SELinux, and I get scared away by its > complexity. This complexity makes it very hard to audit, and assure What auditing are you referring to? Kernel code, application code, or policy? The application code is not overly complex. The kernel code is as good as such code can be. Tresys http://www.tresys.com/ are developing tools for auditing SE Linux policy. > oneself that its actually providing any real security, as opposed to > the illusion of security. During this email thread, there are > references to mysterious rules that neither party in the conversation > fully understands; this scares me. Which mysterious rules are you referring to? > Compare that to this thread, where we are talking about atomic vs. > non-atomic restoration of context for udev-mounted temp file systems. > Shudder. This seems to be begging for an exploit to be discovered. > Are we sure that SELinux is really on the right track here? The original udev implementation had the device nodes relabelled after creation. As of recent times (since 2002) the default SE Linux policy has denied almost all domains (only two system domains) access to device nodes labelled as device_t. This means that there is no window of opportunity for an attacker to access a device before it is correctly labelled. The worst race condition attack would be a DOS attack, cause an access at the wrong time and have it be denied when otherwise it would be permitted. This is the least serious of all possible problems related to device labelling. -- 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 linas at austin.ibm.com Wed Sep 1 17:25:42 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Wed, 1 Sep 2004 12:25:42 -0500 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <1094048975.11084.9.camel@nexus.verbum.private> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <1094048975.11084.9.camel@nexus.verbum.private> Message-ID: <20040901172542.GH4964@austin.ibm.com> On Wed, Sep 01, 2004 at 10:29:34AM -0400, Colin Walters was heard to remark: > [ The CC list here is rather nuts, someone needs to trim it...] > > On Tue, 2004-08-31 at 17:44 -0500, Linas Vepstas wrote: > > > Every now and then, I look at SELinux, and I get scared away by its > > complexity. > > It is actually not that complicated, but if you're unfamiliar with > mandatory access control (as I was when I first started learning about > SELinux), it does require understanding some theory before you dive in. Hmm, I thought I understood MAC; I was refering to the large numbers of rules in SELinux. Its not obvious (to me) that there isn't a path through those rules that allows privledge escalation. For example: and correct me if I'm wrong, but its quite possible to write a complex rule set that intentionally leaves 'holes' allowing for priveledge escalation. Thus, by extrapolation, its quite possible to write a set of rules that accidentally do the same. When one is presented with a set of rules, how does one know that they don't have a hole? Answer: one audits the rules. Unfortunately, there are a lot of rules: last time I looked at one of the config files, it was thousands of lines long. Thus, a short, simple audit performed by one person seems out of the question. Now, as to auditing... > it's too complex? I can certainly find plenty of examples of people not > understanding Linux on linux-kernel; does that imply Linux is too > complex? We've had a fair number of "eyeballs" read the linux kernel, and thus base our trust in its security on that. However, the SELinux rules are unlike the kernel in an important way: they are config files. This allows allows some anonymous fedora/debian/gentoo maintainer to do something dumb like "gee, my USB camera doesn't work with udev, but then when I change this selinux rule, it does", and poof, you've lost the security. I'm presuming that this kind of mucking around is far more common than altering lines of source in the kernel that weaken security. But I base my presumption on real life: go to any LUG, hang out with any sysadmin long enough, and you will see them make changes to config files that are dangerous if not outright incorrect. Sysadmins are, as a species, people who work with incomplete knowledge of the systems they administer. > > Compare this to less complex security provided by e.g. the Linux > > VServer project. > VServer isn't solving the same problem as SELinux. Yes, that's right. I did try to point that out ... > That way, if e.g. the bind > daemon running in one of the virtualized servers gets cracked, it > doesn't mean a compromise of the whole virtual server. No... If the bind deamon gets cracked, it doesn't compromise the 'whole'; it only compromises root and anything else running in that context. It does not (in theory) compromise root in the other contexts. In other words, one of the servers could be 0wned by someone truly hostile, while the 'whole' remains (theoretically) safe. > Now, you can use a virtualization technology as a primitive form of > separation by running e.g. your MTA in one virtual server, your name > server in another, etc. But that's rather painful, and is only an > approximation to least privilege. Yes, this is exactly what I'm thinking of. But its not painful, it solves 90% or 100% of the needs of a 'typical' ISP/ASP/web server admin. Yes, this is indeed a blunt tool... see below: > > Another example: Way back in the kernel-2.2 timeframe, I hacked on > > something neat: 'LOMAC': if you came in from a network connection, > > you lost permission to do almost anything, other than to e.g. webserve. > > The system was simple, worked well, the kernel patches were easy to audit, > > you could go home without worrying about priveledge escalation. > > That's also a rather blunt tool; SELinux is much more flexible. What I'm proposing here is that bluntness can be traded for increased assurances and increased ability to audit the code for "correctness". Yes, SELinux is far more flexible; but this is exactly what scares me. I once thought about re-implementing LoMAC as a ruleset atop of SELinux. I'm pretty sure that this is possible, but I started thinking that the complexity of the ruleset may introduce holes that voids the effort. And that thought disturbed me. Along with Lomac's 'bluntness' comes 'zero configurability': its something that could be installed on the proverbial 'Grandma's Linux desktop', and provide additional security without causing pain. With selinux, its not only not zero-conf, but its also not clear (to me) if the rulesets that install with debian/fedora/etc. actually provide any additonal security at all against network breakins. If the rulesets do indeed provide this protection, then there is a perception/marketing problem: people like me "don't get it" from just skimming the selinux web pages. I'd prefer to get all the benefits of SELinux without having to RTFM. --linas From 23e9t5t02 at sneakemail.com Thu Sep 2 15:34:56 2004 From: 23e9t5t02 at sneakemail.com (Steve Coleman) Date: Thu, 02 Sep 2004 11:34:56 -0400 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040901172542.GH4964@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <1094048975.11084.9.camel@nexus.verbum.private> <20040901172542.GH4964@austin.ibm.com> Message-ID: <18796-35389@sneakemail.com> Linas Vepstas linas-at-austin.ibm.com |fedora| wrote: > Its not obvious (to me) that there isn't a path > through those rules that allows privledge escalation. > > Unfortunately, there are a lot > of rules: last time I looked at one of the config files, it was > thousands of lines long. Thus, a short, simple audit performed by > one person seems out of the question. Has anyone been working on a graphical representation to the rules and current labeling for visualizing a rulebase/system/runtime configuration? It seems to me that for Fedora/SELinux to go mainstream some form of a visual auditing tool would be required. Being able to take some entity such as a file system or running process and visually displaying the access permissions in the context of privileges granted to a user or process would go a long way towards SE's mainstream adoption. If such a tool were to also help the admin rewrite the rules based on changes to entities while walking down the directory tree it would put SELinux in a much better position for the average admin. Of course such a tool would require careful though in the design due to the desired separation of duties (e.g. auditing vs. administration privs) and the rule definition v.s. Application thereof v.s. the runtime contexts for a given user/process. I have to admit that I have been merely lurking here for a while and have not yet installed SELinux on anything as of yet. My ?lurking? rather than ?doing? is due mostly to my time limitations, and the thought of making my system unusable for my real work because I would have no way to understand all the rules in such short order. If I could see the effects of making a given change (e.g. color coding, symbolic representation) to the system before actually applying that change (relabeling) then I would be much less hesitant to convert everything over to FC2/3 with SELinux as my primary reason for migrating. From what I can see so far SELinux is great stuff, and I praise everyone working on it for such dedicated work! Thanks to all. From sds at epoch.ncsc.mil Thu Sep 2 16:10:30 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 02 Sep 2004 12:10:30 -0400 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040901172542.GH4964@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <1094048975.11084.9.camel@nexus.verbum.private> <20040901172542.GH4964@austin.ibm.com> Message-ID: <1094141429.17265.281.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote: > Hmm, I thought I understood MAC; I was refering to the large numbers of > rules in SELinux. Its not obvious (to me) that there isn't a path > through those rules that allows privledge escalation. > > For example: and correct me if I'm wrong, but its quite possible to > write a complex rule set that intentionally leaves 'holes' allowing > for priveledge escalation. Thus, by extrapolation, its quite possible > to write a set of rules that accidentally do the same. When one is > presented with a set of rules, how does one know that they don't have a > hole? Answer: one audits the rules. Unfortunately, there are a lot > of rules: last time I looked at one of the config files, it was > thousands of lines long. Thus, a short, simple audit performed by > one person seems out of the question. The complexity of the rules reflect the complexity of the existing Linux system and its interactions; SELinux didn't introduce that complexity - SELinux just enables you to control what happens in that complex system. No criticism intended of Linux; the same would apply to any mainstream operating system, and the complexity just reflects real world requirements. And you do have the option of reducing the visible complexity based on your security goals; if you don't care about the interactions among a set of processes/resources, you fold the domain and type space accordingly. The targeted policy is an example of doing that to an extreme. Analysis of that complexity _does_ require automated tools, and such tools exist. apol (yum install setools setools-gui) provides support for analysis, including domain transitions and information flow. slat (available from the NSA SELinux site or MITRE) does security goal checking using a model checker. Gokyo from IBM Watson (which AFAIK is unfortunately not released publically yet, perhaps you could encourage that to happen) analyzes against Biba integrity constraints and identifies exceptions for further examination. > However, the SELinux rules > are unlike the kernel in an important way: they are config files. > This allows allows some anonymous fedora/debian/gentoo maintainer > to do something dumb like "gee, my USB camera doesn't work with udev, > but then when I change this selinux rule, it does", and poof, you've > lost the security. The policy maintainers for the various distros are not anonymous and appear to take their work quite seriously; rejecting policy changes despite a reduction in functionality is not uncommon. You seem to be assuming that policy for each package is maintained by the individual package maintainers; that isn't the case, and likely never will be. Ditto for sysadmins; most of them should never touch policy at all. > What I'm proposing here is that bluntness can be traded for increased > assurances and increased ability to audit the code for "correctness". > Yes, SELinux is far more flexible; but this is exactly what scares me. Reality is complex. Deal with it. Being confident in the correctness of an inadequate security model doesn't help much. > I once thought about re-implementing LoMAC as a ruleset atop of SELinux. > I'm pretty sure that this is possible, but I started thinking that the > complexity of the ruleset may introduce holes that voids the effort. > And that thought disturbed me. It isn't actually possible to implement LOMAC via SELinux, but that's another topic. > Along with Lomac's 'bluntness' comes 'zero configurability': its > something that could be installed on the proverbial 'Grandma's Linux > desktop', and provide additional security without causing pain. Until Grandma wants to do useful work. Simple security models are nice to look at, but they don't capture the behavior of real systems, and it doesn't matter that the model is "secure"; you just break one of the trusted subjects authorized to override the security model in order to get the real work done. SELinux policy may look weaker to you, but it actually represents what is being allowed in the system; no exceptions. -- Stephen Smalley National Security Agency From frasercringan at yahoo.co.uk Thu Sep 2 16:58:37 2004 From: frasercringan at yahoo.co.uk (Fraser Cringan) Date: Thu, 2 Sep 2004 11:58:37 -0500 Subject: unsubscribe In-Reply-To: <1094141429.17265.281.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200409021658.i82Gwrip010771@mx3.redhat.com> -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Stephen Smalley Sent: Thursday, September 02, 2004 11:11 AM To: Fedora SELinux support list for users & developers. Cc: linux-hotplug-devel at lists.sourceforge.net; SELinux; Bill Nottingham; Colin Walters; Nigel Kukard; harald at redhat.com Subject: Re: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] On Wed, 2004-09-01 at 13:25, Linas Vepstas wrote: > Hmm, I thought I understood MAC; I was refering to the large numbers of > rules in SELinux. Its not obvious (to me) that there isn't a path > through those rules that allows privledge escalation. > > For example: and correct me if I'm wrong, but its quite possible to > write a complex rule set that intentionally leaves 'holes' allowing > for priveledge escalation. Thus, by extrapolation, its quite possible > to write a set of rules that accidentally do the same. When one is > presented with a set of rules, how does one know that they don't have a > hole? Answer: one audits the rules. Unfortunately, there are a lot > of rules: last time I looked at one of the config files, it was > thousands of lines long. Thus, a short, simple audit performed by > one person seems out of the question. The complexity of the rules reflect the complexity of the existing Linux system and its interactions; SELinux didn't introduce that complexity - SELinux just enables you to control what happens in that complex system. No criticism intended of Linux; the same would apply to any mainstream operating system, and the complexity just reflects real world requirements. And you do have the option of reducing the visible complexity based on your security goals; if you don't care about the interactions among a set of processes/resources, you fold the domain and type space accordingly. The targeted policy is an example of doing that to an extreme. Analysis of that complexity _does_ require automated tools, and such tools exist. apol (yum install setools setools-gui) provides support for analysis, including domain transitions and information flow. slat (available from the NSA SELinux site or MITRE) does security goal checking using a model checker. Gokyo from IBM Watson (which AFAIK is unfortunately not released publically yet, perhaps you could encourage that to happen) analyzes against Biba integrity constraints and identifies exceptions for further examination. > However, the SELinux rules > are unlike the kernel in an important way: they are config files. > This allows allows some anonymous fedora/debian/gentoo maintainer > to do something dumb like "gee, my USB camera doesn't work with udev, > but then when I change this selinux rule, it does", and poof, you've > lost the security. The policy maintainers for the various distros are not anonymous and appear to take their work quite seriously; rejecting policy changes despite a reduction in functionality is not uncommon. You seem to be assuming that policy for each package is maintained by the individual package maintainers; that isn't the case, and likely never will be. Ditto for sysadmins; most of them should never touch policy at all. > What I'm proposing here is that bluntness can be traded for increased > assurances and increased ability to audit the code for "correctness". > Yes, SELinux is far more flexible; but this is exactly what scares me. Reality is complex. Deal with it. Being confident in the correctness of an inadequate security model doesn't help much. > I once thought about re-implementing LoMAC as a ruleset atop of SELinux. > I'm pretty sure that this is possible, but I started thinking that the > complexity of the ruleset may introduce holes that voids the effort. > And that thought disturbed me. It isn't actually possible to implement LOMAC via SELinux, but that's another topic. > Along with Lomac's 'bluntness' comes 'zero configurability': its > something that could be installed on the proverbial 'Grandma's Linux > desktop', and provide additional security without causing pain. Until Grandma wants to do useful work. Simple security models are nice to look at, but they don't capture the behavior of real systems, and it doesn't matter that the model is "secure"; you just break one of the trusted subjects authorized to override the security model in order to get the real work done. SELinux policy may look weaker to you, but it actually represents what is being allowed in the system; no exceptions. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sklein at cpcug.org Thu Sep 2 18:25:39 2004 From: sklein at cpcug.org (Stanley A. Klein) Date: 02 Sep 2004 14:25:39 -0400 Subject: fedora-selinux-list Digest, Vol 7, Issue 1 In-Reply-To: <20040901160021.BF91F742CF@hormel.redhat.com> References: <20040901160021.BF91F742CF@hormel.redhat.com> Message-ID: <1094149537.2094.81.camel@p500> On Wed, 2004-09-01 at 12:00, Linas Vepstas wrote: > > Every now and then, I look at SELinux, and I get scared away by its > complexity. This complexity makes it very hard to audit, and assure > oneself that its actually providing any real security, as opposed to > the illusion of security. During this email thread, there are > references to mysterious rules that neither party in the conversation > fully understands; this scares me. > This is not the first time I've heard about SELinux complexity. A colleague attended a meeting of the DC area SELinux Users Group and came away repeating stories about 50000 rules that needed to be defined for a typical system. His reaction was "How can you be sure you have done 50000 rules right?". I heard similar talk in the hallway at one of the EGOVOS conferences. I think the complexity derives from Mandatory Access Control rather than SELinux itself. Thus far almost all of the attention regarding SELinux policies has been given to basic computer infrastructure and basic system administration. Some of the packages in the basic infrastructure have hundreds of files. MAC requires each file in each package to be considered and its access control rules defined. The complexity in the rules is a consequence of the complexity in the infrastructure. The real issue is the adequacy of tools to manage the complexity. Furthermore, although SELinux has the mechanisms for defining and enforcing access control rules beyond the basic infrastructure, trying to develop policies based on business process rules and business considerations looks like a daunting task right now. By this I mean roles that get beyond sysadmin and user into areas such as bank teller or hospital primary care provider or control system operations shift supervisor, together with the rules appropriate to those roles in their business contexts. I think there are people working on tool concepts, but it seems we are a few years away from taming the complexity of MAC and SELinux sufficiently to allow users to easily and confidently define SELinux policies for applications based on business considerations. Stan Klein -- Stanley A. Klein, D.Sc. Principal Consultant Stan Klein Associates, LLC 301-881-4087 From linas at austin.ibm.com Thu Sep 2 17:07:34 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Sep 2004 12:07:34 -0500 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <200409022215.20830.russell@coker.com.au> References: <20040830173744.GD10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <200409022215.20830.russell@coker.com.au> Message-ID: <20040902170734.GA9645@austin.ibm.com> On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker was heard to remark: > On Wed, 1 Sep 2004 08:44, Linas Vepstas wrote: > > Every now and then, I look at SELinux, and I get scared away by its > > complexity. This complexity makes it very hard to audit, and assure > > What auditing are you referring to? Kernel code, application code, or policy? policy. > > oneself that its actually providing any real security, as opposed to > > the illusion of security. During this email thread, there are > > references to mysterious rules that neither party in the conversation > > fully understands; this scares me. > > Which mysterious rules are you referring to? I wasn't refering to them, the posters to the thread were. Unfortunately, I've already deleted those emails. > labelled as device_t. This means that there is no window of opportunity for > an attacker to access a device before it is correctly labelled. OK. Well, here's another idle question, again off-topic: Does SELinux provide any sort of assurances that storage media weren't tampered with between reboots? For example, with BIOS/firmware getting more sophisticated over time, there's potential for an attacker to break in, remotely, into bios/firmware, shortly before booting into the OS, and then alter disk contents. Yes, I know this is far-fetched, but was just curious. What got me going on that thread was thinking about udev/hotplug again: with devices coming and going, disappearing and re-appearing, it isn't obvious that there wasn't tampering while the device was gone. Again, excuse me if this sounds naive, un-informed or far-fetched, or terribly off-topic, but: In ye olden days, viruses spread through diskettes. These days, we're plugging-n-playing usb keychains, cameras, ipods, bluetooth this-n-that; although I haven't heard of attacks carried out through these media, its not obivious that these couldn't be carriers for an attack. --linas From linas at austin.ibm.com Thu Sep 2 17:29:07 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 2 Sep 2004 12:29:07 -0500 Subject: Lomac questions [was Re: [OT] SELinux vs. other systems] In-Reply-To: <1094141429.17265.281.camel@moss-spartans.epoch.ncsc.mil> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <1094048975.11084.9.camel@nexus.verbum.private> <20040901172542.GH4964@austin.ibm.com> <1094141429.17265.281.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040902172907.GB9645@austin.ibm.com> Hi Stephen, Excellent answer... its been too long since I've played with selinux. I'll try again. > > I once thought about re-implementing LoMAC as a ruleset atop of SELinux. > > I'm pretty sure that this is possible, but I started thinking that the > > complexity of the ruleset may introduce holes that voids the effort. > > And that thought disturbed me. > > It isn't actually possible to implement LOMAC via SELinux, but that's > another topic. Hmm, why not? > > Along with Lomac's 'bluntness' comes 'zero configurability': its > > something that could be installed on the proverbial 'Grandma's Linux > > desktop', and provide additional security without causing pain. > > Until Grandma wants to do useful work. Simple security models are nice > to look at, but they don't capture the behavior of real systems, and it > doesn't matter that the model is "secure"; you just break one of the > trusted subjects authorized to override the security model in order to > get the real work done. SELinux policy may look weaker to you, but it > actually represents what is being allowed in the system; no exceptions. I don't quite understand this. I'm currently running Lomac on one of my servers, and I can get work done. It seems to be usable, even if it makes some operations, like software install, harder. I'm not sure what you mean by 'break a trusted subject'. If you mean 'ssh is trusted, so if ssh is broken, all hope is lost', then yes. But surely selinux has trusted subjects that may not be trustworthy? If you mean 'lomac provides explicit tools that allow a sysadmin to manually move a file from lower to higher trust domains', then, well, I'm also confused. Surely selinux also has a way to start with something untrusted, and then raise its level ... e.g. to install software downloaded from the net. Is the 'broken-ness' the fact that grandma failed to run an anti-virus scanner and verify checksums, yada yada, before elevating the priveldge on the downloaded software? --linas From lkcl at lkcl.net Thu Sep 2 17:19:35 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 2 Sep 2004 18:19:35 +0100 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <200409022215.20830.russell@coker.com.au> References: <20040830173744.GD10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <200409022215.20830.russell@coker.com.au> Message-ID: <20040902171935.GH5745@lkcl.net> On Thu, Sep 02, 2004 at 10:15:20PM +1000, Russell Coker wrote: > > Compare that to this thread, where we are talking about atomic vs. > > non-atomic restoration of context for udev-mounted temp file systems. > > Shudder. This seems to be begging for an exploit to be discovered. > > Are we sure that SELinux is really on the right track here? > > The original udev implementation had the device nodes relabelled after > creation. As of recent times (since 2002) the default SE Linux policy has > denied almost all domains (only two system domains) access to device nodes > labelled as device_t. This means that there is no window of opportunity for > an attacker to access a device before it is correctly labelled. > > The worst race condition attack would be a DOS attack, cause an access at the > wrong time and have it be denied when otherwise it would be permitted. This > is the least serious of all possible problems related to device labelling. ... and with the use of matchpathcon() followed by setfscreatecon(), it isn't even that: inode, symlink and directory creation-plus-filecontext-setting are done as an atomic operation. problem goes away. the _old_ selinux udev support (0.024), on the other hand, suffered from the big-deal-DOS-attack that russell describes above. l. From lkcl at lkcl.net Thu Sep 2 20:05:40 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Thu, 2 Sep 2004 21:05:40 +0100 Subject: Lomac questions [was Re: [OT] SELinux vs. other systems] In-Reply-To: <20040902172907.GB9645@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <20040831160750.GM11456@lkcl.net> <20040831164635.GK10151@lbsd.net> <20040831191809.GC4375@lkcl.net> <20040831224447.GA4964@austin.ibm.com> <1094048975.11084.9.camel@nexus.verbum.private> <20040901172542.GH4964@austin.ibm.com> <1094141429.17265.281.camel@moss-spartans.epoch.ncsc.mil> <20040902172907.GB9645@austin.ibm.com> Message-ID: <20040902200540.GL5745@lkcl.net> On Thu, Sep 02, 2004 at 12:29:07PM -0500, Linas Vepstas wrote: > Is the 'broken-ness' the fact that grandma failed to run an anti-virus > scanner and verify checksums, yada yada, before elevating the > priveldge on the downloaded software? [this is all with the strict policy 1.14 mostly sortof btw] i've installed clamav, spamassassin, razor and pyzor. oh, and freshclam. i then found a little script called clamassassin [google], i then searched [google] for some advice on how to set up kmail filters. kmail, the clamassassin script and spamc all run under the user context. the user context is given the right to bind to servers. spamd and clamd both run as servers: they have their own policies that restrict their operation to what is known that they presently do, but they are allowed to listen to incoming requests [from spamc and the clamassassin script respectively.] selinux doesn't in the _slightest_ bit get in the way. the only thing that i did find is that razor is a complete pain. it endeavours to write log files into /root/razor.log, /tmp/razor.log, /razor.log, it's a pain, and selinux is _exactly_ the sort of thing that can detect - and stop! - this behaviour. pyzor appears to be a lot less haphazard. also nobody else appears to have tried to run freshclam [automatic update script] before now, so i had to hack the clamav.te policy a bit to get it to run. l. From dp at drak.lbc.cz Thu Sep 2 20:03:40 2004 From: dp at drak.lbc.cz (DP) Date: Thu, 2 Sep 2004 22:03:40 +0200 Subject: RAID HPT370 & Linux Fedora Core 2 Message-ID: <200409022003.i82K3etJ020821@mail.drak.lbc.cz> Hi, I have folowing problem: I built RAID1 in HPT370 controller. After boot from installation CD Linux FC2 not visible in system RAID field, but two physical disks. Help me somebody? Thanks DP From selinux at comcast.net Fri Sep 3 03:30:13 2004 From: selinux at comcast.net (Tom London) Date: Thu, 02 Sep 2004 20:30:13 -0700 Subject: .541 status.... invalid context Message-ID: <4137E545.8020903@comcast.net> Running strict, with latest from Rawhide (except gawk), with selinux-policy-strict-1.17.8-2. After backing out gawk and reinstalling .541, I have a system that boots, but only in permissive mode. In strict mode, many avc's rush past, and then the systems automagically reboots before I have time to examine the screen (nothing makes it to the log). Booting in permissive mode produces scads of avc's. I notice the following on 'make reload' of the policy: Sep 2 20:26:29 fedora kernel: security: 4 users, 6 roles, 1220 types, 23 bools Sep 2 20:26:29 fedora kernel: security: 53 classes, 278677 rules Sep 2 20:26:29 fedora kernel: security: context user_u:user_r:dbusd_t is invalid checkpolicy doesn't seem to complain ..... Anything to worry about? tom From walters at redhat.com Fri Sep 3 04:23:27 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 03 Sep 2004 00:23:27 -0400 Subject: .541 status.... invalid context In-Reply-To: <4137E545.8020903@comcast.net> References: <4137E545.8020903@comcast.net> Message-ID: <1094185407.6963.0.camel@nexus.verbum.private> On Thu, 2004-09-02 at 20:30 -0700, Tom London wrote: > Running strict, with latest from Rawhide (except gawk), with > selinux-policy-strict-1.17.8-2. > > After backing out gawk and reinstalling .541, I have a system that > boots, but only in permissive mode. > > In strict mode, many avc's rush past, and then the systems automagically > reboots before I have time to examine the screen (nothing makes it to > the log). > > Booting in permissive mode produces scads of avc's. > > I notice the following on 'make reload' of the policy: > > Sep 2 20:26:29 fedora kernel: security: 4 users, 6 roles, 1220 types, > 23 bools > Sep 2 20:26:29 fedora kernel: security: 53 classes, 278677 rules > Sep 2 20:26:29 fedora kernel: security: context user_u:user_r:dbusd_t > is invalid Will be fixed soon. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From leonard at den.ottolander.nl Fri Sep 3 12:01:25 2004 From: leonard at den.ottolander.nl (Leonard den Ottolander) Date: Fri, 03 Sep 2004 14:01:25 +0200 Subject: Todays issues with strict policy Message-ID: <1094212884.4751.4.camel@athlon.localdomain> Hi, Noticed a lot of issues with selinux-policy-strict-1.17.8-2 today: Loads of udev related avc denies: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130992 (old bug, new messages) Smartd fails to start: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131696 eth0 doesn't come up at system startup: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131698 Can't login to X because dbus policy incorrect/incomplete: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131701 Leonard. -- mount -t life -o ro /dev/dna /genetic/research From selinux at comcast.net Fri Sep 3 15:43:29 2004 From: selinux at comcast.net (Tom London) Date: Fri, 03 Sep 2004 08:43:29 -0700 Subject: latest Rawhide... selinux-policy-strict-1.17.9-2 Message-ID: <41389121.7070000@comcast.net> Newest Rawhide packages improve things a bit for strict/enforcing, but still no joy. When booting strict/enforcing, the system seems to boot to single user mode, but is unable to write to the console. Last messages are avc denials from /bin/dmesg, that seem to occur just before the 'Welcome to Fedora' message. I can hear the device discovery going on, but nothing on the console. After about 5 minutes, ALT-CTL-DEL brought the system down, with the customary console messages. (But, error messages about most file systems not being mounted). Here are the early avcs... Sep 3 07:25:35 fedora kernel: audit(1094196259.050:0): avc: denied { create } for pid=1 exe=/sbin/init name=initctl scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Opened configuration file /etc/smartd.conf Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { associate } for pid=1 exe=/sbin/init name=initctl scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t tclass=filesystem Sep 3 07:25:36 fedora smartd[2856]: Configuration file /etc/smartd.conf parsed. Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { read write } for pid=1 exe=/sbin/init name=initctl dev=tmpfs ino=2095 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, opened Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { getattr } for pid=1 exe=/sbin/init path=/dev/initctl dev=tmpfs ino=2095 scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t tclass=fifo_file Sep 3 07:25:36 fedora smartd[2856]: Device: /dev/hda, found in smartd database. Sep 3 07:25:36 fedora kernel: audit(1094196259.312:0): avc: denied { read write } for pid=344 exe=/bin/hostname name=console dev=tmpfs ino=864 scontext=system_u:system_r:hostname_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied { search } for pid=346 exe=/bin/bash dev=tmpfs ino=863 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:36 fedora kernel: audit(1094196259.382:0): avc: denied { read write } for pid=346 exe=/bin/bash name=tty dev=tmpfs ino=1227 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:37 fedora smartd[2856]: Device: /dev/hda, is SMART capable. Adding to "monitor" list. Sep 3 07:25:37 fedora kernel: audit(1094196260.276:0): avc: denied { read write } for pid=490 exe=/bin/mount name=console dev=tmpfs ino=864 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:37 fedora smartd[2856]: Monitoring 1 ATA and 0 SCSI devices Sep 3 07:25:37 fedora kernel: audit(1094196260.277:0): avc: denied { search } for pid=490 exe=/bin/mount dev=tmpfs ino=863 scontext=system_u:system_r:mount_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:37 fedora kernel: SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts Sep 3 07:25:38 fedora smartd[2858]: smartd has fork()ed into background mode. New PID=2858. Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { read write } for pid=514 exe=/sbin/consoletype name=console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora smartd: smartd startup succeeded Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { getattr } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196260.368:0): avc: denied { ioctl } for pid=514 exe=/sbin/consoletype path=/dev/console dev=tmpfs ino=864 scontext=system_u:system_r:consoletype_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { read write } for pid=724 exe=/sbin/minilogd name=console dev=tmpfs ino=864 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { use } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17 scontext=system_u:system_r:syslogd_t tcontext=system_u:system_r:kernel_t tclass=fd Sep 3 07:25:38 fedora kernel: audit(1094196262.158:0): avc: denied { read } for pid=724 exe=/sbin/minilogd path=/init dev=rootfs ino=17 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:root_t tclass=file Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { search } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { write } for pid=724 exe=/sbin/minilogd dev=tmpfs ino=863 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { add_name } for pid=724 exe=/sbin/minilogd name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=dir Sep 3 07:25:38 fedora kernel: audit(1094196262.159:0): avc: denied { create } for pid=724 exe=/sbin/minilogd name=log scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=sock_file Sep 3 07:25:38 fedora kernel: audit(1094196262.160:0): avc: denied { getattr } for pid=727 exe=/sbin/minilogd path=/dev/log dev=tmpfs ino=2641 scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:unlabeled_t tclass=sock_file Sep 3 07:25:38 fedora kernel: audit(1094196262.217:0): avc: denied { read write } for pid=730 exe=/bin/dmesg name=console dev=tmpfs ino=864 scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora acpid: acpid startup succeeded Sep 3 07:25:38 fedora kernel: audit(1094196262.285:0): avc: denied { read write } for pid=735 exe=/sbin/restorecon name=console dev=tmpfs ino=864 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:unlabeled_t tclass=chr_file Sep 3 07:25:38 fedora kernel: audit(1094196266.948:0): avc: denied { create } for pid=746 exe=/sbin/udev name=input scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=dir tom From sds at epoch.ncsc.mil Fri Sep 3 16:20:36 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 03 Sep 2004 12:20:36 -0400 Subject: latest Rawhide... selinux-policy-strict-1.17.9-2 In-Reply-To: <41389121.7070000@comcast.net> References: <41389121.7070000@comcast.net> Message-ID: <1094228436.19206.221.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-03 at 11:43, Tom London wrote: > Newest Rawhide packages improve things a bit for strict/enforcing, but > still no joy. > > When booting strict/enforcing, the system seems to boot to single user mode, > but is unable to write to the console. Last messages are avc denials from > /bin/dmesg, that seem to occur just before the 'Welcome to Fedora' message. > I can hear the device discovery going on, but nothing on the console. > After about 5 minutes, ALT-CTL-DEL brought the system down, with the > customary console messages. (But, error messages about most file systems > not being mounted). > > Here are the early avcs... > > Sep 3 07:25:35 fedora kernel: audit(1094196259.050:0): avc: denied { > create } for pid=1 exe=/sbin/init name=initctl > scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t > tclass=fifo_file > Sep 3 07:25:36 fedora smartd[2856]: Opened configuration file > /etc/smartd.conf > Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { > associate } for pid=1 exe=/sbin/init name=initctl > scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t > tclass=filesystem No point in even trying to work from those audit messages, as the tmpfs entry in fs_use in the rawhide policy is wrong and will break all users of anonymous shared mappings and System V shared memory regardless of whether it ever works for tmpfs /dev. And life is still rather unpleasant even if fs_use is reverted to the upstream policy. Using fscontext=system_u:object_r:device_t on the tmpfs /dev mount would help significantly, but the claim is that it is mounted before the initial policy load. End result is that tmpfs_t ends up doing double duty as a type on shmem and /dev, which has a huge impact on existing policy. Strongly advise changing initialization to umount the initial tmpfs /dev prior to initrd exit and re-mount it _after_ the initial policy load using fscontext=. Or load a minimal policy from the initrd in your /linuxrc prior to original tmpfs mount. -- Stephen Smalley National Security Agency From russell at coker.com.au Sat Sep 4 08:49:09 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 4 Sep 2004 18:49:09 +1000 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <20040902170734.GA9645@austin.ibm.com> References: <20040830173744.GD10151@lbsd.net> <200409022215.20830.russell@coker.com.au> <20040902170734.GA9645@austin.ibm.com> Message-ID: <200409041849.09954.russell@coker.com.au> On Fri, 3 Sep 2004 03:07, Linas Vepstas wrote: > Well, here's another idle question, again off-topic: Does SELinux provide > any sort of assurances that storage media weren't tampered with between > reboots? No, that is outside the scope of the SE Linux project. I am one of the many people in Red Hat who are involved in working on crypto block device support. One of my own systems has a root file system that is AES encrypted with the kernel and initrd (which includes the decryption key) on removable media. Eventually I want to see this become a standard feature of Fedora, maybe in FC4. I think it will address most of what you want in this regard. Note that the NSA guys do not talk to me about any security stuff, so I don't expect them to have any involvement in such things. > For example, with BIOS/firmware getting more sophisticated over time, > there's potential for an attacker to break in, remotely, into > bios/firmware, shortly before booting into the OS, and then alter > disk contents. Yes, I know this is far-fetched, but was just curious. When booting from removable media that contains the decryption key the attack scenario would be to replace the BIOS with one that sends everything it reads from disk (IE everything that the boot loader reads) over an Ethernet interface. A trojan BIOS that modifies the kernel during the boot load process to introduce a security hole would be doable if you have adequate resources. -- 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 fedora-se-linux at dalini.de Sat Sep 4 10:54:43 2004 From: fedora-se-linux at dalini.de (Ives Steglich) Date: Sat, 04 Sep 2004 12:54:43 +0200 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <200409041849.09954.russell@coker.com.au> References: <20040830173744.GD10151@lbsd.net> <200409022215.20830.russell@coker.com.au> <20040902170734.GA9645@austin.ibm.com> <200409041849.09954.russell@coker.com.au> Message-ID: <41399EF3.609@dalini.de> Russell Coker wrote: > When booting from removable media that contains the decryption key the attack > scenario would be to replace the BIOS with one that sends everything it reads > from disk (IE everything that the boot loader reads) over an Ethernet > interface. > > A trojan BIOS that modifies the kernel during the boot load process to > introduce a security hole would be doable if you have adequate resources. > there is a second option (also bios and startup related): you can put an additional pci-extension-bios to any pci-card which have a own pci-extension-bios for setting up its hardware, the chips are usaly 64k but not fully used (graficcard, networkcard, ...) and the point is, the standard allows you to put several pci-extension-bios-images into one of such eeproms which just point to each other and get called through the main-bios so its not really necessary to exchange the system bios, get your hands on a pci-card with a extension-bios may be enough... so keep your eyes open if you change hardware ;) and this is working practical, i have written a pci-extension-bios which actuly was sitting at (in this case) the network card for reading/setting bios-settings (nvram) during boot-up process at the serial port some years ago (was for some semiautomatic setting up process of 'black-box' hardware with no keyboard monitors attached to it) ok - second problem here, would be getting the code surviving in ram the boot-up sequence of the operating system, but i'm sure this won't be any problem for some ppl with the necessary skills i'm not sure about the pci-x-standard, but i think this could be working similar greetings dalini From jim-cornette at sbcglobal.net Sun Sep 5 02:25:27 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 04 Sep 2004 22:25:27 -0400 Subject: Kernel *-541 - avc errors - busts inodes - kills X11 Message-ID: <413A7917.9030703@sbcglobal.net> When I booted up with the latest development kernel -541, I got the following avc errors. Also, I ended up damaging my installation. The first attached file is from the first boot and encountering errors. I'll send a second message with the after relabeling filesystem errors. Here is the first boot avc errors file from initial boot. mode is enforcing/targeted Jim -- You're at the end of the road again. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 541-avc.txt URL: From jim-cornette at sbcglobal.net Sun Sep 5 02:30:41 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 04 Sep 2004 22:30:41 -0400 Subject: Kernel *-541 - avc errors - ... after fsck,reboot,fixfiles,reboot Message-ID: <413A7A51.5030805@sbcglobal.net> When I booted up with the latest development kernel -541, I got the following avc errors. Also, I ended up damaging my installation. The first attached file is from the first boot and encountering errors. I'll send a second message with the after relabeling filesystem errors. Here is the second avc error file. The system was fscked to eliminate errors. (Also was dropped to init 1 because of file errors) Bad inodes were detected, so I rebooted and did fixfiles relabel. After that, I rebooted and logged in again. X would not startup, it hung at switching to graphics and could not event be pinged from another computer on my network. (Locked up, I presume.) Jim -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 541-avc-fdsk.txt URL: From jim-cornette at sbcglobal.net Sun Sep 5 03:22:47 2004 From: jim-cornette at sbcglobal.net (Jim Cornette) Date: Sat, 04 Sep 2004 23:22:47 -0400 Subject: Wiped installation - 541 kernel - SELinux cleared? Message-ID: <413A8687.8070600@sbcglobal.net> After viewing the logs myself, I think that SELinux was working properly. I deleted the installation and am using it as a clean download partition for the FC3T2 iso files. It looks like SELInux is working pretty decent up until gawk, the latest kernel, etc: Jim -- You're at the end of the road again. From russell at coker.com.au Sun Sep 5 10:45:46 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 5 Sep 2004 20:45:46 +1000 Subject: log file names (was Additional rule files) In-Reply-To: <1094260356.29689.44.camel@wintermute.xmldesign.de> References: <1094260356.29689.44.camel@wintermute.xmldesign.de> Message-ID: <200409052045.46899.russell@coker.com.au> On Sat, 4 Sep 2004 11:12, Erich Schubert wrote: > The next two rule sets are for the statistic tools "bindgraph" and > "mailgraph". The first parses bind query logs and does nice graphs out > of them, the second does the same for postfix+amavis logs. Do we need to have two different domains for programs that do the same thing? Both bindgraph and mailgraph can read the same file types as input and their output can be accessed by cgi-bin scripts. It seems that there is little (if any) benefit in isolating them. If we were to assign different types to different log files (may require code changes in syslogd) then we could deny the mailgraph program the ability to read log files other than mail.log and deny the bindgraph program the ability to read mail.log. Also note that in your policy both those programs can read /var/log/auth.log (Debian) and /var/log/secure (Fedora). This is not desirable, we probably should make changes to the syslog setup. One possible change is greater use of sub-directories in /var/log. We could have /var/log/security/ for auth.log, secure, and any other security critical log files and /var/log/mail/ for mail server log files (including POP server, and maybe webmail), etc. Doing this would allow different types for the log files with no code changes to syslogd, and this would make it more beneficial to have separate domains for mailgraph and bindgraph. I've CC'd this to fedora-selinux and debian-devel because if we make such changes then we want to get some cross-distribution agreement on file names. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sun Sep 5 12:52:52 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 5 Sep 2004 22:52:52 +1000 Subject: Is anyone using Selinux for VOIP applications? In-Reply-To: <00ab01c4933f$c66e32f0$0a01a8c0@huey> References: <1094260356.29689.44.camel@wintermute.xmldesign.de> <200409052045.46899.russell@coker.com.au> <00ab01c4933f$c66e32f0$0a01a8c0@huey> Message-ID: <200409052252.52432.russell@coker.com.au> On Sun, 5 Sep 2004 21:59, "Joop" wrote: > Is anyone using Selinux for VOIP applications at present? If so please > contact me off the list. I am looking at Asterisk, Ser etc. I've written SE Linux policy for Asterisk. I haven't had the time to set it up fully though, so some aspects of Asterisk functionality probably don't work yet. Try it out and let me know how it goes. I'll fix any bugs you report in the Asterisk policy. -- 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 Sep 7 09:48:18 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 7 Sep 2004 19:48:18 +1000 Subject: fedora-selinux-list Digest, Vol 7, Issue 1 In-Reply-To: <1094149537.2094.81.camel@p500> References: <20040901160021.BF91F742CF@hormel.redhat.com> <1094149537.2094.81.camel@p500> Message-ID: <200409071948.18983.russell@coker.com.au> On Fri, 3 Sep 2004 04:25, "Stanley A. Klein" wrote: > On Wed, 2004-09-01 at 12:00, Linas Vepstas wrote: > > Every now and then, I look at SELinux, and I get scared away by its > > complexity. This complexity makes it very hard to audit, and assure > > oneself that its actually providing any real security, as opposed to > > the illusion of security. During this email thread, there are > > references to mysterious rules that neither party in the conversation > > fully understands; this scares me. > > This is not the first time I've heard about SELinux complexity. A > colleague attended a meeting of the DC area SELinux Users Group and came > away repeating stories about 50000 rules that needed to be defined for a > typical system. His reaction was "How can you be sure you have done > 50000 rules right?". I heard similar talk in the hallway at one of the > EGOVOS conferences. What about the stories of systems of 130,000 files where the permissions of each file matters? How can you be sure that you have done 130,000 file permissions right? :-# A minimal Linux install has 130,000 files... SE Linux has assertion rules to prevent you doing something really stupid. The rule "allow domain shadow_t:file create_file_perms;" will not be compiled because of the assertions. The command "chmod 4777 /bin/foo" can be executed on any typical Unix system. The SE Linux policy can be analysed with apol or slat. These tools allow you to determine what access is granted from a particular domain. To attempt to perform such analysis of Unix permissions you need to start with a "find /" operation to discover what access is granted. On some systems "find /" is not feasible (I used to run a system where according to my best estimates "find /" would take more than 10 days to complete while hurting system performance enough to get the direct attention of the CEO), in which case analysing the Unix permissions can not be done. You (as the administrator of a SE Linux system) do not have to write 50,000 rules. Many of the rules in the binary policy are expansions from simple rules in the policy language. A rule such as "allow user_t domain:dir { search getattr read };" may expand to 300 rules (one for each domain) in the policy binary (depending on how many domains are in the policy). Then there's the macro language, if you want to allow user_t to see all domains in the output of "ps" then you use the macro invocation "can_ps(user_t, domain)" which expands to four rules in the policy.conf file which are then multiplied by the 300 domains to give 1200 rules in the policy binary (from one line of source which is easy to verify). Also 99.99% of the policy is already there and has been well checked. The amount of changes you need to make to the default policy should be rather small and therefore easy to check. > I think the complexity derives from Mandatory Access Control rather than > SELinux itself. Thus far almost all of the attention regarding SELinux > policies has been given to basic computer infrastructure and basic > system administration. Some of the packages in the basic infrastructure > have hundreds of files. MAC requires each file in each package to be > considered and its access control rules defined. The complexity in the > rules is a consequence of the complexity in the infrastructure. Yes. > The real issue is the adequacy of tools to manage the complexity. I believe that the tools to manage SE Linux policy are more adequate than the tools to manage Unix permissions. > Furthermore, although SELinux has the mechanisms for defining and > enforcing access control rules beyond the basic infrastructure, trying > to develop policies based on business process rules and business > considerations looks like a daunting task right now. By this I mean > roles that get beyond sysadmin and user into areas such as bank teller > or hospital primary care provider or control system operations shift > supervisor, together with the rules appropriate to those roles in their > business contexts. Why would you need anything special for that? It's just a matter of having a SE Linux role to match the use of the system and some rules to allow access to the appropriate files, databases, etc which are appropriate for that role. > I think there are people working on tool concepts, but it seems we are a > few years away from taming the complexity of MAC and SELinux > sufficiently to allow users to easily and confidently define SELinux > policies for applications based on business considerations. I agree that there is more work to be done in this area. However people have been using systems based solely on Unix permissions without any such tools for many years. It would be nice to have a tool to analyse access transitions via SETUID programs on a Unix system in the same way that slat and apol can analyse the SE Linux policy. -- 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 dalini at datenschleuder.org Sat Sep 4 10:47:39 2004 From: dalini at datenschleuder.org (dalini) Date: Sat, 04 Sep 2004 12:47:39 +0200 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <200409041849.09954.russell@coker.com.au> References: <20040830173744.GD10151@lbsd.net> <200409022215.20830.russell@coker.com.au> <20040902170734.GA9645@austin.ibm.com> <200409041849.09954.russell@coker.com.au> Message-ID: <41399D4B.9060501@datenschleuder.org> Russell Coker wrote: > When booting from removable media that contains the decryption key the attack > scenario would be to replace the BIOS with one that sends everything it reads > from disk (IE everything that the boot loader reads) over an Ethernet > interface. > > A trojan BIOS that modifies the kernel during the boot load process to > introduce a security hole would be doable if you have adequate resources. > there is a second option (also bios and startup related): you can put an additional pci-extension-bios to any pci-card which have a own pci-extension-bios for setting up its hardware, the chips are usaly 64k but not fully used (graficcard, networkcard, ...) and the point is, the standard allows you to put several pci-extension-bios-images into one of such eeproms which just point to each other and get called through the main-bios so its not really necessary to exchange the system bios, get your hands on a pci-card with a extension-bios may be enough... so keep your eyes open if you change hardware ;) and this is working practical, i have written a pci-extension-bios which actuly was sitting at (in this case) the network card for reading/setting bios-settings (nvram) during boot-up process at the serial port some years ago (was for some semiautomatic setting up process of 'black-box' hardware with no keyboard monitors attached to it) ok - second problem here, would be getting the code surviving in ram the boot-up sequence of the operating system, but i'm sure this won't be any problem for some ppl with the necessary skills i'm not sure about the pci-x-standard, but i think this could be working similar greetings dalini From joop at fttp.ca Sun Sep 5 11:59:18 2004 From: joop at fttp.ca (Joop) Date: Sun, 5 Sep 2004 05:59:18 -0600 Subject: Is anyone using Selinux for VOIP applications? References: <1094260356.29689.44.camel@wintermute.xmldesign.de> <200409052045.46899.russell@coker.com.au> Message-ID: <00ab01c4933f$c66e32f0$0a01a8c0@huey> Is anyone using Selinux for VOIP applications at present? If so please contact me off the list. I am looking at Asterisk, Ser etc. Joop From selinux at comcast.net Tue Sep 7 15:30:58 2004 From: selinux at comcast.net (Tom London) Date: Tue, 07 Sep 2004 08:30:58 -0700 Subject: relabeling cycles... Message-ID: <413DD432.5020700@comcast.net> No matter how often I 'fix' these files with either setfiles or fixfiles, they seem to revert back the next reboot. I think I've also booted single-user to do relabeling with the same effect. Not clear this affects functioning in any way. tom > /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux.accept from > system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t > /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux from > system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t > /usr/sbin/setfiles: relabeling /tmp/.X11-unix from > system_u:object_r:xdm_tmp_t > to system_u:object_r:xdm_xserver_tmp_t > /usr/sbin/setfiles: relabeling /tmp/.X0-lock from > system_u:object_r:xdm_xserver_tmp_t to system_u:object_r:xdm_tmp_t From mayerf at tresys.com Tue Sep 7 21:10:10 2004 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 7 Sep 2004 17:10:10 -0400 Subject: (no subject) Message-ID: <02c601c4951f$1041d090$a00c010a@columbia.tresys.com> CALL FOR PRESENTATION PROPOSALS FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) The inaugural symposium on Security Enhanced Linux (SELinux) will be held March 2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux brings the power of flexible mandatory access control such as type enforcement to Linux. The symposium is an opportunity to learn about SELinux and share technical and application experiences. The call for presentation and tutorial proposals is now open until October 1, 2004. All proposals will be reviewed by the review committees for inclusion in the symposium agenda. To submit proposals visit http://www.selinux-symposium.org. From mayerf at tresys.com Tue Sep 7 21:15:29 2004 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 7 Sep 2004 17:15:29 -0400 Subject: SELinux Symposium Call for Presentation Proposals Message-ID: <02c701c4951f$cd8cad50$a00c010a@columbia.tresys.com> CALL FOR PRESENTATION PROPOSALS FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) The inaugural symposium on Security Enhanced Linux (SELinux) will be held March 2-4 2005 in the Silver Spring, Maryland, USA (near Washington, DC). SELinux brings the power of flexible mandatory access control such as type enforcement to Linux. The symposium is an opportunity to learn about SELinux and share technical and application experiences. The call for presentation and tutorial proposals is now open until October 1, 2004. All proposals will be reviewed by the review committees for inclusion in the symposium agenda. To submit proposals visit http://www.selinux-symposium.org. From don.patterson at tresys.com Tue Sep 7 21:28:40 2004 From: don.patterson at tresys.com (Don Patterson) Date: Tue, 7 Sep 2004 17:28:40 -0400 Subject: Users writting to home directory Message-ID: <20040907212840.QSES1729.mm-ismta3.bizmailsrvcs.net@ICEMAN> > ----- Original Message ----- > From: "James R. Marcus" > To: "Stephen Smalley" > Cc: > Sent: Tuesday, August 24, 2004 2:14 PM > Subject: RE: Users writting to home directory > > > > Okay I tried just creating a user under home. While in permissive > > mode they can login to the ftp server and upload and download. > > However when I turn on enforced mode they get this message: > > > > C:\Documents and Settings\jmarcus\Desktop>ftp ftp Connected to > > ftp.mvalent.local. > > 220 Welcome to mValent, Inc. FTP service. > > User (ftp.mvalent.local:(none)): jmarcus7 > > 331 Please specify the password. > > Password: > > 500 OOPS: cannot change directory:/home/jmarcus7 500 OOPS: child > > died Connection closed by remote host. > > > > C:\Documents and Settings\jmarcus\Desktop> > > > > ftp policy # seuseradd -g users -d /home/jmarcus7 -m -s /bin/bash > > -c "James R. Marcus" jmarcus7 loading new policy... > > > > Error relabeling users home directory files: User is not defined in > > the policy. > > > In case anyone sees a similar problem, this bug was fixed in setools 1.4.x. To upgrade use the commands: Fedora - 'yum update setools' Gentoo - 'emerge setools' Don Patterson Tresys Technology www.tresys.com From mayerf at tresys.com Tue Sep 7 21:35:25 2004 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 7 Sep 2004 17:35:25 -0400 Subject: SELinux article in eWeek Message-ID: <02ca01c49522$96f03d90$a00c010a@columbia.tresys.com> Not a depth article but generally favorable review of SELinux: http://www.eweek.com/article2/0,1759,1643024,00.asp Frank From russell at coker.com.au Wed Sep 8 09:01:21 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 8 Sep 2004 19:01:21 +1000 Subject: [OT] SELinux vs. other systems [was Re: [idea] udev + selinux] In-Reply-To: <41399EF3.609@dalini.de> References: <20040830173744.GD10151@lbsd.net> <200409041849.09954.russell@coker.com.au> <41399EF3.609@dalini.de> Message-ID: <200409081901.21556.russell@coker.com.au> On Sat, 4 Sep 2004 20:54, Ives Steglich wrote: > there is a second option (also bios and startup related): > > you can put an additional pci-extension-bios to any pci-card which have > a own pci-extension-bios for setting up its hardware, the chips are > usaly 64k but not fully used (graficcard, networkcard, ...) and the Good point. However one limitation of this is that it won't work so well for laptops. The idea of replacing a BIOS was first suggested to me after a discussion of an advertised security product which had some very suspect claims about it's performance. The claim that it could survive a re-install of Windows seemed difficult to believe and a modified BIOS was the only suggestion of a possible way of doing it. > second problem here, would be getting the code surviving in ram > the boot-up sequence of the operating system, but i'm sure this won't be > any problem for some ppl with the necessary skills That is solvable too. It would have to decompress the kernel image, modify the kernel code in some subtle way (EG making some security check function in the kernel be a noop), re-compress the kernel image and then present it to the boot loader upon read requests. It's difficult, but not impossible. -- 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 dwalsh at redhat.com Thu Sep 9 14:02:37 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Sep 2004 10:02:37 -0400 Subject: latest Rawhide... selinux-policy-strict-1.17.9-2 In-Reply-To: <1094228436.19206.221.camel@moss-spartans.epoch.ncsc.mil> References: <41389121.7070000@comcast.net> <1094228436.19206.221.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4140627D.5020905@redhat.com> Stephen Smalley wrote: >On Fri, 2004-09-03 at 11:43, Tom London wrote: > > >>Newest Rawhide packages improve things a bit for strict/enforcing, but >>still no joy. >> >>When booting strict/enforcing, the system seems to boot to single user mode, >>but is unable to write to the console. Last messages are avc denials from >>/bin/dmesg, that seem to occur just before the 'Welcome to Fedora' message. >>I can hear the device discovery going on, but nothing on the console. >>After about 5 minutes, ALT-CTL-DEL brought the system down, with the >>customary console messages. (But, error messages about most file systems >>not being mounted). >> >>Here are the early avcs... >> >>Sep 3 07:25:35 fedora kernel: audit(1094196259.050:0): avc: denied { >>create } for pid=1 exe=/sbin/init name=initctl >>scontext=system_u:system_r:init_t tcontext=system_u:object_r:unlabeled_t >>tclass=fifo_file >>Sep 3 07:25:36 fedora smartd[2856]: Opened configuration file >>/etc/smartd.conf >>Sep 3 07:25:36 fedora kernel: audit(1094196259.050:0): avc: denied { >>associate } for pid=1 exe=/sbin/init name=initctl >>scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:fs_t >>tclass=filesystem >> >> > >No point in even trying to work from those audit messages, as the tmpfs >entry in fs_use in the rawhide policy is wrong and will break all users >of anonymous shared mappings and System V shared memory regardless of >whether it ever works for tmpfs /dev. > >And life is still rather unpleasant even if fs_use is reverted to the >upstream policy. Using fscontext=system_u:object_r:device_t on the >tmpfs /dev mount would help significantly, but the claim is that it is >mounted before the initial policy load. End result is that tmpfs_t ends >up doing double duty as a type on shmem and /dev, which has a huge >impact on existing policy. > >Strongly advise changing initialization to umount the initial tmpfs /dev >prior to initrd exit and re-mount it _after_ the initial policy load >using fscontext=. Or load a minimal policy from the initrd in your >/linuxrc prior to original tmpfs mount. > > > Most of the problems with booting strict SELinux with /dev/ mounted on a tmpfs file system should be fixed by the latest policy and initscripts package. Dan From selinux at gmail.com Thu Sep 9 17:31:09 2004 From: selinux at gmail.com (Tom London) Date: Thu, 9 Sep 2004 10:31:09 -0700 Subject: Strict/enforcing.... ifconfig.te In-Reply-To: <4140627D.5020905@redhat.com> References: <41389121.7070000@comcast.net> <1094228436.19206.221.camel@moss-spartans.epoch.ncsc.mil> <4140627D.5020905@redhat.com> Message-ID: <4c4ba15304090910317847d38e@mail.gmail.com> Dan, [Rawhide repo seems to be down, so I may have incomplete download state...] running .541, strict enforcing. Installed latest stuff from your tree, and applied patches you sent out later. Strict/enforcing now boots up to X/Gnome. (Can login and everything!). Early failure configuring NICs. Suggest: --- ifconfig.te 2004-09-08 11:05:53.000000000 -0700 +++ ifconfig.te.new 2004-09-09 10:28:05.467768274 -0700 @@ -24,7 +24,7 @@ domain_auto_trans(sysadm_t, ifconfig_exec_t, ifconfig_t) # for /sbin/ip -allow ifconfig_t self:netlink_route_socket { bind create getattr nlmsg_read nlmsg_write read write }; +allow ifconfig_t self:netlink_route_socket { bind create getattr nlmsg_read nlmsg_write read write setopt }; allow ifconfig_t self:tcp_socket { create ioctl }; allow ifconfig_t etc_t:file { getattr read }; [I'm sorry if I missed this in your patches. I applied them manually, so I may have missed this one.] -- Tom London From dwalsh at redhat.com Thu Sep 9 19:07:08 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Sep 2004 15:07:08 -0400 Subject: relabeling cycles... In-Reply-To: <413DD432.5020700@comcast.net> References: <413DD432.5020700@comcast.net> Message-ID: <4140A9DC.7020206@redhat.com> Tom London wrote: > No matter how often I 'fix' these files with either setfiles or fixfiles, > they seem to revert back the next reboot. I think I've also booted > single-user to do relabeling with the same effect. > > Not clear this affects functioning in any way. > > tom > >> /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux.accept from >> system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t >> /usr/sbin/setfiles: relabeling /var/run/saslauthd/mux from >> system_u:object_r:saslauthd_var_run_t to system_u:object_r:var_run_t >> /usr/sbin/setfiles: relabeling /tmp/.X11-unix from >> system_u:object_r:xdm_tmp_t >> to system_u:object_r:xdm_xserver_tmp_t >> /usr/sbin/setfiles: relabeling /tmp/.X0-lock from >> system_u:object_r:xdm_xserver_tmp_t to system_u:object_r:xdm_tmp_t > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list I will fix these in policy file context. From russell at coker.com.au Thu Sep 9 19:36:59 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 05:36:59 +1000 Subject: tmpfs /dev Message-ID: <200409100536.59711.russell@coker.com.au> I have got a working system with tmpfs /dev and with udev in the initrd. I modified /sbin/init to run the following script immediately after loading the policy: #!/bin/sh . /etc/selinux/config /sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev Naturally we need to change the location of setfiles to /sbin from /usr/sbin if this is the solution we choose as this script will run before any file systems are mounted. Below is the policy I added. I had already changed the type declarations to use the dev_filesystem attribute for everything that may occur under /dev (patch sent to the main SE Linux list). I have setfiles being run as kernel_t because I feel that running setfiles as kernel_t is better than granting setfiles_t more access than is otherwise required. This means that I have to grant kernel_t access to relabel the device nodes, no big deal IMHO as kernel_t generally has ultimate access anyway. I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run from /sbin/start_udev and can do the things that it wants to do. This is a minor hack. Maybe it would be better to label /sbin/start_udev as udev_exec_t? That would remove the need to allow initrc_t to create sym-links under /dev. avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t tcontext=system_u:object_r:udev_exec_t tclass=file Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me. Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't split it into all the relevant .te files because it's still an experiment at this stage. After some discussion I'll produce a release version. # for tmpfs /dev allow dev_filesystem tmpfs_t:filesystem associate; allow kernel_t tmpfs_t:chr_file rw_file_perms; allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr relabel from }; allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto; allow kernel_t device_type:{ chr_file blk_file } relabelto; allow kernel_t udev_tbl_t:file relabelto; can_exec(kernel_t, { sbin_t setfiles_exec_t }) # for /dev/pts on tmpfs allow mount_t tmpfs_t:dir mounton; # for /sbin/MAKEDEV - why? allow lvm_t udev_exec_t:file getattr; # allow /sbin/start_udev to run ln allow initrc_t device_t:lnk_file create_lnk_perms; -- 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 dwalsh at redhat.com Thu Sep 9 20:19:04 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Sep 2004 16:19:04 -0400 Subject: tmpfs /dev In-Reply-To: <200409100536.59711.russell@coker.com.au> References: <200409100536.59711.russell@coker.com.au> Message-ID: <4140BAB8.8070808@redhat.com> Russell Coker wrote: >I have got a working system with tmpfs /dev and with udev in the initrd. I >modified /sbin/init to run the following script immediately after loading the >policy: > >#!/bin/sh >. /etc/selinux/config >/sbin/setfiles-mine /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts /dev > >Naturally we need to change the location of setfiles to /sbin from /usr/sbin >if this is the solution we choose as this script will run before any file >systems are mounted. > >Below is the policy I added. I had already changed the type declarations to >use the dev_filesystem attribute for everything that may occur under /dev >(patch sent to the main SE Linux list). I have setfiles being run as >kernel_t because I feel that running setfiles as kernel_t is better than >granting setfiles_t more access than is otherwise required. This means that >I have to grant kernel_t access to relabel the device nodes, no big deal IMHO >as kernel_t generally has ultimate access anyway. > >I relabeled /sbin/MAKEDEV as udev_exec_t so that it runs as udev_t when run >from /sbin/start_udev and can do the things that it wants to do. This is a >minor hack. Maybe it would be better to label /sbin/start_udev as >udev_exec_t? That would remove the need to allow initrc_t to create >sym-links under /dev. > >avc: denied { getattr } for pid=1641 exe=/sbin/lvm.static >path=/sbin/MAKEDEV dev=dm-0 ino=196261 scontext=system_u:system_r:lvm_t >tcontext=system_u:object_r:udev_exec_t tclass=file > >Why does lvm.static want to stat /sbin/MAKEDEV? Seems strange to me. > >Below is the policy I wrote to allow tmpfs /dev and udev in initrd. I haven't >split it into all the relevant .te files because it's still an experiment at >this stage. After some discussion I'll produce a release version. > ># for tmpfs /dev >allow dev_filesystem tmpfs_t:filesystem associate; >allow kernel_t tmpfs_t:chr_file rw_file_perms; >allow kernel_t tmpfs_t:{ dir file lnk_file chr_file blk_file } { getattr >relabel >from }; >allow kernel_t device_t:{ dir lnk_file chr_file blk_file } relabelto; >allow kernel_t device_type:{ chr_file blk_file } relabelto; >allow kernel_t udev_tbl_t:file relabelto; >can_exec(kernel_t, { sbin_t setfiles_exec_t }) ># for /dev/pts on tmpfs >allow mount_t tmpfs_t:dir mounton; ># for /sbin/MAKEDEV - why? >allow lvm_t udev_exec_t:file getattr; ># allow /sbin/start_udev to run ln >allow initrc_t device_t:lnk_file create_lnk_perms; > > > You will need to talk to Bill Nottingham about modifying /sbin/init to do this. They are not crazy about putting additional code into /sbin/init since it is very hard to debug. They prefer rc.sysinit. They also do not want to relabel the /dev file system if it is not a tmpfs, since with 8000 or more files it could take a while and slow down the boot up. The modification that we are currently using only modifies rc.sysinit to do a restorecon on /dev/* when it is tmpfs and adds a couple of allows for hostname, init, mount and consoletype to use tmpfs_t. Dan From russell at coker.com.au Fri Sep 10 05:08:27 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 10 Sep 2004 15:08:27 +1000 Subject: tmpfs /dev In-Reply-To: <4140BAB8.8070808@redhat.com> References: <200409100536.59711.russell@coker.com.au> <4140BAB8.8070808@redhat.com> Message-ID: <200409101508.27612.russell@coker.com.au> On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > You will need to talk to Bill Nottingham about modifying /sbin/init to > do this. They are not crazy about > putting additional code into /sbin/init since it is very hard to debug. We've done it once, we can do it again. > They prefer rc.sysinit. They also do not rc.sysinit means changing the policy for init_t, initrc_t, and maybe others. > want to relabel the /dev file system if it is not a tmpfs, since with > 8000 or more files it could take a while and > slow down the boot up. On the slowest machine I have access to (a machine that can never run Fedora because it doesn't meet the hardware requirements) it takes 12 seconds to run setfiles on a fully loaded /dev. On machines that are a mere four years old it takes about 2 seconds, I doubt that you will be able to measure the difference that this makes on any hardware that can be purchased now. But writing some code to check for the file system type is not too difficult. -- 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 lkcl at lkcl.net Fri Sep 10 10:01:51 2004 From: lkcl at lkcl.net (Luke Kenneth Casson Leighton) Date: Fri, 10 Sep 2004 11:01:51 +0100 Subject: tmpfs /dev In-Reply-To: <200409101508.27612.russell@coker.com.au> References: <200409100536.59711.russell@coker.com.au> <4140BAB8.8070808@redhat.com> <200409101508.27612.russell@coker.com.au> Message-ID: <20040910100151.GD14060@lkcl.net> On Fri, Sep 10, 2004 at 03:08:27PM +1000, Russell Coker wrote: > On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > > You will need to talk to Bill Nottingham about modifying /sbin/init to > > do this. They are not crazy about > > putting additional code into /sbin/init since it is very hard to debug. > > We've done it once, we can do it again. > > > They prefer rc.sysinit. They also do not > > rc.sysinit means changing the policy for init_t, initrc_t, and maybe others. > > > want to relabel the /dev file system if it is not a tmpfs, since with > > 8000 or more files it could take a while and > > slow down the boot up. > > On the slowest machine I have access to (a machine that can never run Fedora > because it doesn't meet the hardware requirements) it takes 12 seconds to run > setfiles on a fully loaded /dev. On machines that are a mere four years old > it takes about 2 seconds, I doubt that you will be able to measure the > difference that this makes on any hardware that can be purchased now. But > writing some code to check for the file system type is not too difficult. on my 1.6Gz athlon, it takes somewhere between 30 and 50 seconds to do the setting up of udev entries (ttyS0->ttyS63 and tty0->tty63) which would make it more of a priority to be sorted than the above! l. -- -- Truth, honesty and respect are rare commodities that all spring from the same well: Love. If you love yourself and everyone and everything around you, funnily and coincidentally enough, life gets a lot better. -- lkcl.net
lkcl at lkcl.net
From notting at redhat.com Fri Sep 10 16:30:21 2004 From: notting at redhat.com (Bill Nottingham) Date: Fri, 10 Sep 2004 12:30:21 -0400 Subject: tmpfs /dev In-Reply-To: <200409101508.27612.russell@coker.com.au> References: <200409100536.59711.russell@coker.com.au> <4140BAB8.8070808@redhat.com> <200409101508.27612.russell@coker.com.au> Message-ID: <20040910163021.GA28303@nostromo.devel.redhat.com> Russell Coker (russell at coker.com.au) said: > On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > > You will need to talk to Bill Nottingham about modifying /sbin/init to > > do this. They are not crazy about > > putting additional code into /sbin/init since it is very hard to debug. > > We've done it once, we can do it again. But why is init any better? Especially when it's just spawning a shell script - that's a hack. > > They prefer rc.sysinit. They also do not > > rc.sysinit means changing the policy for init_t, initrc_t, and maybe others. init runs in init_t, surely? > > want to relabel the /dev file system if it is not a tmpfs, since with > > 8000 or more files it could take a while and > > slow down the boot up. > > On the slowest machine I have access to (a machine that can never run Fedora > because it doesn't meet the hardware requirements) it takes 12 seconds to run > setfiles on a fully loaded /dev. On machines that are a mere four years old > it takes about 2 seconds, I doubt that you will be able to measure the > difference that this makes on any hardware that can be purchased now. But > writing some code to check for the file system type is not too difficult. The code's already written and there. The reason you don't want to run it on a normal /dev is because it's *pointless.* Bill From selinux at gmail.com Fri Sep 10 17:42:20 2004 From: selinux at gmail.com (Tom London) Date: Fri, 10 Sep 2004 10:42:20 -0700 Subject: /etc/hal/capability.d/printer_update.hal Message-ID: <4c4ba15304091010424b657013@mail.gmail.com> Notice the following: Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied { execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 9 09:37:55 fedora kernel: audit(1094747875.090:0): avc: denied { execute } for pid=3131 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Should the following be added to hald.fc? /etc/hal/capability.d/printer_update.hal -- system_u:object_r:hald_exec_t (similar to /etc/hal/device.d/printer_remove.hal ?) tom -- Tom London From russell at coker.com.au Sat Sep 11 06:43:54 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Sep 2004 16:43:54 +1000 Subject: tmpfs /dev In-Reply-To: <20040910163021.GA28303@nostromo.devel.redhat.com> References: <200409100536.59711.russell@coker.com.au> <200409101508.27612.russell@coker.com.au> <20040910163021.GA28303@nostromo.devel.redhat.com> Message-ID: <200409111643.54132.russell@coker.com.au> On Sat, 11 Sep 2004 02:30, Bill Nottingham wrote: > Russell Coker (russell at coker.com.au) said: > > On Fri, 10 Sep 2004 06:19, Daniel J Walsh wrote: > > > You will need to talk to Bill Nottingham about modifying /sbin/init to > > > do this. They are not crazy about > > > putting additional code into /sbin/init since it is very hard to debug. > > > > We've done it once, we can do it again. > > But why is init any better? Especially when it's just spawning a > shell script - that's a hack. Spawning a shell script is good for a test. If we decide to run it from init then we can do it differently in the release version of the code. > > > They prefer rc.sysinit. They also do not > > > > rc.sysinit means changing the policy for init_t, initrc_t, and maybe > > others. > > init runs in init_t, surely? init runs in init_t AFTER it re-exec's itself. At the time it is doing the SE Linux stuff it's running as kernel_t or running on a system with no policy loaded. -- 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 Sat Sep 11 09:34:19 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 11 Sep 2004 19:34:19 +1000 Subject: /dev/dri/* and SE Linux Message-ID: <200409111934.19937.russell@coker.com.au> In the latest CVS SE Linux policy xserver_macros.te has: # Create and access /dev/dri devices. allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; allow $1_xserver_t dri_device_t:chr_file create_file_perms; [...] # Do not flood audit logs due to device node creation attempts. dontaudit $1_xserver_t device_t:chr_file create; [...] allow $1_xserver_t device_t:dir { create }; It seems that the first and second sections don't work well together. Since we changed /dev/dri to have type device_t instead of dri_device_t it seems that attempts to create /dev/dri/whatever will be permitted on the device_t:dir access but dontaudit'd on the device_t:chr_file access. Does it even make sense to allow creating device nodes under /dev/dri now that we have udev doing so much? Can't udev do this for us? -- 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 vamsee.krishna at gmail.com Sun Sep 12 19:15:45 2004 From: vamsee.krishna at gmail.com (Vamsee Krishna Gomatam) Date: Mon, 13 Sep 2004 00:45:45 +0530 Subject: SELinux Enabled - Can't mount SMB shares Message-ID: Hello, I've enabled SELinux on my machine running FC2. Everything went well and I didn't get any "avc: denied" messages after I did a "relabel" and reboot. But now, I can't mount any SMB shares. I'm able to give the login and password for mounting and it seems to work. But then, I can't access those mounted drives. What is going wrong? This is my first time with SELinux. regards, GVK -- Real programmers don't work 9 to 5. If any real programmers are around at 9, it's because they were up all night From russell at coker.com.au Mon Sep 13 09:17:26 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 13 Sep 2004 19:17:26 +1000 Subject: SELinux Enabled - Can't mount SMB shares In-Reply-To: References: Message-ID: <200409131917.26860.russell@coker.com.au> On Mon, 13 Sep 2004 05:15, Vamsee Krishna Gomatam wrote: > I've enabled SELinux on my machine running FC2. Everything went well > and I didn't get any "avc: denied" messages after I did a "relabel" > and reboot. But now, I can't mount any SMB shares. I'm able to give Please run "dmesg" after you experience this problem and send us the AVC messages that seem most relevant. -- 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 dwalsh at redhat.com Mon Sep 13 14:38:33 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Sep 2004 10:38:33 -0400 Subject: /dev/dri/* and SE Linux In-Reply-To: <200409111934.19937.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> Message-ID: <4145B0E9.80000@redhat.com> Russell Coker wrote: >In the latest CVS SE Linux policy xserver_macros.te has: > ># Create and access /dev/dri devices. >allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >allow $1_xserver_t dri_device_t:chr_file create_file_perms; > >[...] > ># Do not flood audit logs due to device node creation attempts. >dontaudit $1_xserver_t device_t:chr_file create; > >[...] > >allow $1_xserver_t device_t:dir { create }; > >It seems that the first and second sections don't work well together. Since >we changed /dev/dri to have type device_t instead of dri_device_t it seems >that attempts to create /dev/dri/whatever will be permitted on the >device_t:dir access but dontaudit'd on the device_t:chr_file access. > >Does it even make sense to allow creating device nodes under /dev/dri now that >we have udev doing so much? Can't udev do this for us? > > > It should in the future, but it doesn't right now. (Might need to add the broken software tunable. :^) Dan From russell at coker.com.au Mon Sep 13 15:24:10 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 14 Sep 2004 01:24:10 +1000 Subject: /dev/dri/* and SE Linux In-Reply-To: <4145B0E9.80000@redhat.com> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> Message-ID: <200409140124.10133.russell@coker.com.au> On Tue, 14 Sep 2004 00:38, Daniel J Walsh wrote: > Russell Coker wrote: > >In the latest CVS SE Linux policy xserver_macros.te has: > > > ># Create and access /dev/dri devices. > >allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; > >allow $1_xserver_t dri_device_t:chr_file create_file_perms; > > > >[...] > > > ># Do not flood audit logs due to device node creation attempts. > >dontaudit $1_xserver_t device_t:chr_file create; > > > >[...] > > > >allow $1_xserver_t device_t:dir { create }; # Create and access /dev/dri devices. allow $1_xserver_t device_t:dir create; file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) OK, the above should do all that's needed, replacing the other rules above. You can replace the current policy with that, the current policy definately doesn't work while the above should give the same result that the old policy did before we changed the type of /dev/dri. Of course it would be nice to get this tested by someone who uses and understands DRI... -- 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 vamsee.krishna at gmail.com Mon Sep 13 16:44:27 2004 From: vamsee.krishna at gmail.com (Vamsee Krishna Gomatam) Date: Mon, 13 Sep 2004 22:14:27 +0530 Subject: SELinux Enabled - Can't mount SMB shares In-Reply-To: <200409131917.26860.russell@coker.com.au> References: <200409131917.26860.russell@coker.com.au> Message-ID: On Mon, 13 Sep 2004 19:17:26 +1000, Russell Coker wrote: > On Mon, 13 Sep 2004 05:15, Vamsee Krishna Gomatam > wrote: > > I've enabled SELinux on my machine running FC2. Everything went well > > and I didn't get any "avc: denied" messages after I did a "relabel" > > and reboot. But now, I can't mount any SMB shares. I'm able to give > > Please run "dmesg" after you experience this problem and send us the AVC > messages that seem most relevant. > I am pasting the relevant dmesg output below. My pc's IP address is 172.16.20.67 and I'm mounting a folder names "songs" from 172.16.19.5 onto my /mnt/songs directory. ------------------------------dmesg output start------------------------------------------------------------- SELinux: initialized (dev , type smbfs), uses genfs_contexts audit(1095086981.281:0): avc: denied { read } for pid=2421 comm=smbiod laddr=172.16.20.67 lport=32771 faddr=172.16.19.5 fport=445 scontext=system_u:system_r:kernel_t tcontext=root:sysadm_r:sysadm_t tclass=tcp_socket smb_get_length: recv error = 13 audit(1095086981.420:0): avc: denied { write } for pid=2424 exe=/usr/libexec/gnome-vfs-daemon laddr=172.16.20.67 lport=32772 faddr=172.16.19.5 fport=445 scontext=user_u:user_r:user_t tcontext=root:sysadm_r:sysadm_t tclass=tcp_socket SMB connection re-established (-13) audit(1095086981.450:0): avc: denied { write } for pid=2421 comm=smbiod laddr=172.16.20.67 lport=32773 faddr=172.16.19.5 fport=445 scontext=system_u:system_r:kernel_t tcontext=root:sysadm_r:sysadm_t tclass=tcp_socket -------------------------------dmesg output end---------------------------------------------------------------------- Regards, GVK From mike at flyn.org Mon Sep 13 19:52:19 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 13 Sep 2004 14:52:19 -0500 (CDT) Subject: /dev/dri/* and SE Linux In-Reply-To: <200409140124.10133.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> <200409140124.10133.russell@coker.com.au> Message-ID: <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> >>> In the latest CVS SE Linux policy xserver_macros.te has: >>> >>> # Create and access /dev/dri devices. >>> allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >>> allow $1_xserver_t dri_device_t:chr_file create_file_perms; >>> >>> [...] >>> >>> # Do not flood audit logs due to device node creation attempts. >>> dontaudit $1_xserver_t device_t:chr_file create; >>> >>> [...] >>> >>> allow $1_xserver_t device_t:dir { create }; > # Create and access /dev/dri devices. > allow $1_xserver_t device_t:dir create; > file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) > > OK, the above should do all that's needed, replacing the other rules > above. You can replace the current policy with that, the current policy > definately doesn't work while the above should give the same result that > the old policy did before we changed the type of /dev/dri. > > Of course it would be nice to get this tested by someone who uses and > understands DRI... For what its worth, I entered a bug into bugzilla about this a while ago: DRI use denied by Red Hat SELinux policy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 -- Mike From mike at flyn.org Mon Sep 13 19:50:43 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 13 Sep 2004 14:50:43 -0500 (CDT) Subject: /dev/dri/* and SE Linux In-Reply-To: <200409140124.10133.russell@coker.com.au> References: <200409111934.19937.russell@coker.com.au> <4145B0E9.80000@redhat.com> <200409140124.10133.russell@coker.com.au> Message-ID: <47766.66.151.13.191.1095105043.squirrel@66.151.13.191> >>> In the latest CVS SE Linux policy xserver_macros.te has: >>> >>> # Create and access /dev/dri devices. >>> allow $1_xserver_t device_t:dir { setattr rw_dir_perms }; >>> allow $1_xserver_t dri_device_t:chr_file create_file_perms; >>> >>> [...] >>> >>> # Do not flood audit logs due to device node creation attempts. >>> dontaudit $1_xserver_t device_t:chr_file create; >>> >>> [...] >>> >>> allow $1_xserver_t device_t:dir { create }; > # Create and access /dev/dri devices. > allow $1_xserver_t device_t:dir create; > file_type_auto_trans($1_xserver_t, device_t, dri_device_t, chr_file) > > OK, the above should do all that's needed, replacing the other rules > above. You can replace the current policy with that, the current policy > definately doesn't work while the above should give the same result that > the old policy did before we changed the type of /dev/dri. > > Of course it would be nice to get this tested by someone who uses and > understands DRI... For what its worth, I entered a bug into bugzilla about this a while ago: DRI use denied by Red Hat SELinux policy https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 -- Mike From joshbaverstock at hotmail.com Tue Sep 14 08:11:56 2004 From: joshbaverstock at hotmail.com (josh baverstock) Date: Tue, 14 Sep 2004 08:11:56 +0000 Subject: dumb question / idea Message-ID: I must first admit that I am new to linux, I am not qualified to suggest a feature, so please consider this a question. IF its true that when SELinux is fully enabled the restrictions can cause some problems when programs do things they are supposed to do but normally don't, THEN I have an idea. What if an intrusion detection system were to inform the SELinux server that an intrusion is likely happening, which triggers a change from non-enforcement mode to enforcement mode? Would this "raise the shields" method be useful for situations where enforcement mode just isnt right, or is this more of a fundamental misunderstanding on my part of how SELinux works...? I think in the future this NSA project will be an example of the government receiving a 100 fold return on their investment, even considering that SELinux isn't likely to be used in classified systems. _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx From sds at epoch.ncsc.mil Tue Sep 14 15:34:08 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 14 Sep 2004 11:34:08 -0400 Subject: dumb question / idea In-Reply-To: References: Message-ID: <1095176047.25556.118.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-09-14 at 04:11, josh baverstock wrote: > I must first admit that I am new to linux, I am not qualified to suggest a > feature, so please consider this a question. > > IF its true that when SELinux is fully enabled the restrictions can cause > some problems when programs do things they are supposed to do but normally > don't, THEN I have an idea. > > What if an intrusion detection system were to inform the SELinux server that > an intrusion is likely happening, which triggers a change from > non-enforcement mode to enforcement mode? > > Would this "raise the shields" method be useful for situations where > enforcement mode just isnt right, or is this more of a fundamental > misunderstanding on my part of how SELinux works...? Switching back and forth between permissive mode and enforcing mode in this manner is not a good idea, as: - there is no SELinux protection at all while in permissive mode (and the IDS trigger to switch to enforcing mode may be processed too late to prevent the attack), - the lack of any enforcement will likely cause your system to migrate into a state of operation while running in permissive mode that will break in spectacular fashion when you are suddenly switched into enforcing mode by some external event, in which case your IDS suddenly becomes a vector for an easy DOS attack. It would be better to instead define a policy that matches your security goals in the first place, even if they are modest, and run enforcing all the time with that policy (e.g. see the targeted policy in FC3/devel). You could also try to implement multiple "levels" of security in a single policy using the runtime policy boolean support, and have your IDS trigger well-defined changes in the policy state by changing one or more policy booleans in response to events. -- Stephen Smalley National Security Agency From selinux at gmail.com Tue Sep 14 16:45:52 2004 From: selinux at gmail.com (Tom London) Date: Tue, 14 Sep 2004 09:45:52 -0700 Subject: firefox and /usr/tmp Message-ID: <4c4ba1530409140945652697de@mail.gmail.com> When firefox starts it seems to access /usr/tmp: Sep 14 09:35:49 fedora kernel: audit(1095179749.095:0): avc: denied { read } for pid=4728 exe=/usr/lib/firefox-0.9.3/firefox-bin name=tmp dev=hda2 ino=4112460 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:tmp_t tclass=lnk_file donaudit, e.g.? dontaudit $1_mozilla_t tmp_t:lnk_file read; -- Tom London From lists at donut.dk Wed Sep 15 12:32:57 2004 From: lists at donut.dk (Cream[DONut]) Date: Wed, 15 Sep 2004 14:32:57 +0200 Subject: SELinux & apache/httpd access to /home/*/www Message-ID: <41483679.9020503@donut.dk> Hello, My problem is this: I host some small PHP & MySQL websites for friends and family, they have their VirtualHost DocumentRoot's in "/home/[name]/www" (and is working fine with SELinux disabled). I am running SELinux with SELINUX=enforcing, SELINUXTYPE=targeted. SELinux seems to be blocking httpd from accessing /home/name/www, atleast when trying to start apache it complains: Starting httpd: Warning: DocumentRoot [/home/xxxxxx/www] does not exist Warning: DocumentRoot [/home/yyyyy/www] does not exist [FAILED] (The non virtualhost root in /var/www/html works fine, but if moved to /home/xxxxxx/www it fails) /etc/selinux/targeted/contexts/files/file_contexts contains: # apache /home/[^/]+/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_user_content_t Which to me would seem to match the /home/[name]/www (I have tried upgrading to selinux-policy-targeted-1.17.12-1, but it didnt fix the problem) (I have the individual logfiles in /home/[name]/log, which probably presents another problem.) I dont quite understand the quirks of SELinux, so I'd certainly appriciate some direction. Regards Kris PS. If what I'm asking is simple, please bare with me, i installed Fedora Core 3 test1 only 2 days ago, and its my first experience with SELinux (I spent most of yesterday google'ing for answers to my problem, and reading up on SELinux permissions. Without learning much.) PPS. Does anyone have context files for Qmail / QmailAdmin / SQWebmail / Vpopmail / courier-imap Qmail-Scanner / SpamAssassin / ClamAV / maildrop / daemontools / ucspi-tcp-0.88 (tcpserver) / ezmlm ? :) (I wouldn't building them if i could only figure out how) From dwalsh at redhat.com Wed Sep 15 14:57:33 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 15 Sep 2004 10:57:33 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <41483679.9020503@donut.dk> References: <41483679.9020503@donut.dk> Message-ID: <4148585D.80204@redhat.com> Cream[DONut] wrote: > Hello, > > My problem is this: > I host some small PHP & MySQL websites for friends and family, they > have their VirtualHost DocumentRoot's in "/home/[name]/www" (and is > working fine with SELinux disabled). > > I am running SELinux with SELINUX=enforcing, SELINUXTYPE=targeted. > > SELinux seems to be blocking httpd from accessing /home/name/www, > atleast when trying to start apache it complains: > Starting httpd: Warning: DocumentRoot [/home/xxxxxx/www] does not exist > Warning: DocumentRoot [/home/yyyyy/www] does not exist > [FAILED] > There are a couple of ways to handle this. This is in the order of most protection. 1. In order to maintain the SELinux protection on Apache, you could change the context of the directrory and files you wish to share. a chcon -t -R httpd_user_content_t /home/*/www b Then restart apache and try to access the pages. service httpd restart 2. You can disable SELinux protextion for apache. a. Run selinux-config-securitylevel and select the SELinux tab. b. In the Modify SELinux Policy box, select the transitions list item and expand. c. Check the Disable SELinux protection for httpd daemon line. d. Click ok e. Restart apache service httpd restart 3. Disable SELinux a. Run selinux-config-securitylevel and select the SELinux tab. b. UnClick Enabled c. Click Ok d. Reboot. From sds at epoch.ncsc.mil Wed Sep 15 16:03:05 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 15 Sep 2004 12:03:05 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <41483679.9020503@donut.dk> References: <41483679.9020503@donut.dk> Message-ID: <1095264185.28981.203.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-09-15 at 08:32, Cream[DONut] wrote: > Hello, > > My problem is this: > I host some small PHP & MySQL websites for friends and family, they have > their VirtualHost DocumentRoot's in "/home/[name]/www" (and is working > fine with SELinux disabled). > > I am running SELinux with SELINUX=enforcing, SELINUXTYPE=targeted. > > SELinux seems to be blocking httpd from accessing /home/name/www, > atleast when trying to start apache it complains: > Starting httpd: Warning: DocumentRoot [/home/xxxxxx/www] does not exist > Warning: DocumentRoot [/home/yyyyy/www] does not exist > [FAILED] > > (The non virtualhost root in /var/www/html works fine, but if moved to > /home/xxxxxx/www it fails) > > /etc/selinux/targeted/contexts/files/file_contexts contains: > # apache > /home/[^/]+/((www)|(web)|(public_html))(/.+)? > system_u:object_r:httpd_user_content_t > > Which to me would seem to match the /home/[name]/www > (I have tried upgrading to selinux-policy-targeted-1.17.12-1, but it > didnt fix the problem) > > (I have the individual logfiles in /home/[name]/log, which probably > presents another problem.) > > I dont quite understand the quirks of SELinux, so I'd certainly > appriciate some direction. audit2allow -v -d will generate allow rules from the audit messages generated by any denials, or you can inspect dmesg output or /var/log/messages directly for lines that have "avc: denied...". ls -aZ /home/[name]/www will show you the current security contexts on the directory and its files. One possible cause would be that the filesystem type for /home doesn't support extended attributes (e.g. NFS) and thus SELinux couldn't label /home/[name]/www with the expected type. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Sep 15 16:06:22 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 15 Sep 2004 12:06:22 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <41483679.9020503@donut.dk> References: <41483679.9020503@donut.dk> Message-ID: <1095264382.28981.207.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-09-15 at 08:32, Cream[DONut] wrote: > PPS. Does anyone have context files for Qmail / QmailAdmin / SQWebmail / > Vpopmail / courier-imap Qmail-Scanner / SpamAssassin / ClamAV / maildrop > / daemontools / ucspi-tcp-0.88 (tcpserver) / ezmlm ? :) (I wouldn't > building them if i could only figure out how) Policy for many of these programs exists in the strict policy. You could either try using the strict policy itself (a large leap), or you could try porting the .te and .fc files from the strict policy and adding them to your targeted policy source tree, then rebuilding, reloading, and relabeling. -- Stephen Smalley National Security Agency From ivg2 at cornell.edu Wed Sep 15 20:46:12 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 15 Sep 2004 16:46:12 -0400 Subject: Bug 129584: restrictions on user_t Message-ID: <1095281172.24059.25.camel@localhost.localdomain> Bug link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584 > Additional Comment #9 From Daniel Walsh (dwalsh at redhat.com) on > 2004-09-15 15:55 > Yes there are a lot of files that user can not access. Mainly any > file that has a security context associated with it and doesn't have > the attribute usercanread. > Again I want to bring this conversation to the public list and come to > concensus. We can add usercanread to these files, but the question > than is should a user be able to read all files even if they are world > readable. I don't see why not. If you think the user should not be able to read those files, then why aren't their permissions flags set accordingly? If a file was intended to be readable only by a certain application or only by root then it could have had the proper user/group/rwx flags set - this restriction could have been imposed without SELinux. If it is marked user readable then it seems to me that any user should be able to read it (or at least that there are no security reasons to deny it). So why does SElinux impose restrictions on user_t that contradict this explicit setting? -- Ivan Gyurdiev Cornell University From selinux at gmail.com Thu Sep 16 00:09:45 2004 From: selinux at gmail.com (Tom London) Date: Wed, 15 Sep 2004 17:09:45 -0700 Subject: Bug 129584: restrictions on user_t In-Reply-To: <1095281172.24059.25.camel@localhost.localdomain> References: <1095281172.24059.25.camel@localhost.localdomain> Message-ID: <4c4ba15304091517093ac55520@mail.gmail.com> I can see this going towards three 'standard' policies: targeted, tight and strict (where tight is strict with usercanread 'everywhere'). In general, I'm in favor of keeping strict as it is: well defined policies for the mandatory access controls that override the discretionary ones. But then again, I can understand circumstances where one may want something 'in between' targeted and strict. Not sure how to extend this to 'group readable', though. tom [My guess is that when the knowledge-/comfort-level of policy hacking is greater, this will be less of an issue.] On Wed, 15 Sep 2004 16:46:12 -0400, Ivan Gyurdiev wrote: > Bug link: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129584 > > > Additional Comment #9 From Daniel Walsh (dwalsh at redhat.com) on > > 2004-09-15 15:55 > > > Yes there are a lot of files that user can not access. Mainly any > > file that has a security context associated with it and doesn't have > > the attribute usercanread. > > > Again I want to bring this conversation to the public list and come to > > concensus. We can add usercanread to these files, but the question > > than is should a user be able to read all files even if they are world > > readable. > > I don't see why not. If you think the user should not be able > to read those files, then why aren't their permissions flags > set accordingly? If a file was intended to be readable only > by a certain application or only by root then it could have had > the proper user/group/rwx flags set - this restriction could > have been imposed without SELinux. If it is marked > user readable then it seems to me that any user should > be able to read it (or at least that there are no > security reasons to deny it). So why > does SElinux impose restrictions on user_t > that contradict this explicit setting? > > -- > Ivan Gyurdiev > Cornell University > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London From selinux at comcast.net Thu Sep 16 03:53:27 2004 From: selinux at comcast.net (Tom London) Date: Wed, 15 Sep 2004 20:53:27 -0700 Subject: mailman... Message-ID: <41490E37.1080106@comcast.net> Running strict/enforcing, latest packages from Dan's tree. Argh... mailman again. Here's the avc: Sep 15 20:40:02 fedora kernel: audit(1095306002.105:0): avc: denied { getattr } for pid=20117 exe=/usr/bin/python path=/var/mailman/pythonlib/korean/__init__.pyc dev=hda2 ino=444330 scontext=system_u:system_r:mailman_queue_t tcontext=system_u:object_r:var_t tclass=file occurs every 5 minutes (so generates lots of error'ed emails). Mailman requires python 'stuff' from /var/mailman/pythonlib and from /var/mailman/Mailman. I can think of 2 possible fixes: 1. Explicitly allow mailman_queue_t to read var_t: --- mailman.te 2004-09-15 12:53:30.000000000 -0700 +++ /etc/selinux/strict/src-1.17.14-1.patched/policy/domains/program/mailman.te2004-09-14 16:36:43.000000000 -0700 @@ -31,7 +31,7 @@ can_network(mailman_$1_t) can_ypbind(mailman_$1_t) allow mailman_$1_t self:unix_stream_socket create_socket_perms; -allow mailman_$1_t var_t:dir r_dir_perms; +r_dir_file(mailman_$1_t, var_t) ') mailman_domain(queue, `, auth_chkpwd') or 2. by relabeling the .py, .pyc and .pyo files in /var/mailman/pythonlib and /var/mailman/Mailman as shlib_t (or something else?) i.e. adding this to mailman.fc: /var/mailman/pythonlib(/.*)?/.*\.py([co])? -- system_u:object_r:shlib_t /var/mailman/Mailman(/.*)?/.*\.py([co])? -- system_u:object_r:shlib_t I'm not sure that shlib_t is correct. (Should it be mailman_queue_t?) But I noticed an entry in types.fc for .so files in the pythonlib tree, and copied that. tom From walters at redhat.com Thu Sep 16 04:07:33 2004 From: walters at redhat.com (Colin Walters) Date: Thu, 16 Sep 2004 00:07:33 -0400 Subject: mailman... In-Reply-To: <41490E37.1080106@comcast.net> References: <41490E37.1080106@comcast.net> Message-ID: <1095307653.4231.155.camel@nexus.verbum.private> On Wed, 2004-09-15 at 20:53 -0700, Tom London wrote: > Running strict/enforcing, latest packages from Dan's tree. > > Argh... mailman again. > > Here's the avc: > > Sep 15 20:40:02 fedora kernel: audit(1095306002.105:0): avc: denied { > getattr } for pid=20117 exe=/usr/bin/python > path=/var/mailman/pythonlib/korean/__init__.pyc dev=hda2 ino=444330 > scontext=system_u:system_r:mailman_queue_t > tcontext=system_u:object_r:var_t tclass=file > > occurs every 5 minutes (so generates lots of error'ed emails). Mailman > requires > python 'stuff' from /var/mailman/pythonlib and from /var/mailman/Mailman. Eww. Why does mailman put Python libraries there? They should go in /usr/lib/python2.3/site-packages. I think simply moving them there would make them lib_t which should fix the problem. I would file a bug on our mailman package. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From SwopeCR at yahoo.com Thu Sep 16 05:45:07 2004 From: SwopeCR at yahoo.com (Christopher R. Swope) Date: Thu, 16 Sep 2004 00:45:07 -0500 Subject: Problems with NFS Message-ID: <41492863.6040007@yahoo.com> Hi all, I have a little linux box which I pretty much use as a firewall box. I also use it as a server, because I have too many hard drives. I just enabled SELinux on it, using the instructions found on the Fedora page. Most things went fine, but I am having some trouble using files that I export over NFS. The directory at issue is a directory that I use for development (for homework). I have regular executable files (that are compiled from C++ source code), and perl scripts in this directory. I can't run either, as I get a permission denied error message. I tried to do the relabeling thing, and also deleting the files and rebuilding them, but to no avail. I know nothing about SELinux other than what I read on the Fedora page. Can someone please tell me how to fix this problem? Thanks, Christopher From sds at epoch.ncsc.mil Thu Sep 16 13:44:07 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 16 Sep 2004 09:44:07 -0400 Subject: Problems with NFS In-Reply-To: <41492863.6040007@yahoo.com> References: <41492863.6040007@yahoo.com> Message-ID: <1095342247.30684.94.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-09-16 at 01:45, Christopher R. Swope wrote: > The directory at issue is a directory that I use for development (for > homework). I have regular executable files (that are compiled from C++ > source code), and perl scripts in this directory. I can't run either, > as I get a permission denied error message. I tried to do the > relabeling thing, and also deleting the files and rebuilding them, but > to no avail. What does audit2allow -d -v show? -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Sep 16 14:27:08 2004 From: selinux at gmail.com (Tom London) Date: Thu, 16 Sep 2004 07:27:08 -0700 Subject: mailman... In-Reply-To: <1095307653.4231.155.camel@nexus.verbum.private> References: <41490E37.1080106@comcast.net> <1095307653.4231.155.camel@nexus.verbum.private> Message-ID: <4c4ba15304091607273379f956@mail.gmail.com> Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132732 On Thu, 16 Sep 2004 00:07:33 -0400, Colin Walters wrote: > On Wed, 2004-09-15 at 20:53 -0700, Tom London wrote: > > Running strict/enforcing, latest packages from Dan's tree. > > > > Argh... mailman again. > > > > Here's the avc: > > > > Sep 15 20:40:02 fedora kernel: audit(1095306002.105:0): avc: denied { > > getattr } for pid=20117 exe=/usr/bin/python > > path=/var/mailman/pythonlib/korean/__init__.pyc dev=hda2 ino=444330 > > scontext=system_u:system_r:mailman_queue_t > > tcontext=system_u:object_r:var_t tclass=file > > > > occurs every 5 minutes (so generates lots of error'ed emails). Mailman > > requires > > python 'stuff' from /var/mailman/pythonlib and from /var/mailman/Mailman. > > Eww. Why does mailman put Python libraries there? They should go > in /usr/lib/python2.3/site-packages. I think simply moving them there > would make them lib_t which should fix the problem. > > I would file a bug on our mailman package. > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- Tom London From selinux at comcast.net Thu Sep 16 17:37:31 2004 From: selinux at comcast.net (Tom London) Date: Thu, 16 Sep 2004 10:37:31 -0700 Subject: mount ? Message-ID: <4149CF5B.2040900@comcast.net> Running strict/enforcing, with latest from Dan's tree. The 'mount' command produces no output when run in enforcing mode. Works fine in permissive mode. No AVCs produced..... tom From dwalsh at redhat.com Thu Sep 16 17:46:30 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Sep 2004 13:46:30 -0400 Subject: mount ? In-Reply-To: <4149CF5B.2040900@comcast.net> References: <4149CF5B.2040900@comcast.net> Message-ID: <4149D176.7050704@redhat.com> Tom London wrote: > Running strict/enforcing, with latest from Dan's tree. > > The 'mount' command produces no output when run in enforcing mode. > Works fine in permissive mode. > > No AVCs produced..... > > tom > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Try mount | cat Problem is sysadm is transitioning to the mount command which is not allowed to write to tty devices. Normal users don't have the problem since they don't transition to mount. Not sure how to solve. Dan From dwalsh at redhat.com Thu Sep 16 17:51:32 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Sep 2004 13:51:32 -0400 Subject: mount ? In-Reply-To: <4149CF5B.2040900@comcast.net> References: <4149CF5B.2040900@comcast.net> Message-ID: <4149D2A4.5060000@redhat.com> Tom London wrote: > Running strict/enforcing, with latest from Dan's tree. > > The 'mount' command produces no output when run in enforcing mode. > Works fine in permissive mode. > > No AVCs produced..... > > tom > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Try this. diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/mount.te policy-1.17.17/domains/program/mount.te --- nsapolicy/domains/program/mount.te 2004-09-14 09:18:10.000000000 -0400 +++ policy-1.17.17/domains/program/mount.te 2004-09-16 13:50:45.899174425 -0400 @@ -93,7 +93,8 @@ allow mount_t file_type:filesystem { unmount mount relabelto }; allow mount_t mnt_t:dir { getattr }; -dontaudit mount_t { userdomain kernel_t}:fd use; +allow mount_t { userdomain }:fd use; +dontaudit mount_t { kernel_t}:fd use; can_exec(mount_t, { sbin_t bin_t }) allow mount_t device_t:dir r_dir_perms; ifdef(`distro_redhat', ` From selinux at comcast.net Thu Sep 16 18:06:07 2004 From: selinux at comcast.net (Tom London) Date: Thu, 16 Sep 2004 11:06:07 -0700 Subject: haldaemon, run_init Message-ID: <4149D60F.2030207@comcast.net> Running strict/enforcing w/ latest from Dan's tree. When haldaemon starts: Sep 16 07:52:29 fedora haldaemon: haldaemon startup succeeded Sep 16 07:52:30 fedora fstab-sync[3132]: removed all generated mount points Sep 16 07:52:30 fedora kernel: audit(1095346350.044:0): avc: denied { execute } for pid=3134 exe=/usr/sbin/hald name=bash dev=hda2 ino=229395 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 07:52:30 fedora mdmonitor: mdadm startup succeeded Believe the AVC is generated when hald tries to run hal_lpadmin from /etc/hal/device.d/printer_remove.hal When I put system into permissive mode and restart haldaemon, I get (sorry for running this as root, but run_init seems busted: Sep 16 11:03:12 fedora kernel: audit(1095357792.163:0): avc: denied { use } for pid=4262 exe=/usr/sbin/run_init path=/dev/pts/2 dev=devpts ino=4 scontext=root:sysadm_r:run_init_t tcontext=user_u:user_r:user_t tclass=fd Sep 16 11:03:12 fedora last message repeated 2 times Sep 16 11:03:12 fedora run_init(pam_unix)[4262]: authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root ) Here are the permissive AVCs: Sep 16 10:44:43 fedora kernel: audit(1095356683.853:0): avc: denied { relabelfrom } for pid=8333 exe=/usr/sbin/fstab-sync name=fstab dev=hda2 ino=4475247 scontext=root:system_r:updfstab_t tcontext=root:object_r:etc_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.854:0): avc: denied { relabelto } for pid=8333 exe=/usr/sbin/fstab-sync name=fstab dev=hda2 ino=4475247 scontext=root:system_r:updfstab_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:43 fedora fstab-sync[8333]: removed all generated mount points Sep 16 10:44:43 fedora kernel: audit(1095356683.893:0): avc: denied { execute } for pid=8335 exe=/usr/sbin/hald name=bash dev=hda2 ino=229395 scontext=root:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.894:0): avc: denied { read } for pid=8335 exe=/usr/sbin/hald path=/bin/bash dev=hda2 ino=229395 scontext=root:system_r:hald_t tcontext=system_u:object_r:shell_exec_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.899:0): avc: denied { execute } for pid=8336 exe=/bin/bash name=hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.900:0): avc: denied { execute_no_trans } for pid=8336 exe=/bin/bash path=/usr/sbin/hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:43 fedora kernel: audit(1095356683.900:0): avc: denied { read } for pid=8336 exe=/bin/bash path=/usr/sbin/hal_lpadmin dev=hda2 ino=278545 scontext=root:system_r:hald_t tcontext=system_u:object_r:sbin_t tclass=file Sep 16 10:44:44 fedora kernel: audit(1095356684.672:0): avc: denied { search } for pid=8381 exe=/usr/libexec/hal-hotplug-map name=hotplug dev=hda2 ino=4472955 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=dir Sep 16 10:44:44 fedora kernel: audit(1095356684.674:0): avc: denied { read } for pid=8381 exe=/usr/libexec/hal-hotplug-map name=usb.usermap dev=hda2 ino=4474609 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=file Sep 16 10:44:44 fedora kernel: audit(1095356684.674:0): avc: denied { getattr } for pid=8381 exe=/usr/libexec/hal-hotplug-map path=/etc/hotplug/usb.usermap dev=hda2 ino=4474609 scontext=root:system_r:hald_t tcontext=system_u:object_r:hotplug_etc_t tclass=file Sep 16 10:44:45 fedora kernel: audit(1095356685.450:0): avc: denied { use } for pid=8430 exe=/bin/mount path=pipe:[13184] dev=pipefs ino=13184 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:xdm_t tclass=fd Sep 16 10:44:45 fedora kernel: audit(1095356685.450:0): avc: denied { write } for pid=8430 exe=/bin/mount path=pipe:[13184] dev=pipefs ino=13184 scontext=user_u:user_r:user_mount_t tcontext=system_u:system_r:xdm_t tclass=fifo_file Sep 16 10:44:46 fedora kernel: audit(1095356686.042:0): avc: denied { execute } for pid=8330 exe=/usr/sbin/hald name=printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:46 fedora kernel: audit(1095356686.075:0): avc: denied { read write } for pid=8330 exe=/usr/sbin/hald name=lp0 dev=tmpfs ino=6883 scontext=root:system_r:hald_t tcontext=system_u:object_r:printer_device_t tclass=chr_file Sep 16 10:44:46 fedora kernel: audit(1095356686.121:0): avc: denied { execute_no_trans } for pid=8479 exe=/usr/sbin/hald path=/etc/hal/capability.d/printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file Sep 16 10:44:46 fedora kernel: audit(1095356686.140:0): avc: denied { ioctl } for pid=8479 exe=/bin/bash path=/etc/hal/capability.d/printer_update.hal dev=hda2 ino=280646 scontext=root:system_r:hald_t tcontext=system_u:object_r:etc_t tclass=file From sds at epoch.ncsc.mil Thu Sep 16 18:08:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 16 Sep 2004 14:08:52 -0400 Subject: mount ? In-Reply-To: <4149D176.7050704@redhat.com> References: <4149CF5B.2040900@comcast.net> <4149D176.7050704@redhat.com> Message-ID: <1095358132.30684.124.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-09-16 at 13:46, Daniel J Walsh wrote: > Problem is sysadm is transitioning to the mount command which is not > allowed to write to tty devices. > Normal users don't have the problem since they don't transition to mount. > > Not sure how to solve. You can allow mount_t to rw admin_tty_type:chr_file; it isn't the same situation as with a daemon where you want to prevent a compromised daemon from being able to access it. -- Stephen Smalley National Security Agency From selinux at gmail.com Thu Sep 16 18:11:31 2004 From: selinux at gmail.com (Tom London) Date: Thu, 16 Sep 2004 11:11:31 -0700 Subject: mount ? In-Reply-To: <4149D2A4.5060000@redhat.com> References: <4149CF5B.2040900@comcast.net> <4149D2A4.5060000@redhat.com> Message-ID: <4c4ba153040916111176194944@mail.gmail.com> 1. 'mount | cat' indeed works. 2. 'mount' from normal user also works. 3. patch applied and works! Thanks! tom On Thu, 16 Sep 2004 13:51:32 -0400, Daniel J Walsh wrote: > > > Tom London wrote: > > > Running strict/enforcing, with latest from Dan's tree. > > > > The 'mount' command produces no output when run in enforcing mode. > > Works fine in permissive mode. > > > > No AVCs produced..... > > > > tom > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Try this. > > diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/mount.te > policy-1.17.17/domains/program/mount.te > --- nsapolicy/domains/program/mount.te 2004-09-14 09:18:10.000000000 -0400 > +++ policy-1.17.17/domains/program/mount.te 2004-09-16 > 13:50:45.899174425 -0400 > @@ -93,7 +93,8 @@ > allow mount_t file_type:filesystem { unmount mount relabelto }; > > allow mount_t mnt_t:dir { getattr }; > -dontaudit mount_t { userdomain kernel_t}:fd use; > +allow mount_t { userdomain }:fd use; > +dontaudit mount_t { kernel_t}:fd use; > can_exec(mount_t, { sbin_t bin_t }) > allow mount_t device_t:dir r_dir_perms; > ifdef(`distro_redhat', ` > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London From selinux at comcast.net Thu Sep 16 18:24:12 2004 From: selinux at comcast.net (Tom London) Date: Thu, 16 Sep 2004 11:24:12 -0700 Subject: fsck.ext3 on bootup Message-ID: <4149DA4C.6030409@comcast.net> Get these very early during boot up. I'm guessing we're trying to check the 'early root' and that this is harmless. If so, dontaudit fsadm_t device_t:blk_file { getattr }; That sound right? tom Sep 16 10:50:36 fedora kernel: ACPI: Sleep Button (CM) [FUTS] Sep 16 10:50:36 fedora kernel: audit(1095357002.303:0): avc: denied { getattr } for pid=1839 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=2028 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file Sep 16 10:50:36 fedora kernel: EXT3 FS on hda2, internal journal Sep 16 10:50:36 fedora kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm at uk.sistina.com Sep 16 10:50:36 fedora kernel: audit(1095357004.327:0): avc: denied { getattr } for pid=2074 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=2028 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file From selinux at comcast.net Thu Sep 16 19:25:46 2004 From: selinux at comcast.net (Tom London) Date: Thu, 16 Sep 2004 12:25:46 -0700 Subject: get the red and green back (really consoletype, rhgb) Message-ID: <4149E8BA.8050507@comcast.net> Booting in strict/enforcing, 'Fedora' in the 'Welcome to Fedora Core' message is no longer red, the subsequent 6 or so messages are formatted differently (i.e., the '[OK]' is not nicely indented, and it is not in green). Also, rhgb doesn't start. (Yeah, I know, this is not a bug, its a feature ;) ) Anyway, the following patch puts the red and green back in the boot. The change mimics the privileges given for console_device_t:chr_file --- /etc/selinux/strict/src-1.17.16-3/policy/domains/program/consoletype.te 2004-09-16 07:14:24.000000000 -0700 +++ ./consoletype.te 2004-09-16 11:37:14.000000000 -0700 @@ -52,5 +52,5 @@ allow consoletype_t pam_var_run_t:file { getattr read }; ') ifdef(`distro_redhat', ` -dontaudit consoletype_t tmpfs_t:chr_file { read write }; +allow consoletype_t tmpfs_t:chr_file { getattr ioctl read write }; ') The follow makes rhgb work in strict/enforcing. The problem is that it wants to mount /etc/rhgb, but it is currently labeled 'etc_t'. Labeling /etc/rhgb as 'root_t' makes it work. Not sure if this is really 'proper'. I'd be more comfortable with it being labeled something like 'etc_rhgb_t' or some such, or moving the mount point.... --- /etc/selinux/strict/src-1.17.16-3/policy/file_contexts/program/rhgb.fc 2004-09-16 07:14:24.000000000 -0700 +++ ./rhgb.fc 2004-09-16 12:21:12.424588200 -0700 @@ -1,2 +1,3 @@ /usr/bin/rhgb -- system_u:object_r:rhgb_exec_t #/etc/dbus-1(/.*)? system_u:object_r:etc_dbusd_t +/etc/rhgb -d system_u:object_r:root_t From dwalsh at redhat.com Thu Sep 16 21:08:55 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Sep 2004 17:08:55 -0400 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <4149E8BA.8050507@comcast.net> References: <4149E8BA.8050507@comcast.net> Message-ID: <414A00E7.1080903@redhat.com> Tom London wrote: > Booting in strict/enforcing, 'Fedora' in the 'Welcome to Fedora Core' > message is no longer red, the subsequent 6 or so messages are formatted > differently (i.e., the '[OK]' is not nicely indented, and it is not in > green). > Also, rhgb doesn't start. (Yeah, I know, this is not a bug, its a > feature ;) ) > > Anyway, the following patch puts the red and green back in the boot. > The change mimics the privileges given for console_device_t:chr_file > > --- > /etc/selinux/strict/src-1.17.16-3/policy/domains/program/consoletype.te > 2004-09-16 07:14:24.000000000 -0700 > +++ ./consoletype.te 2004-09-16 11:37:14.000000000 -0700 > @@ -52,5 +52,5 @@ > allow consoletype_t pam_var_run_t:file { getattr read }; > ') > ifdef(`distro_redhat', ` > -dontaudit consoletype_t tmpfs_t:chr_file { read write }; > +allow consoletype_t tmpfs_t:chr_file { getattr ioctl read write }; > ') > Modified > The follow makes rhgb work in strict/enforcing. The problem > is that it wants to mount /etc/rhgb, but it is currently labeled > 'etc_t'. Labeling /etc/rhgb as 'root_t' makes it work. Not sure > if this is really 'proper'. I'd be more comfortable with it being > labeled something like 'etc_rhgb_t' or some such, or moving > the mount point.... > > --- > /etc/selinux/strict/src-1.17.16-3/policy/file_contexts/program/rhgb.fc > 2004-09-16 07:14:24.000000000 -0700 > +++ ./rhgb.fc 2004-09-16 12:21:12.424588200 -0700 > @@ -1,2 +1,3 @@ > /usr/bin/rhgb -- system_u:object_r:rhgb_exec_t > #/etc/dbus-1(/.*)? system_u:object_r:etc_dbusd_t > +/etc/rhgb -d system_u:object_r:root_t > Changed to mnt_t > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at gmail.com Thu Sep 16 21:39:37 2004 From: selinux at gmail.com (Tom London) Date: Thu, 16 Sep 2004 14:39:37 -0700 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <414A00E7.1080903@redhat.com> References: <4149E8BA.8050507@comcast.net> <414A00E7.1080903@redhat.com> Message-ID: <4c4ba153040916143927979f62@mail.gmail.com> On Thu, 16 Sep 2004 17:08:55 -0400, Daniel J Walsh wrote: <<>> > > /etc/selinux/strict/src-1.17.16-3/policy/file_contexts/program/rhgb.fc > > 2004-09-16 07:14:24.000000000 -0700 > > +++ ./rhgb.fc 2004-09-16 12:21:12.424588200 -0700 > > @@ -1,2 +1,3 @@ > > /usr/bin/rhgb -- system_u:object_r:rhgb_exec_t > > #/etc/dbus-1(/.*)? system_u:object_r:etc_dbusd_t > > +/etc/rhgb -d system_u:object_r:root_t > > > Changed to mnt_t Better! thanks, tom -- Tom London From lists at donut.dk Fri Sep 17 00:02:52 2004 From: lists at donut.dk (Cream[DONut]) Date: Fri, 17 Sep 2004 02:02:52 +0200 Subject: Bug in audit2allow? Message-ID: <414A29AC.1040502@donut.dk> I think i found a bug in audit2allow, when parsing this line: Sep 15 21:10:45 DONut kernel: audit(1095275445.237:0): avc: denied { write } for pid=3463 exe=/usr/sbin/httpd path=/home/iced/www/thumbs/albums/Iced does Greece/parga2003-1 019.jpg dev=hda2 ino=1459429 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_user_content_t tclass=file (running in permissive mode) it turns it into this: allow httpd_t httpd_user_content_t:dir { add_name create write }; #EXE=/usr/sbin/httpd NAME=albums : write #EXE=/usr/sbin/httpd NAME=Iced : add_name #EXE=/usr/sbin/httpd NAME=Iced : create #EXE=/usr/sbin/httpd NAME=Iced : write #EXE=/usr/sbin/httpd NAME=parga2003-1 : add_name as you can see the spaces in the dir name seems to cause problems. From lists at donut.dk Fri Sep 17 00:18:22 2004 From: lists at donut.dk (Cream[DONut]) Date: Fri, 17 Sep 2004 02:18:22 +0200 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <4148585D.80204@redhat.com> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> Message-ID: <414A2D4E.8090004@donut.dk> Daniel J Walsh wrote: > 1. In order to maintain the SELinux protection on Apache, you could > change the context of the directrory and files you wish to share. > a chcon -t -R httpd_user_content_t /home/*/www > b Then restart apache and try to access the pages. service > httpd restart I assume you mean "chcon -R -t httpd_user_content_t /home/*/www", since the context you posted doesnt work. But it doesnt fix the problem, apache still cant i still get "DocumentRoot [/home/xxxxxx/www] does not exist". la -latZ /home/ drwxr-x--- xxxxxx apache system_u:object_r:user_home_dir_t xxxxxx ls -latZ /home/xxxxxx drwxr-xr-x xxxxxx xxxxxx system_u:object_r:httpd_user_content_t www I checked that the apache user could open the files, even in enforcing targeted mode > > 2. You can disable SELinux protextion for apache. > a. Run selinux-config-securitylevel and select the SELinux tab. > b. In the Modify SELinux Policy box, select the transitions list > item and expand. > c. Check the Disable SELinux protection for httpd daemon line. > d. Click ok > e. Restart apache > service httpd restart Do you mean system-config-securitylevel? because i dont have any selinux-config-securitylevel, but my system-config-securitylevel doesnt display any SELinux related stuff. (I prefer to edit the configs in emacs, it seems to give me a better picture of how it works). Still not sure how to disable auditing of the httpd in targeted mode. > 3. Disable SELinux > a. Run selinux-config-securitylevel and select the SELinux tab. > b. UnClick Enabled > c. Click Ok > d. Reboot. or SELINUX=disabled in /etc/selinux/config, or selinux=0 in the boot config, but I'd like to give SELinux a try. (at the moment targeted mode seems to be the right one for me) Stephen Smalley wrote: > audit2allow -v -d will generate allow rules from the audit messages > generated by any denials, or you can inspect dmesg output or > /var/log/messages directly for lines that have "avc: denied...". I figured if i ran the system in strict & permissive mode, and then ran the system trough the paces it would be expected to do in normal day operations, I would be able to build a good "seed file". I havent been able to find any page discribing what to do with that file, but im guessing it should somehow be used in /etc/selinux/strict/src/policy. (the system halts during booting if its in strict & enforcing mode) > ls -aZ /home/[name]/www will show you the current security contexts on > the directory and its files. handy, thanks > One possible cause would be that the filesystem type for /home doesn't > support extended attributes (e.g. NFS) and thus SELinux couldn't label > /home/[name]/www with the expected type. /home is not NFS, its ext3 Thanks for taking the time to respond to my initial post. Kris From selinux at comcast.net Fri Sep 17 01:22:32 2004 From: selinux at comcast.net (Tom London) Date: Thu, 16 Sep 2004 18:22:32 -0700 Subject: cups, /dev/fd Message-ID: <414A3C58.8060801@comcast.net> Running strict/enforcing, latest from Dan's tree. Printing (say, from openoffice) yields: Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t tclass=lnk_file Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t tclass=lnk_file inode 2794 is /dev/fd. Make sense to add? dontaudit cupsd_t device_t:lnk_file { read }; tom From dwalsh at redhat.com Fri Sep 17 11:31:32 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 17 Sep 2004 07:31:32 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414A2D4E.8090004@donut.dk> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> Message-ID: <414ACB14.9050007@redhat.com> Cream[DONut] wrote: > Daniel J Walsh wrote: > > 1. In order to maintain the SELinux protection on Apache, you could > > change the context of the directrory and files you wish to share. > > a chcon -t -R httpd_user_content_t /home/*/www > > b Then restart apache and try to access the pages. service > > httpd restart > > I assume you mean "chcon -R -t httpd_user_content_t /home/*/www", > since the context you posted doesnt work. But it doesnt fix the > problem, apache still cant i still get "DocumentRoot > [/home/xxxxxx/www] does not exist". What are the AVC messages you are seeing in the /var/log/messages file. > > la -latZ /home/ > drwxr-x--- xxxxxx apache system_u:object_r:user_home_dir_t xxxxxx > > ls -latZ /home/xxxxxx > drwxr-xr-x xxxxxx xxxxxx system_u:object_r:httpd_user_content_t www > > I checked that the apache user could open the files, even in enforcing > targeted mode > > > > > 2. You can disable SELinux protextion for apache. > > a. Run selinux-config-securitylevel and select the SELinux tab. > > b. In the Modify SELinux Policy box, select the transitions list > > item and expand. > > c. Check the Disable SELinux protection for httpd daemon line. > > d. Click ok > > e. Restart apache > > service httpd restart > > Do you mean system-config-securitylevel? because i dont have any > selinux-config-securitylevel, but my system-config-securitylevel > doesnt display any SELinux related stuff. (I prefer to edit the > configs in emacs, it seems to give me a better picture of how it works). > Yes system-config-securitylevel, you need to upgrade to a newer version. But you can edit the booleans file in /etc/selinux/targeted/booleans if you like and add a boolean http_disable_trans=1, then type "setsebool http_disable_trans 1". Stop and restart the http service. > Still not sure how to disable auditing of the httpd in targeted mode. > > > > > 3. Disable SELinux > > a. Run selinux-config-securitylevel and select the SELinux tab. > > b. UnClick Enabled > > c. Click Ok > > d. Reboot. > > or SELINUX=disabled in /etc/selinux/config, > or selinux=0 in the boot config, > but I'd like to give SELinux a try. (at the moment targeted mode seems > to be the right one for me) > Get the AVC messages and we can get it working. audit2allow -i /var/log/messages > > > Stephen Smalley wrote: > > audit2allow -v -d will generate allow rules from the audit messages > > generated by any denials, or you can inspect dmesg output or > > /var/log/messages directly for lines that have "avc: denied...". > > I figured if i ran the system in strict & permissive mode, and then > ran the system trough the paces it would be expected to do in normal > day operations, I would be able to build a good "seed file". > > I havent been able to find any page discribing what to do with that > file, but im guessing it should somehow be used in > /etc/selinux/strict/src/policy. > > (the system halts during booting if its in strict & enforcing mode) > > > > > ls -aZ /home/[name]/www will show you the current security contexts on > > the directory and its files. > > handy, thanks > > > > > One possible cause would be that the filesystem type for /home doesn't > > support extended attributes (e.g. NFS) and thus SELinux couldn't label > > /home/[name]/www with the expected type. > > /home is not NFS, its ext3 > > > Thanks for taking the time to respond to my initial post. > Kris > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From lists at donut.dk Fri Sep 17 12:17:19 2004 From: lists at donut.dk (Cream[DONut]) Date: Fri, 17 Sep 2004 14:17:19 +0200 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414ACB14.9050007@redhat.com> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> Message-ID: <414AD5CF.8010901@donut.dk> Daniel J Walsh wrote: > What are the AVC messages you are seeing in the /var/log/messages file. when starting httpd, it just fails, there are no AVC messages in /var/log, but for testing purpose I set DocumentRoot to the / root of the server, which worked, then i tried going to /home, which didnt work, I couldnt open /home/xxxxxx or /home/xxxxxx/www. These are the AVC's the server produced from starting the server and accessing those folders: Sep 17 13:54:05 DONut kernel: audit(1095422045.364:0): avc: denied { getattr } for pid=1956 exe=/usr/sbin/httpd path=/misc dev=hda2 ino=7487489 scontext=root:system_r:httpd_t tcontext=system_u:object_r:default_t tclass=dir Sep 17 13:54:05 DONut kernel: audit(1095422045.365:0): avc: denied { getattr } for pid=1956 exe=/usr/sbin/httpd path=/boot dev=hda1 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:boot_t tclass=dir Sep 17 13:54:05 DONut kernel: audit(1095422045.365:0): avc: denied { getattr } for pid=1956 exe=/usr/sbin/httpd path=/backup dev=hda3 ino=2 scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir Sep 17 13:54:05 DONut kernel: audit(1095422045.368:0): avc: denied { getattr } for pid=1956 exe=/usr/sbin/httpd path=/lost+found dev=hda2 ino=11 scontext=root:system_r:httpd_t tcontext=system_u:object_r:file_t tclass=dir Sep 17 13:54:05 DONut kernel: audit(1095422045.377:0): avc: denied { getattr } for pid=1956 exe=/usr/sbin/httpd path=/selinux dev=selinuxfs ino=760 scontext=root:system_r:httpd_t tcontext=system_u:object_r:security_t tclass=dir Sep 17 13:54:17 DONut kernel: audit(1095422057.529:0): avc: denied { read } for pid=1959 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir Sep 17 13:54:43 DONut kernel: audit(1095422083.486:0): avc: denied { read } for pid=1963 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir Sep 17 13:54:46 DONut kernel: audit(1095422086.425:0): avc: denied { read } for pid=1958 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir I'm not sure why it accesses /lost+found /backup /boot or /misc, it certainly shouldnt be for some reason the error messages for /home and /home/xxxxxx were different. /home produces a standard 403 Forbidden error, while /home/xxxxxx and /home/xxxxxx/www produces a 403 + the added text "Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request." (for this test i disabled all virtual domains, and just had the main server in /. when moved to /home it still produced 403) > Yes system-config-securitylevel, you need to upgrade to a newer version. > But you can edit the booleans file in /etc/selinux/targeted/booleans if > you like and add a boolean > http_disable_trans=1, then type "setsebool http_disable_trans 1". Stop > and restart the http service. > > Get the AVC messages and we can get it working. audit2allow -i > /var/log/messages > allow httpd_t boot_t:dir { getattr }; allow httpd_t default_t:dir { getattr }; allow httpd_t file_t:dir { getattr }; allow httpd_t home_root_t:dir { read }; allow httpd_t security_t:dir { getattr }; here are the AVC errors from when DocumentRoot pointed to /home (again there are no AVC errors when pointing to /home/xxxxxx/www Sep 17 14:09:44 DONut kernel: audit(1095422984.079:0): avc: denied { read } for pid=2221 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir Sep 17 14:09:45 DONut kernel: audit(1095422985.732:0): avc: denied { read } for pid=2222 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir Sep 17 14:10:00 DONut kernel: audit(1095423000.418:0): avc: denied { read } for pid=2223 exe=/usr/sbin/httpd name=home dev=hda2 ino=884737 scontext=root:system_r:httpd_t tcontext=system_u:object_r:home_root_t tclass=dir could it be this one missing? allow httpd_t home_root_t:dir { read }; Regards Kris From lists at donut.dk Fri Sep 17 12:48:09 2004 From: lists at donut.dk (Cream[DONut]) Date: Fri, 17 Sep 2004 14:48:09 +0200 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414AD5CF.8010901@donut.dk> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> Message-ID: <414ADD09.4010108@donut.dk> Cream[DONut] wrote: > Daniel J Walsh wrote: >I set DocumentRoot to the / root of > the server, which worked, then i tried going to /home, which didnt work, > I couldnt open /home/xxxxxx or /home/xxxxxx/www. oops, correction, setting DocumentRoot to /home did work, the server started, but when accessing it it gave a 403 forbidden access message. sorry for being unclear Kris From sds at epoch.ncsc.mil Fri Sep 17 12:49:16 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 08:49:16 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414AD5CF.8010901@donut.dk> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> Message-ID: <1095425356.17932.21.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 08:17, Cream[DONut] wrote: > could it be this one missing? > > allow httpd_t home_root_t:dir { read }; It should only require search permission to home_root_t and user_home_dir_t in order to lookup /home//www, and then have read permission to httpd_user_content_t. Naturally, someone (Dan, Russell, me, whoever) should verify that, but in the past, that was sufficient. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Sep 17 13:19:04 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 09:19:04 -0400 Subject: cups, /dev/fd In-Reply-To: <414A3C58.8060801@comcast.net> References: <414A3C58.8060801@comcast.net> Message-ID: <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-09-16 at 21:22, Tom London wrote: > Running strict/enforcing, latest from Dan's tree. > > Printing (say, from openoffice) yields: > > Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { > read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 > scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t > tclass=lnk_file > Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { > read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 > scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t > tclass=lnk_file > > inode 2794 is /dev/fd. > > Make sense to add? > dontaudit cupsd_t device_t:lnk_file { read }; I'd allow it. /dev/fd is just a symlink to /proc/self/fd, and that should be permitted. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Sep 17 13:31:30 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 09:31:30 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <1095425356.17932.21.camel@moss-spartans.epoch.ncsc.mil> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> <1095425356.17932.21.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1095427890.17932.49.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 08:49, Stephen Smalley wrote: > It should only require search permission to home_root_t and > user_home_dir_t in order to lookup /home//www, and then have > read permission to httpd_user_content_t. Naturally, someone (Dan, > Russell, me, whoever) should verify that, but in the past, that was > sufficient. I can successfully access web content in a user's home directory (under public_html, since that is what is enabled in my httpd.conf, but same security context) with the current FC3/devel targeted policy (don't know about the FC3/test1 policy - that was back in July, and a lot has changed). httpd_t only has search and getattr permissions to home_root_t and user_home_dir_t, but has read/search/getattr to httpd_sys_content_t (and httpd_user_content_t is just an alias in the targeted policy). Might want to yum update your system against rawhide (at least selinux-policy-targeted and selinux-policy-targeted-sources) and retry, or wait for test2 on Sep 20th and try it. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Sep 17 13:33:24 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 09:33:24 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414AD5CF.8010901@donut.dk> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> Message-ID: <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 08:17, Cream[DONut] wrote: > when starting httpd, it just fails, there are no AVC messages in > /var/log, but for testing purpose I set DocumentRoot to the / root of > the server, which worked, then i tried going to /home, which didnt work, > I couldnt open /home/xxxxxx or /home/xxxxxx/www. BTW, when you see no AVC messages but think that SELinux is the culprit, do a 'make enableaudit load' in the policy source directory and try again, and then do a 'make clean load' to revert. That is noted in the Fedora SELinux FAQ. Certain audit messages are explicitly suppressed by default using dontaudit rules in the policy to avoid filling the logs with noise, and the 'enableaudit' removes those rules to ensure that you see every denial. -- Stephen Smalley National Security Agency From selinux at gmail.com Fri Sep 17 14:30:33 2004 From: selinux at gmail.com (Tom London) Date: Fri, 17 Sep 2004 07:30:33 -0700 Subject: cups, /dev/fd In-Reply-To: <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> References: <414A3C58.8060801@comcast.net> <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba15304091707303770538@mail.gmail.com> Hmm. Then should /dev/fd (the link) be unlabeled, defaulting to the general DAC? Or labeled, say, self_fd_t, with a general rule allowing accesses to it? Could do the same for /dev/stdin, /dev/stdout, and /dev/stderr. tom On Fri, 17 Sep 2004 09:19:04 -0400, Stephen Smalley wrote: > On Thu, 2004-09-16 at 21:22, Tom London wrote: > > Running strict/enforcing, latest from Dan's tree. > > > > Printing (say, from openoffice) yields: > > > > Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { > > read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 > > scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t > > tclass=lnk_file > > Sep 16 18:01:39 fedora kernel: audit(1095382899.718:0): avc: denied { > > read } for pid=10941 exe=/usr/bin/perl name=fd dev=tmpfs ino=2794 > > scontext=system_u:system_r:cupsd_t tcontext=system_u:object_r:device_t > > tclass=lnk_file > > > > inode 2794 is /dev/fd. > > > > Make sense to add? > > dontaudit cupsd_t device_t:lnk_file { read }; > > I'd allow it. /dev/fd is just a symlink to /proc/self/fd, and that > should be permitted. > > -- > Stephen Smalley > National Security Agency > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London From sds at epoch.ncsc.mil Fri Sep 17 14:32:52 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 10:32:52 -0400 Subject: cups, /dev/fd In-Reply-To: <4c4ba15304091707303770538@mail.gmail.com> References: <414A3C58.8060801@comcast.net> <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> <4c4ba15304091707303770538@mail.gmail.com> Message-ID: <1095431572.17932.71.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 10:30, Tom London wrote: > Then should /dev/fd (the link) be unlabeled, defaulting > to the general DAC? Or labeled, say, self_fd_t, > with a general rule allowing accesses to it? > > Could do the same for /dev/stdin, /dev/stdout, and > /dev/stderr. I don't see why you wouldn't just generally give search to device_t:dir for /dev and read to device_t:lnk_file for /dev/{fd,stdin,stdout,stderr}. Maintaining individual types on those symlinks seems overkill. BTW, unlabeled doesn't default to general DAC, it is inaccessible to most domains. -- Stephen Smalley National Security Agency From selinux at gmail.com Fri Sep 17 14:45:07 2004 From: selinux at gmail.com (Tom London) Date: Fri, 17 Sep 2004 07:45:07 -0700 Subject: cups, /dev/fd In-Reply-To: <1095431572.17932.71.camel@moss-spartans.epoch.ncsc.mil> References: <414A3C58.8060801@comcast.net> <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> <4c4ba15304091707303770538@mail.gmail.com> <1095431572.17932.71.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba15304091707451cd96166@mail.gmail.com> oops.... (got tripped up on /proc). Yeah. Your approach is better. thanks, tom On Fri, 17 Sep 2004 10:32:52 -0400, Stephen Smalley wrote: > On Fri, 2004-09-17 at 10:30, Tom London wrote: > > Then should /dev/fd (the link) be unlabeled, defaulting > > to the general DAC? Or labeled, say, self_fd_t, > > with a general rule allowing accesses to it? > > > > Could do the same for /dev/stdin, /dev/stdout, and > > /dev/stderr. > > I don't see why you wouldn't just generally give search to device_t:dir > for /dev and read to device_t:lnk_file for > /dev/{fd,stdin,stdout,stderr}. Maintaining individual types on those > symlinks seems overkill. BTW, unlabeled doesn't default to general DAC, > it is inaccessible to most domains. > > > > -- > Stephen Smalley > National Security Agency > > -- Tom London From selinux at gmail.com Fri Sep 17 14:45:07 2004 From: selinux at gmail.com (Tom London) Date: Fri, 17 Sep 2004 07:45:07 -0700 Subject: cups, /dev/fd In-Reply-To: <1095431572.17932.71.camel@moss-spartans.epoch.ncsc.mil> References: <414A3C58.8060801@comcast.net> <1095427144.17932.41.camel@moss-spartans.epoch.ncsc.mil> <4c4ba15304091707303770538@mail.gmail.com> <1095431572.17932.71.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba15304091707451cd96166@mail.gmail.com> oops.... (got tripped up on /proc). Yeah. Your approach is better. thanks, tom On Fri, 17 Sep 2004 10:32:52 -0400, Stephen Smalley wrote: > On Fri, 2004-09-17 at 10:30, Tom London wrote: > > Then should /dev/fd (the link) be unlabeled, defaulting > > to the general DAC? Or labeled, say, self_fd_t, > > with a general rule allowing accesses to it? > > > > Could do the same for /dev/stdin, /dev/stdout, and > > /dev/stderr. > > I don't see why you wouldn't just generally give search to device_t:dir > for /dev and read to device_t:lnk_file for > /dev/{fd,stdin,stdout,stderr}. Maintaining individual types on those > symlinks seems overkill. BTW, unlabeled doesn't default to general DAC, > it is inaccessible to most domains. > > > > -- > Stephen Smalley > National Security Agency > > -- Tom London From dwalsh at redhat.com Fri Sep 17 15:42:29 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 17 Sep 2004 11:42:29 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <414B05E5.9070602@redhat.com> Stephen Smalley wrote: >On Fri, 2004-09-17 at 08:17, Cream[DONut] wrote: > > >>when starting httpd, it just fails, there are no AVC messages in >>/var/log, but for testing purpose I set DocumentRoot to the / root of >>the server, which worked, then i tried going to /home, which didnt work, >>I couldnt open /home/xxxxxx or /home/xxxxxx/www. >> >> > >BTW, when you see no AVC messages but think that SELinux is the culprit, >do a 'make enableaudit load' in the policy source directory and try >again, and then do a 'make clean load' to revert. That is noted in the >Fedora SELinux FAQ. Certain audit messages are explicitly suppressed by >default using dontaudit rules in the policy to avoid filling the logs >with noise, and the 'enableaudit' removes those rules to ensure that you >see every denial. > > > I also have it working fine. With the 1-17-17 policy, targeted and strict. DocumentRoot is /var/www/html Attached the difference in httpd.conf to get it to work. ls -laZ ~dwalsh/www/ drwx--x--x dwalsh dwalsh system_u:object_r:httpd_user_content_t . drwxr-xr-x dwalsh dwalsh system_u:object_r:user_home_dir_t .. -rw-r--r-- dwalsh dwalsh system_u:object_r:httpd_user_content_t hunts.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From lists at donut.dk Fri Sep 17 16:40:39 2004 From: lists at donut.dk (Cream[DONut]) Date: Fri, 17 Sep 2004 18:40:39 +0200 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <414B1387.5020101@donut.dk> Stephen Smalley wrote: > On Fri, 2004-09-17 at 08:17, Cream[DONut] wrote: > >>when starting httpd, it just fails, there are no AVC messages in >>/var/log, but for testing purpose I set DocumentRoot to the / root of >>the server, which worked, then i tried going to /home, which didnt work, >>I couldnt open /home/xxxxxx or /home/xxxxxx/www. > > > BTW, when you see no AVC messages but think that SELinux is the culprit, > do a 'make enableaudit load' in the policy source directory and try > again, and then do a 'make clean load' to revert. That is noted in the > Fedora SELinux FAQ. Certain audit messages are explicitly suppressed by > default using dontaudit rules in the policy to avoid filling the logs > with noise, and the 'enableaudit' removes those rules to ensure that you > see every denial. > with make enableaudit load Sep 17 18:23:15 DONut kernel: audit(1095438195.775:0): avc: denied { read write } for pid=2822 exe=/usr/sbin/httpd path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:httpd_t tcontext=root:object_r:devpts_t tclass=chr_file Sep 17 18:23:16 DONut httpd: httpd startup succeeded when trying to accessing http://server/~xxxxxx/ Sep 17 18:24:10 DONut kernel: audit(1095438250.555:0): avc: denied { search } for pid=2826 exe=/usr/sbin/httpd name=xxxxxx dev=hda2 ino=886604 scontext=root:system_r:httpd_t tcontext=system_u:object_r:user_home_dir_t tclass=dir Sep 17 18:24:10 DONut kernel: audit(1095438250.556:0): avc: denied { getattr } for pid=2826 exe=/usr/sbin/httpd path=/home/xxxxxx dev=hda2 ino=886604 scontext=root:system_r:httpd_t tcontext=system_u:object_r:user_home_dir_t tclass=dir Anyway, thanks for the help, dont give it too much attention, i'll install test2 next week, and let you know how it goes. regards Kris From sds at epoch.ncsc.mil Fri Sep 17 17:13:13 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 13:13:13 -0400 Subject: SELinux & apache/httpd access to /home/*/www In-Reply-To: <414B1387.5020101@donut.dk> References: <41483679.9020503@donut.dk> <4148585D.80204@redhat.com> <414A2D4E.8090004@donut.dk> <414ACB14.9050007@redhat.com> <414AD5CF.8010901@donut.dk> <1095428004.17932.52.camel@moss-spartans.epoch.ncsc.mil> <414B1387.5020101@donut.dk> Message-ID: <1095441193.17932.241.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 12:40, Cream[DONut] wrote: > Sep 17 18:23:15 DONut kernel: audit(1095438195.775:0): avc: denied { > read write } for pid=2822 exe=/usr/sbin/httpd path=/dev/pts/0 > dev=devpts ino=2 scontext=root:system_r:httpd_t > tcontext=root:object_r:devpts_t tclass=chr_file This one is correct; we revoke access to the tty upon the transition to the httpd_t domain so that a compromised daemon cannot subsequently gain access to an admin tty. IIRC, that did cause breakage in apache until we made a change to the kernel to also re-open descriptors 0-2 to /dev/null when it closes access to the tty so that stdin/stdout/stderr are still defined as expected for it during initialization. The kernel change wasn't made until after test1, so that is likely why this breaks for you. You can allow it temporarily if you like for testing purposes, or update to a newer kernel. > Sep 17 18:24:10 DONut kernel: audit(1095438250.555:0): avc: denied { > search } for pid=2826 exe=/usr/sbin/httpd name=xxxxxx dev=hda2 > ino=886604 scontext=root:system_r:httpd_t > tcontext=system_u:object_r:user_home_dir_t tclass=dir > Sep 17 18:24:10 DONut kernel: audit(1095438250.556:0): avc: denied { > getattr } for pid=2826 exe=/usr/sbin/httpd path=/home/xxxxxx dev=hda2 > ino=886604 scontext=root:system_r:httpd_t > tcontext=system_u:object_r:user_home_dir_t tclass=dir This should have been allowed, and it is allowed in the current targeted policy. Looking at the CVS history, it was fixed for the targeted policy after test1 as well, which explains your error. So you can add it or update your policy. -- Stephen Smalley National Security Agency From selinux at gmail.com Fri Sep 17 18:35:56 2004 From: selinux at gmail.com (Tom London) Date: Fri, 17 Sep 2004 11:35:56 -0700 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <4c4ba153040916143927979f62@mail.gmail.com> References: <4149E8BA.8050507@comcast.net> <414A00E7.1080903@redhat.com> <4c4ba153040916143927979f62@mail.gmail.com> Message-ID: <4c4ba153040917113551b2c9fc@mail.gmail.com> uhhh... Sorry, but I didn't check before. Need this in rhgb.te: --- /etc/selinux/strict/src-1.17.18-1/policy/domains/program/rhgb.te 2004-09-17 11:32:00.886510890 -0700 +++ ./rhgb.te 2004-09-17 11:33:42.601099238 -0700 @@ -34,7 +34,7 @@ allow insmod_t rhgb_t:fd use; allow rhgb_t ramfs_t:filesystem { mount unmount }; -allow rhgb_t root_t:dir { mounton }; +allow rhgb_t { root_t mnt_t }:dir { mounton }; allow rhgb_t rhgb_t:capability { sys_admin }; dontaudit rhgb_t var_run_t:dir { search }; Otherwise can't mount.... tom On Thu, 16 Sep 2004 14:39:37 -0700, Tom London wrote: > On Thu, 16 Sep 2004 17:08:55 -0400, Daniel J Walsh wrote: > > <<>> > > > > /etc/selinux/strict/src-1.17.16-3/policy/file_contexts/program/rhgb.fc > > > 2004-09-16 07:14:24.000000000 -0700 > > > +++ ./rhgb.fc 2004-09-16 12:21:12.424588200 -0700 > > > @@ -1,2 +1,3 @@ > > > /usr/bin/rhgb -- system_u:object_r:rhgb_exec_t > > > #/etc/dbus-1(/.*)? system_u:object_r:etc_dbusd_t > > > +/etc/rhgb -d system_u:object_r:root_t > > > > > Changed to mnt_t > > Better! > > thanks, > tom > -- > Tom London > -- Tom London From ltcgcw at us.ibm.com Fri Sep 17 19:38:39 2004 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 17 Sep 2004 14:38:39 -0500 Subject: Boolean utilities segv's Message-ID: <20040917193839.GA3020@us.ibm.com> Hi, We found what appears to be a bug in libselinux. The getsebool, setsebool, and togglesebool all SIGSEGV when SELINUX=disabled. The global that stores the selinuxfs mountpoint in libselinux, selinux_mnt, is initialized to NULL. selinuxfs is not mounted when SELinux is disabled, therefore no mountpoint exists when init_selinuxmnt() scans /proc/mounts, and selinux_mnt remains NULL. So when get_bool_value() in booleans.c attempts to strlen(selinux_mnt), a SIGSEGV results. The fix is to validate selinux_mnt before the offending strlen() in get_bool_value(), line 101 of booleans.c from selinux-usr-2004081908. It probably would not hurt to validate name as well. The same bug exists in FC3. Thanks -- George Wilson IBM Linux Technology Center From sds at epoch.ncsc.mil Fri Sep 17 19:56:19 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 15:56:19 -0400 Subject: Boolean utilities segv's In-Reply-To: <20040917193839.GA3020@us.ibm.com> References: <20040917193839.GA3020@us.ibm.com> Message-ID: <1095450979.17932.317.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 15:38, George C. Wilson wrote: > We found what appears to be a bug in libselinux. The getsebool, setsebool, > and togglesebool all SIGSEGV when SELINUX=disabled. > > The global that stores the selinuxfs mountpoint in libselinux, selinux_mnt, is > initialized to NULL. selinuxfs is not mounted when SELinux is disabled, > therefore no mountpoint exists when init_selinuxmnt() scans /proc/mounts, and > selinux_mnt remains NULL. So when get_bool_value() in booleans.c attempts to > strlen(selinux_mnt), a SIGSEGV results. The fix is to validate selinux_mnt > before the offending strlen() in get_bool_value(), line 101 of booleans.c from > selinux-usr-2004081908. It probably would not hurt to validate name as well. > The same bug exists in FC3. Ok, we can certainly fix this, but note that these functions are not going to work on a non-SELinux system regardless; you shouldn't even be calling them (or running those utilities) on a non-SELinux system. -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Fri Sep 17 20:07:31 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 17 Sep 2004 16:07:31 -0400 Subject: Boolean utilities segv's In-Reply-To: Your message of "Fri, 17 Sep 2004 15:56:19 EDT." <1095450979.17932.317.camel@moss-spartans.epoch.ncsc.mil> References: <20040917193839.GA3020@us.ibm.com> <1095450979.17932.317.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200409172007.i8HK7W3w005709@turing-police.cc.vt.edu> On Fri, 17 Sep 2004 15:56:19 EDT, Stephen Smalley said: > Ok, we can certainly fix this, but note that these functions are not > going to work on a non-SELinux system regardless; you shouldn't even be > calling them (or running those utilities) on a non-SELinux system. Probably should put in code like this: fprintf(stderr,"%0: running on non-SELinux system, aborting", argv[0]); exit(1); in case some script or other doesn't do the check itself. I can imagine a package that includes some SELinux policies that include a bool or two - and the package installer software getting this wrong.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From russell at coker.com.au Fri Sep 17 20:28:39 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 18 Sep 2004 06:28:39 +1000 Subject: /dev/dri/* and SE Linux In-Reply-To: <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> References: <200409111934.19937.russell@coker.com.au> <200409140124.10133.russell@coker.com.au> <49502.66.151.13.191.1095105139.squirrel@66.151.13.191> Message-ID: <200409180628.39624.russell@coker.com.au> On Tue, 14 Sep 2004 05:52, "W. Michael Petullo" wrote: > For what its worth, I entered a bug into bugzilla about this a while ago: > > DRI use denied by Red Hat SELinux policy > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124837 The AVC messages in that bugzilla don't reference the DRI device, they indicate that a game was not running in user_games_t domain. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From sds at epoch.ncsc.mil Fri Sep 17 20:41:40 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 17 Sep 2004 16:41:40 -0400 Subject: Boolean utilities segv's In-Reply-To: <200409172007.i8HK7W3w005709@turing-police.cc.vt.edu> References: <20040917193839.GA3020@us.ibm.com> <1095450979.17932.317.camel@moss-spartans.epoch.ncsc.mil> <200409172007.i8HK7W3w005709@turing-police.cc.vt.edu> Message-ID: <1095453700.17932.346.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-09-17 at 16:07, Valdis.Kletnieks at vt.edu wrote: > Probably should put in code like this: > > fprintf(stderr,"%0: running on non-SELinux system, aborting", argv[0]); > exit(1); Ok, changes committed to the sourceforge CVS. Added is_selinux_enabled() tests to the boolean utilities, fail immediately if not enabled, and added assertions to the boolean functions on selinux_mnt. -- Stephen Smalley National Security Agency From walters at redhat.com Sat Sep 18 19:40:33 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 15:40:33 -0400 Subject: please try SELinux again Message-ID: <1095536433.4655.18.camel@nexus.verbum.private> Hi, Talking with a number of people at the office, it seems a high percentage of Fedora developers disabled SELinux during FC2 test2, which was our first attempt at SELinux. Many other users and testers in the Fedora community likely did so as well. I think a lot of people are not aware that things have changed (and generally improved) dramatically since then. Instead of the original "strict" policy which covered everything, a new "targeted" policy has been developed which only applies SELinux restrictions to a few select system daemons. Regular user login sessions are unrestricted. This targeted policy will be enabled by default for FC3. But those of you who are upgrading from existing systems, if you earlier added selinux=0 to your grub config, or disabled it in /etc/sysconfig/selinux, will not be testing the new policy. Please: undo those changes, and give it another try. Be sure that /etc/sysconfig/selinux has these two lines: SELINUX=enforcing SELINUXTYPE=targeted Also be sure you don't have selinux=0 in your grub configuration. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Sat Sep 18 21:31:10 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 18 Sep 2004 17:31:10 -0400 Subject: please try SELinux again In-Reply-To: References: <1095536433.4655.18.camel@nexus.verbum.private> <1095540511.25149.34.camel@one.myworld> <1095541738.4655.24.camel@nexus.verbum.private> Message-ID: <1095543070.4655.30.camel@nexus.verbum.private> On Sat, 2004-09-18 at 23:19 +0200, Lars wrote: > > when i try to enable selinux it only boots to the message > "setting up local disks" in rhgb and stays there. Hmm. Are you running the latest rawhide? Does it work again when you add enforcing=0 to the boot line? [We should move this discussion to fedora-selinux-list] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sun Sep 19 04:12:42 2004 From: selinux at gmail.com (Tom London) Date: Sat, 18 Sep 2004 21:12:42 -0700 Subject: lsusb Message-ID: <4c4ba153040918211298ce35b@mail.gmail.com> Running strict/enforcing, latest Rawhide packages including latest from Dan's tree (selinux-policy-strict-1.17.18-2). Running 'lsusb' as root fails, but '/sbin/lsusb' as user works. [root at fedora ~]# lsusb cannot open /proc/bus/usb, Permission denied (13) Works in permissive mode. Here are the avc's from permissive mode: Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.018:0): avc: denied { getattr } for pid=13020 exe=/sbin/lsusb path=/proc/bus/usb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { search } for pid=13020 exe=/sbin/lsusb dev=usbfs ino=2335 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=dir Sep 18 20:45:36 fedora kernel: audit(1095565536.019:0): avc: denied { read } for pid=13020 exe=/sbin/lsusb name=001 dev=usbfs ino=6351 scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:usbfs_t tclass=file These look like: r_dir_file(sysadm_t, usbfs_t) r_dir_file($1_t, usbfs_t) is in user_macros.te. Should it be in base_user_macros.te? Included in admin_macros.te? tom -- Tom London From walters at redhat.com Sun Sep 19 04:26:13 2004 From: walters at redhat.com (Colin Walters) Date: Sun, 19 Sep 2004 00:26:13 -0400 Subject: lsusb In-Reply-To: <4c4ba153040918211298ce35b@mail.gmail.com> References: <4c4ba153040918211298ce35b@mail.gmail.com> Message-ID: <1095567973.4655.47.camel@nexus.verbum.private> On Sat, 2004-09-18 at 21:12 -0700, Tom London wrote: > Running strict/enforcing, latest Rawhide packages including latest > from Dan's tree (selinux-policy-strict-1.17.18-2). > These look like: > r_dir_file(sysadm_t, usbfs_t) > > r_dir_file($1_t, usbfs_t) is in user_macros.te. > Should it be in base_user_macros.te? Included in admin_macros.te? base_user_macros.te (base_user_domain) is probably the right thing here. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bobgus at rcn.com Sun Sep 19 05:59:59 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Sun, 19 Sep 2004 00:59:59 -0500 Subject: Variable naming confusion Message-ID: <414D205F.7000308@rcn.com> To me, there is a lot of confusion in the naming and choice of values of the SELINUX booleans. (Maybe I just don't have my head around the concepts.. - but I don't think I am alone) For example: The variable 'SELINUX' in the file /etc/selinux/config has the value choices 'enforcing' or 'permissive'. The variable 'enforce' in the /boot/grub/grub.conf file has the value choices '=0' or '=1' The variable shown by the command 'getenforce' is either 'Permissive' or 'Enforcing' (note the initial capitalization) When using the runtime command 'setenforce', the argument is either '0' or '1' When using the script command 'selinuxenabled', the result is '0' if it IS enabled. Suggestions The variable 'SELINUX' is either 'enabled' or 'disabled' The variable 'enforcing' is either 'enabled' or 'disabled' (This can be named 'enforce' rather than 'enforcing' - would help when trying to remember whether the runtime command is 'setenforce' or 'setenforcing') The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy', 'strangleddaemons', etc. From russell at coker.com.au Sun Sep 19 10:31:46 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 19 Sep 2004 20:31:46 +1000 Subject: Bug 129584: restrictions on user_t In-Reply-To: <4c4ba15304091517093ac55520@mail.gmail.com> References: <1095281172.24059.25.camel@localhost.localdomain> <4c4ba15304091517093ac55520@mail.gmail.com> Message-ID: <200409192031.46232.russell@coker.com.au> On Thu, 16 Sep 2004 10:09, Tom London wrote: > I can see this going towards three 'standard' policies: targeted, > tight and strict > (where tight is strict with usercanread 'everywhere'). > > In general, I'm in favor of keeping strict as it is: well defined policies > for the mandatory access controls that override the discretionary ones. If you want strict with usercanread everywhere, then you probably want targetted with more daemons having policy. The general plan is to add more daemons to the targetted policy, so I think that long-term anyone who wants what you refer to as "tight" would be best served by the targetted policy. -- 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 felipe_alfaro at linuxmail.org Mon Sep 20 12:18:17 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 20 Sep 2004 14:18:17 +0200 Subject: AVCs with ntpd Message-ID: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> OK, so I'm trying SElinux after having it disabled for some time. That's what I did: 1. Installed selinux-policy-targeted-1.17.16-2 2. Recompiled the kernel with SElinux support 3. Booted into single user mode 4. Ran "fixfiles relabel" 5. Rebooted with "selinux=1" Now, I'm seeing a lot of these: audit(1095681913.039:0(: avc: denied { search } for pid=2515 exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t tcontext=user_u:object_r"tmpfs_t tclass=dir The problem here is that I'm using UDEV and that the initial ramdisk mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that resides on disk. How should I fix this? From dwalsh at redhat.com Mon Sep 20 12:43:42 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 08:43:42 -0400 Subject: Variable naming confusion In-Reply-To: <414D205F.7000308@rcn.com> References: <414D205F.7000308@rcn.com> Message-ID: <414ED07E.6000305@redhat.com> Bob Gustafson wrote: > To me, there is a lot of confusion in the naming and choice of values > of the SELINUX booleans. (Maybe I just don't have my head around the > concepts.. - but I don't think I am alone) > > For example: > > The variable 'SELINUX' in the file /etc/selinux/config has the value > choices 'enforcing' or 'permissive'. > Case does not matter. > The variable 'enforce' in the /boot/grub/grub.conf file has the value > choices '=0' or '=1' > > The variable shown by the command 'getenforce' is either 'Permissive' > or 'Enforcing' (note the initial capitalization) > > When using the runtime command 'setenforce', the argument is either > '0' or '1' > > When using the script command 'selinuxenabled', the result is '0' if > it IS enabled. > > Suggestions > > The variable 'SELINUX' is either 'enabled' or 'disabled' > > The variable 'enforcing' is either 'enabled' or 'disabled' This is not a bad idea, since this is the way we have gone with the system-config-securitylevel Check it out. > > (This can be named 'enforce' rather than 'enforcing' - would help when > trying to remember whether the runtime command is 'setenforce' or > 'setenforcing') > > The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy', > 'strangleddaemons', etc. > > -- > 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 Mon Sep 20 12:45:19 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 08:45:19 -0400 Subject: AVCs with ntpd In-Reply-To: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> References: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> Message-ID: <414ED0DF.6080601@redhat.com> Felipe Alfaro Solana wrote: > OK, so I'm trying SElinux after having it disabled for some time. > That's what I did: > > 1. Installed selinux-policy-targeted-1.17.16-2 > 2. Recompiled the kernel with SElinux support > 3. Booted into single user mode > 4. Ran "fixfiles relabel" > 5. Rebooted with "selinux=1" > > Now, I'm seeing a lot of these: > > audit(1095681913.039:0(: avc: denied { search } for pid=2515 > exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t > tcontext=user_u:object_r"tmpfs_t tclass=dir > > The problem here is that I'm using UDEV and that the initial ramdisk > mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" > that resides on disk. > > How should I fix this? > Try the policy available on people.redhat.com:~dwalsh/Fedora/ > -- > 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 Mon Sep 20 13:02:23 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 20 Sep 2004 09:02:23 -0400 Subject: AVCs with ntpd In-Reply-To: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> References: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> Message-ID: <1095685342.9744.5.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-09-20 at 08:18, Felipe Alfaro Solana wrote: > 2. Recompiled the kernel with SElinux support The Fedora kernel SRPM or a kernel.org kernel? > audit(1095681913.039:0(: avc: denied { search } for pid=2515 > exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t > tcontext=user_u:object_r"tmpfs_t tclass=dir > > The problem here is that I'm using UDEV and that the initial ramdisk > mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that > resides on disk. > > How should I fix this? This works fine on my rawhide systems, but I am using the Fedora kernel, and it includes a patch to add xattr support to tmpfs so that udev can label the tmpfs inodes with the correct security context. The tmpfs xattr support is not yet in the mainline kernel, but should be soon. -- Stephen Smalley National Security Agency From bobgus at rcn.com Mon Sep 20 14:15:48 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 20 Sep 2004 09:15:48 -0500 Subject: AVCs with ntpd In-Reply-To: <27387A7D-0AFF-11D9-B155-000D9352858E@linuxmail.org> Message-ID: I wonder about step 2. below. If you have the latest (and even just a recent) kernel, all of the SELinux patches are in the kernel already. [doing the patches by hand after looking them over is always a good idea for a secure system, but if you just want to get things up for a sanity check, maybe not necessary at the moment..] Bringing your system up2date is also a good idea as some of the utilities (nptd?) have SELinux related patches. I also think that step 5. needs to be done before steps 3 and 4. You might boot a couple of times with 5. set, then do 3. and 4. At least that is what I have done. BobG On Mon, 20 Sep 2004 14:18:17 +0200, Felipe Alfaro Solana wrote: >OK, so I'm trying SElinux after having it disabled for some time. >That's what I did: > >1. Installed selinux-policy-targeted-1.17.16-2 >2. Recompiled the kernel with SElinux support >3. Booted into single user mode >4. Ran "fixfiles relabel" >5. Rebooted with "selinux=1" > >Now, I'm seeing a lot of these: > >audit(1095681913.039:0(: avc: denied { search } for pid=2515 >exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t >tcontext=user_u:object_r"tmpfs_t tclass=dir > >The problem here is that I'm using UDEV and that the initial ramdisk >mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" that >resides on disk. > >How should I fix this? > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list From bobgus at rcn.com Mon Sep 20 15:48:42 2004 From: bobgus at rcn.com (Bob Gustafson) Date: Mon, 20 Sep 2004 10:48:42 -0500 Subject: Variable naming confusion In-Reply-To: <414ED07E.6000305@redhat.com> References: <414D205F.7000308@rcn.com> <414D205F.7000308@rcn.com> Message-ID: Dan Walsh wrote: >Bob Gustafson wrote: > >> To me, there is a lot of confusion in the naming and choice of values >> of the SELINUX booleans. (Maybe I just don't have my head around the >> concepts.. - but I don't think I am alone) >> >> For example: >> >> The variable 'SELINUX' in the file /etc/selinux/config has the value >> choices 'enforcing' or 'permissive'. >> >Case does not matter. Which case? The variable name, or its values - 'SELINUX' or 'disabled' > >> The variable 'enforce' in the /boot/grub/grub.conf file has the value >> choices '=0' or '=1' >> >> The variable shown by the command 'getenforce' is either 'Permissive' >> or 'Enforcing' (note the initial capitalization) >> >> When using the runtime command 'setenforce', the argument is either >> '0' or '1' >> >> When using the script command 'selinuxenabled', the result is '0' if >> it IS enabled. >> >> Suggestions >> >> The variable 'SELINUX' is either 'enabled' or 'disabled' >> >> The variable 'enforcing' is either 'enabled' or 'disabled' > >This is not a bad idea, since this is the way we have gone with the >system-config-securitylevel >Check it out. Yes, system-config-securitylevel looks good. Binary choices for both SELinux and Enforcing. And a pop-up menu for 'Policy Type' choices. (This label is not the same as the variable name in the /etc/sysconfig/selinux file though. SELINUXTYPE does not even include the word 'policy') Now if only the /etc/sysconfig/selinux file could be brought into conformance. It currenly has a strange trinary choice which includes the value 'enforcing' - which is a variable name in all the other contexts. The variable name SELINUXTYPE refers to the type of policy. The word policy should be in that variable name. Maybe 'POLICY_TYPE', or 'PolicyType', or ..'SELINUXPOLICYTYPE'. Also, the names of the commands 'getenforce' and 'setenforce' should conform to the name of the variable (variable name now is 'enforcing'). Maybe just change the name of the commands to 'getenforcing' and 'setenforcing'. The boot grub.conf parameters should also have the same spelling - either 'enforce' or 'enforcing', make a consistent choice. Also, the output value of the 'selinuxenabled' command should be '0' = disabled, and '1' enabled - to conform with the grub.conf values of selinux (currently the opposite !!). This is just a plea from the 'user' side for CONSISTENCY throughout. > >> >> (This can be named 'enforce' rather than 'enforcing' - would help when >> trying to remember whether the runtime command is 'setenforce' or >> 'setenforcing') >> >> The variable 'SELINUXTYPE' is 'strict', 'targeted', 'myownpolicy', >> 'strangleddaemons', etc. >> >> -- >> 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 felipe_alfaro at linuxmail.org Mon Sep 20 18:33:09 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 20 Sep 2004 20:33:09 +0200 Subject: AVCs with ntpd In-Reply-To: References: Message-ID: <85686A5D-0B33-11D9-B155-000D9352858E@linuxmail.org> > I wonder about step 2. below. If you have the latest (and even just a > recent) kernel, all of the SELinux patches are in the kernel already. I?m running a custom kernel (exactly 2.6.9-rc2-mm1-VP-S1). Since I disabled SElinux, I had no support for it compiled in the kernel, thus the recompilation. > Bringing your system up2date is also a good idea as some of the > utilities > (nptd?) have SELinux related patches. I'm always running from RawHide ;-) > I also think that step 5. needs to be done before steps 3 and 4. > > You might boot a couple of times with 5. set, then do 3. and 4. > > At least that is what I have done. AFAIK, you don't need to get SElinux enabled in order to relabel the filesystem. It seems my problems are caused by vanilla kernels not having xattrs support for tmpfs yet. I'll take the RedHat kernel SRPM and will extract the tmpfs xattr support. Thanks! > BobG > > On Mon, 20 Sep 2004 14:18:17 +0200, Felipe Alfaro Solana wrote: >> OK, so I'm trying SElinux after having it disabled for some time. >> That's what I did: >> >> 1. Installed selinux-policy-targeted-1.17.16-2 >> 2. Recompiled the kernel with SElinux support >> 3. Booted into single user mode >> 4. Ran "fixfiles relabel" >> 5. Rebooted with "selinux=1" >> >> Now, I'm seeing a lot of these: >> >> audit(1095681913.039:0(: avc: denied { search } for pid=2515 >> exe=/usr/sbin/ntpd dev=tmpfs ino=357 scontext=user_u:system_r:ntpd_t >> tcontext=user_u:object_r"tmpfs_t tclass=dir >> >> The problem here is that I'm using UDEV and that the initial ramdisk >> mounts a tmpfs on top of "/dev", thus, covering the labeled "/dev" >> that >> resides on disk. >> >> How should I fix this? >> >> -- >> 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 Mon Sep 20 20:04:31 2004 From: kwade at redhat.com (Karsten Wade) Date: Mon, 20 Sep 2004 13:04:31 -0700 Subject: Variable naming confusion In-Reply-To: References: <414D205F.7000308@rcn.com> <414D205F.7000308@rcn.com> Message-ID: <1095710671.4078.14191.camel@erato.phig.org> On Mon, 2004-09-20 at 08:48, Bob Gustafson wrote: > This is just a plea from the 'user' side for CONSISTENCY throughout. +1 This is an agreement from the documentation side, good ideas! - Karsten, who wrote the prototype for /etc/sysconfig/selinux and would love to see it revised -- 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 felipe_alfaro at linuxmail.org Mon Sep 20 21:08:16 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 20 Sep 2004 23:08:16 +0200 Subject: More AVCs during boot Message-ID: <30DDF66C-0B49-11D9-B155-000D9352858E@linuxmail.org> Hi! With selinux-policy-targeted, I get this during boot: audit(1095721178.335:0): avc: denied { associate } for pid=508 exe=/sbin/restorecon name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem audit(1095721179.084:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=initctl dev=tmpfs ino=1992 scontext=system_u:object_r:initctl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which seem related related to "/dev/initctl". audit(1095721179.097:0): avc: denied { associate } for pid=721 exe=/usr/sbin/setfiles name=.udev.tdb dev=tmpfs ino=366 scontext=system_u:object_r:udev_tbl_t tcontext=system_u:object_r:tmpfs_t tclass=filesystem which is related to /dev/.udev.tdb audit(1095714008.289:0): avc: denied { setrlimit } for pid=2218 exe=/usr/sbin/named scontext=user_u:system_r:named_t tcontext=user_u:system_r:named_t tclass=process related to bind audit(1095714008.771:0): avc: denied { read } for pid=2251 exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t tclass=file related to ntpd. Any ideas? From dwalsh at redhat.com Mon Sep 20 21:18:14 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:18:14 -0400 Subject: More AVCs during boot In-Reply-To: <30DDF66C-0B49-11D9-B155-000D9352858E@linuxmail.org> References: <30DDF66C-0B49-11D9-B155-000D9352858E@linuxmail.org> Message-ID: <414F4916.2020301@redhat.com> Felipe Alfaro Solana wrote: > Hi! > > With selinux-policy-targeted, I get this during boot: > > audit(1095721178.335:0): avc: denied { associate } for pid=508 > exe=/sbin/restorecon name=initctl dev=tmpfs ino=1992 > scontext=system_u:object_r:initctl_t > tcontext=system_u:object_r:tmpfs_t tclass=filesystem > > audit(1095721179.084:0): avc: denied { associate } for pid=721 > exe=/usr/sbin/setfiles name=initctl dev=tmpfs ino=1992 > scontext=system_u:object_r:initctl_t > tcontext=system_u:object_r:tmpfs_t tclass=filesystem > > which seem related related to "/dev/initctl". > > audit(1095721179.097:0): avc: denied { associate } for pid=721 > exe=/usr/sbin/setfiles name=.udev.tdb dev=tmpfs ino=366 > scontext=system_u:object_r:udev_tbl_t > tcontext=system_u:object_r:tmpfs_t tclass=filesystem > > which is related to /dev/.udev.tdb > Latest policy should fix these. > audit(1095714008.289:0): avc: denied { setrlimit } for pid=2218 > exe=/usr/sbin/named scontext=user_u:system_r:named_t > tcontext=user_u:system_r:named_t tclass=process > > related to bind Added a rule to allow this in policy. > > audit(1095714008.771:0): avc: denied { read } for pid=2251 > exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 > scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t > tclass=file Which drift file are you accessing and where is it located? It should not be marked file_t? > > related to ntpd. > > Any ideas? > > -- > 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 Mon Sep 20 21:35:44 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Sep 2004 17:35:44 -0400 Subject: What is SELinux targeted policy? In-Reply-To: <20040920211657.GA25436@earthlink.net> References: <1095709136.3464.12.camel@junior.yellowhouse> <20040920211657.GA25436@earthlink.net> Message-ID: <414F4D30.6040001@redhat.com> When FC2 was released we attempted to add the NSA strict policy to the operating system. We were able to find hundreds of problems in the policy and we quickly found out that users who customized their environments in unexpected ways caused SELinux and the OS to conflict. We decided at that point to take a step back and go with a strategy where we would lock down a few daemons with SELinux and allow the rest of the system to run in the same manner with or without SELinux. Targeted policy was born. In targeted policy most processes run in a unconfined_t domain, which means for the most part they are not being confined by the SELinux policy. They are still governed by Standard unix security, but not effected by SELinux. Certain network daemons have policy and the unconfined_t policy transitions to those policies when the application starts. So when the system boots init runs in the unconfined_t policy, but when named starts up it transitions to the named_t domain and is locked down. We use the following policies nscd.te apache.te dhcpd.te named.te ntpd.te portmap.te snmpd.te squid.te syslogd.te Also users can select which daemons he want to have SELinux to protect via system-config-securitylevel. So if an admin finds that SELinux will not allow his apache web server to run the way he wants he can turn off the transition. This will drop it back to normal Unix protections, but all other daemons will continue to be protected by SELinux. Through the use of these "boolean" values the admin can increase or decrease the level of protection SELinux provides. In the future we plan on adding additional Domains that SELinux will protect. Strict policy is still available but will be not be installable directly, you can use selinux-config-securitylevel to turn it on and relabel the file system. Dan From felipe_alfaro at linuxmail.org Tue Sep 21 11:24:52 2004 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 21 Sep 2004 13:24:52 +0200 Subject: More AVCs during boot In-Reply-To: <414F4916.2020301@redhat.com> References: <30DDF66C-0B49-11D9-B155-000D9352858E@linuxmail.org> <414F4916.2020301@redhat.com> Message-ID: >> audit(1095714008.771:0): avc: denied { read } for pid=2251 >> exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 >> scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t >> tclass=file > > Which drift file are you accessing and where is it located? It should > not be marked file_t? /var/lib/ntp/drift How can I see the labeling for this file? From mayerf at tresys.com Tue Sep 21 13:41:00 2004 From: mayerf at tresys.com (Frank Mayer) Date: Tue, 21 Sep 2004 09:41:00 -0400 Subject: SELinux Symposium Call for Presentation Proposals (Second Announcement) In-Reply-To: <02c701c4951f$cd8cad50$a00c010a@columbia.tresys.com> Message-ID: <006b01c49fe0$a2410f80$320c010a@columbia.tresys.com> Just a reminder that the call for presentation proposals for the First SELinux Symposium remains open until October 1, 2004. See the formal call below for further information. Frank > CALL FOR PRESENTATION PROPOSALS > > FIRST SECURITY ENHANCED LINUX SYMPOSIUM (www.selinux-symposium.org) > > The inaugural symposium on Security Enhanced Linux (SELinux) will be > held March 2-4 2005 in the Silver Spring, Maryland, USA (near > Washington, DC). SELinux > brings the power of flexible mandatory access control such as type > enforcement to Linux. The symposium is an opportunity to learn about > SELinux and share technical and application experiences. > > The call for presentation and tutorial proposals is now open until > October 1, 2004. All proposals will be reviewed by the review > committees for inclusion in the symposium agenda. To submit > proposals visit http://www.selinux-symposium.org. From dwalsh at redhat.com Tue Sep 21 16:49:54 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 21 Sep 2004 12:49:54 -0400 Subject: More AVCs during boot In-Reply-To: References: <30DDF66C-0B49-11D9-B155-000D9352858E@linuxmail.org> <414F4916.2020301@redhat.com> Message-ID: <41505BB2.8040406@redhat.com> Felipe Alfaro Solana wrote: >>> audit(1095714008.771:0): avc: denied { read } for pid=2251 >>> exe=/usr/sbin/ntpd name=drift dev=hda2 ino=10289214 >>> scontext=user_u:system_r:ntpd_t tcontext=system_u:object_r:file_t >>> tclass=file >> >> >> Which drift file are you accessing and where is it located? It >> should not be marked file_t? > > > /var/lib/ntp/drift > ls -lZ /var/lib/ntp/drift To fix the labeling you can restorecon /var/lib/ntp/drift > How can I see the labeling for this file? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From russell at coker.com.au Wed Sep 22 12:07:31 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 22 Sep 2004 22:07:31 +1000 Subject: AVCs with ntpd In-Reply-To: References: Message-ID: <200409222207.31714.russell@coker.com.au> On Tue, 21 Sep 2004 00:15, Bob Gustafson wrote: > Bringing your system up2date is also a good idea as some of the utilities > (nptd?) have SELinux related patches. You are correct that some of the utilities have SE Linux related patches. Also one thing to note is that utilities and policy are changed in synchronisation. So if you upgrade one without the other when tracking rawhide then things might not work (NB upgrades other than from one release to another are not officially supported, tracking rawhide in every way should work but with partial upgrades you are on your own). ntpd does not have SE Linux related patches and we have no plans to do such things. > I also think that step 5. needs to be done before steps 3 and 4. Yes. Boot with "selinux=1 enforcing=0" to relabel it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Wed Sep 22 17:33:29 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 03:33:29 +1000 Subject: fsck.ext3 on bootup In-Reply-To: <4149DA4C.6030409@comcast.net> References: <4149DA4C.6030409@comcast.net> Message-ID: <200409230333.29662.russell@coker.com.au> On Fri, 17 Sep 2004 04:24, Tom London wrote: > Get these very early during boot up. I'm guessing we're trying to check > the 'early root' and that this is harmless. If so, > > Sep 16 10:50:36 fedora kernel: ACPI: Sleep Button (CM) [FUTS] > Sep 16 10:50:36 fedora kernel: audit(1095357002.303:0): avc: denied { > getattr } for pid=1839 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs > ino=2028 scontext=system_u:system_r:fsadm_t > tcontext=system_u:object_r:device_t tclass=blk_file Is this still happening with FC3T2 or the latest rawhide? -- 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 Wed Sep 22 18:29:36 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 04:29:36 +1000 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <4c4ba153040917113551b2c9fc@mail.gmail.com> References: <4149E8BA.8050507@comcast.net> <4c4ba153040916143927979f62@mail.gmail.com> <4c4ba153040917113551b2c9fc@mail.gmail.com> Message-ID: <200409230429.36586.russell@coker.com.au> On Sat, 18 Sep 2004 04:35, Tom London wrote: > Need this in rhgb.te: > > --- /etc/selinux/strict/src-1.17.18-1/policy/domains/program/rhgb.te > 2004-09-17 11:32:00.886510890 -0700 > +++ ./rhgb.te 2004-09-17 11:33:42.601099238 -0700 > @@ -34,7 +34,7 @@ > allow insmod_t rhgb_t:fd use; > > allow rhgb_t ramfs_t:filesystem { mount unmount }; > -allow rhgb_t root_t:dir { mounton }; > +allow rhgb_t { root_t mnt_t }:dir { mounton }; > allow rhgb_t rhgb_t:capability { sys_admin }; > dontaudit rhgb_t var_run_t:dir { search }; > > Otherwise can't mount.... Does it still need access to mount on type root_t? RHGB doesn't work for me at the moment due to other errors so I can't test. -- 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 alex at darkhonor.com Wed Sep 22 18:33:26 2004 From: alex at darkhonor.com (Alex Ackerman) Date: Wed, 22 Sep 2004 14:33:26 -0400 Subject: What is SELinux targeted policy? Message-ID: >-----Original Message----- >From: fedora-selinux-list-bounces at redhat.com on behalf of Daniel J Walsh >Sent: Mon 9/20/2004 5:35 PM >To: For users of Fedora Core releases; Fedora SELinux support list for users & developers.; Development discussions related to Fedora Core >Subject: What is SELinux targeted policy? >Strict policy is still available but will be not be installable >directly, you can use selinux-config-securitylevel to turn it on >and relabel the file system. Does this mean the strict policy will not work on a Fedora Core system at all or that it will take some customization prior to working effectively? Also, are there plans to support te domains for either Sendmail or Postfix via the SELinux policy in the near future? What about PostgreSQL/MySQL? Thanks! Alex Ackerman http://www.darkhonor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Sep 22 18:46:42 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 22 Sep 2004 14:46:42 -0400 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <200409230429.36586.russell@coker.com.au> References: <4149E8BA.8050507@comcast.net> <4c4ba153040916143927979f62@mail.gmail.com> <4c4ba153040917113551b2c9fc@mail.gmail.com> <200409230429.36586.russell@coker.com.au> Message-ID: <4151C892.9080405@redhat.com> Russell Coker wrote: >On Sat, 18 Sep 2004 04:35, Tom London wrote: > > >>Need this in rhgb.te: >> >>--- /etc/selinux/strict/src-1.17.18-1/policy/domains/program/rhgb.te >> 2004-09-17 11:32:00.886510890 -0700 >>+++ ./rhgb.te 2004-09-17 11:33:42.601099238 -0700 >>@@ -34,7 +34,7 @@ >> allow insmod_t rhgb_t:fd use; >> >> allow rhgb_t ramfs_t:filesystem { mount unmount }; >>-allow rhgb_t root_t:dir { mounton }; >>+allow rhgb_t { root_t mnt_t }:dir { mounton }; >> allow rhgb_t rhgb_t:capability { sys_admin }; >> dontaudit rhgb_t var_run_t:dir { search }; >> >>Otherwise can't mount.... >> >> > >Does it still need access to mount on type root_t? > >RHGB doesn't work for me at the moment due to other errors so I can't test. > > > No I removed root_t. From dwalsh at redhat.com Wed Sep 22 18:50:52 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 22 Sep 2004 14:50:52 -0400 Subject: What is SELinux targeted policy? In-Reply-To: References: Message-ID: <4151C98C.8010609@redhat.com> Alex Ackerman wrote: > >-----Original Message----- > >From: fedora-selinux-list-bounces at redhat.com on behalf of Daniel J Walsh > >Sent: Mon 9/20/2004 5:35 PM > >To: For users of Fedora Core releases; Fedora SELinux support list > for users & developers.; Development discussions related to Fedora Core > >Subject: What is SELinux targeted policy? > >Strict policy is still available but will be not be installable > >directly, you can use selinux-config-securitylevel to turn it on > >and relabel the file system. > > Does this mean the strict policy will not work on a Fedora Core system > at all or that it will take some customization prior to working > effectively? Also, are there plans to support te domains for either > Sendmail or Postfix via the SELinux policy in the near future? What > about PostgreSQL/MySQL? > Yes strict policy will work on Fedora Core. And we are working to make transitioning from one policy to the other easier. system-config-securitylevel allows you to transition from one to the other by building a relabel into the startup scripts. We would like to add ftp and a mail agent to targeted policy eventually. We would like to get vsftpd to work like login in that after the users logs in a new process gets execed under the users context or Anonymous FTP context. The problem with mail agents is that alot of them want to touch the users home directories, and as soon as they do we get into labeling problems around the users home directory which we are trying to avoid in targeted policy. Dan > Thanks! > Alex Ackerman > http://www.darkhonor.com > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From russell at coker.com.au Thu Sep 23 01:54:46 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 11:54:46 +1000 Subject: mailman... In-Reply-To: <41490E37.1080106@comcast.net> References: <41490E37.1080106@comcast.net> Message-ID: <200409231154.46987.russell@coker.com.au> Colin's suggestion of a bugzilla about file locations is good. Also you need the attached patch to the policy. But it still won't work, even more needs to be done. -- 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: 760 bytes Desc: not available URL: From russell at coker.com.au Thu Sep 23 12:51:32 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 23 Sep 2004 22:51:32 +1000 Subject: mount ? In-Reply-To: <4149D2A4.5060000@redhat.com> References: <4149CF5B.2040900@comcast.net> <4149D2A4.5060000@redhat.com> Message-ID: <200409232251.32297.russell@coker.com.au> On Fri, 17 Sep 2004 03:51, Daniel J Walsh wrote: > Tom London wrote: > > Running strict/enforcing, with latest from Dan's tree. > > > > The 'mount' command produces no output when run in enforcing mode. > > Works fine in permissive mode. > > Try this. > > diff --exclude-from=exclude -N -u -r nsapolicy/domains/program/mount.te > policy-1.17.17/domains/program/mount.te > --- nsapolicy/domains/program/mount.te 2004-09-14 09:18:10.000000000 -0400 > +++ policy-1.17.17/domains/program/mount.te 2004-09-16 > 13:50:45.899174425 -0400 > @@ -93,7 +93,8 @@ > allow mount_t file_type:filesystem { unmount mount relabelto }; > > allow mount_t mnt_t:dir { getattr }; > -dontaudit mount_t { userdomain kernel_t}:fd use; > +allow mount_t { userdomain }:fd use; > +dontaudit mount_t { kernel_t}:fd use; https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132914 This is a bug in su which we have to get fixed. In the mean time it's best to have ifdef(`distro_redhat' around that as no other distribution has this issue. -- 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 Fri Sep 24 03:14:08 2004 From: selinux at gmail.com (Tom London) Date: Thu, 23 Sep 2004 20:14:08 -0700 Subject: fsck.ext3 on bootup In-Reply-To: <200409230333.29662.russell@coker.com.au> References: <4149DA4C.6030409@comcast.net> <200409230333.29662.russell@coker.com.au> Message-ID: <4c4ba1530409232014438385b9@mail.gmail.com> Still happening with latest Rawhide with Dan's latest (selinux-policy-strict-1.17.20-3) tom On Thu, 23 Sep 2004 03:33:29 +1000, Russell Coker wrote: > On Fri, 17 Sep 2004 04:24, Tom London wrote: > > Get these very early during boot up. I'm guessing we're trying to check > > the 'early root' and that this is harmless. If so, > > > > Sep 16 10:50:36 fedora kernel: ACPI: Sleep Button (CM) [FUTS] > > Sep 16 10:50:36 fedora kernel: audit(1095357002.303:0): avc: denied { > > getattr } for pid=1839 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs > > ino=2028 scontext=system_u:system_r:fsadm_t > > tcontext=system_u:object_r:device_t tclass=blk_file > > Is this still happening with FC3T2 or the latest rawhide? > > -- > http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages > http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark > http://www.coker.com.au/postal/ Postal SMTP/POP benchmark > http://www.coker.com.au/~russell/ My home page > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London From selinux at gmail.com Fri Sep 24 03:33:45 2004 From: selinux at gmail.com (Tom London) Date: Thu, 23 Sep 2004 20:33:45 -0700 Subject: firefox, gaim, /lib/ld-2.3.3.so ? Message-ID: <4c4ba1530409232033577a175@mail.gmail.com> After being on the road for a bit, I did a 'yum update' to grab the new stuff. After doing so (>300 packages), running strict/enforcing, firefox and gaim fail to start: Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:ld_so_t tclass=file Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin name=.fonts.cache-1 dev=hda2 ino=2752979 scontext=user_u:user_r:user_mozilla_t tcontext=user_u:object_r:user_home_t tclass=file and Sep 23 20:26:51 fedora kernel: audit(1095996411.010:0): avc: denied { write } for pid=4838 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file Running in permissive mode both start, and /lib/ld-2.3.3.so is not written to. Write to /lib/ld-2.3.3.so ????? Did I do something stupid? tom -- Tom London From selinux at gmail.com Fri Sep 24 03:38:55 2004 From: selinux at gmail.com (Tom London) Date: Thu, 23 Sep 2004 20:38:55 -0700 Subject: get the red and green back (really consoletype, rhgb) In-Reply-To: <4151C892.9080405@redhat.com> References: <4149E8BA.8050507@comcast.net> <4c4ba153040916143927979f62@mail.gmail.com> <4c4ba153040917113551b2c9fc@mail.gmail.com> <200409230429.36586.russell@coker.com.au> <4151C892.9080405@redhat.com> Message-ID: <4c4ba15304092320384489449@mail.gmail.com> Runing latest Rawhide w/Dan's latest stuff: rhgb fails with: Sep 23 19:41:43 fedora kernel: audit(1095968474.168:0): avc: denied { search } for pid=1593 exe=/usr/bin/rhgb name=rhgb dev=hda2 ino=280446 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:mnt_t tclass=dir Sep 23 19:41:43 fedora kernel: audit(1095968474.168:0): avc: denied { search } for pid=1593 exe=/usr/bin/rhgb name=rhgb dev=hda2 ino=280446 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:mnt_t tclass=dir tom On Wed, 22 Sep 2004 14:46:42 -0400, Daniel J Walsh wrote: > Russell Coker wrote: > > >On Sat, 18 Sep 2004 04:35, Tom London wrote: > > > > > >>Need this in rhgb.te: > >> > >>--- /etc/selinux/strict/src-1.17.18-1/policy/domains/program/rhgb.te > >> 2004-09-17 11:32:00.886510890 -0700 > >>+++ ./rhgb.te 2004-09-17 11:33:42.601099238 -0700 > >>@@ -34,7 +34,7 @@ > >> allow insmod_t rhgb_t:fd use; > >> > >> allow rhgb_t ramfs_t:filesystem { mount unmount }; > >>-allow rhgb_t root_t:dir { mounton }; > >>+allow rhgb_t { root_t mnt_t }:dir { mounton }; > >> allow rhgb_t rhgb_t:capability { sys_admin }; > >> dontaudit rhgb_t var_run_t:dir { search }; > >> > >>Otherwise can't mount.... > >> > >> > > > >Does it still need access to mount on type root_t? > > > >RHGB doesn't work for me at the moment due to other errors so I can't test. > > > > > > > No I removed root_t. > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Tom London From walters at redhat.com Fri Sep 24 04:18:05 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 24 Sep 2004 00:18:05 -0400 Subject: firefox, gaim, /lib/ld-2.3.3.so ? In-Reply-To: <4c4ba1530409232033577a175@mail.gmail.com> References: <4c4ba1530409232033577a175@mail.gmail.com> Message-ID: <1095999485.4597.15.camel@nexus.verbum.private> On Thu, 2004-09-23 at 20:33 -0700, Tom London wrote: > After being on the road for a bit, I did a 'yum update' to grab the new stuff. > > After doing so (>300 packages), running strict/enforcing, > firefox and gaim fail to start: > > Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied > { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 > scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:object_r:ld_so_t tclass=file That is bizarre. My guess is some recent glibc change. > Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied > { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin > name=.fonts.cache-1 dev=hda2 ino=2752979 > scontext=user_u:user_r:user_mozilla_t > tcontext=user_u:object_r:user_home_t tclass=file The fontconfig cache as it's currently implemented is going to be a perennial problem for SELinux. Any application that uses fontconfig will want to read and write to the cache file. Currently the fontconfig library has a bit of code: FcBool FcGlobalCacheSave (FcGlobalCache *cache, const FcChar8 *cache_file) { /* ... */ #if defined (HAVE_GETUID) && defined (HAVE_GETEUID) /* Set-UID programs can't safely update the cache */ if (getuid () != geteuid ()) return FcFalse; #endif But there's really no equivalent to that check for SELinux. A short term solution might be to give .fonts.cache-1 its own type by patching fontconfig to put it in a ~/.fontconfig directory which has a type user_font_cache_t that we can statically assign, and when .fonts.cache-1 is created in that directory it should inherit the type, so it won't just be user_home_t. Then for every user domain except user_t we just dontaudit writes to it. Was mozilla actually not starting because of this? That would probably be a bug in the fontconfig libraries. A longer term solution would be to make the fontconfig cache a daemon that controls access to fonts more precisely. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Fri Sep 24 10:59:15 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Sep 2004 20:59:15 +1000 Subject: fsck.ext3 on bootup In-Reply-To: <4c4ba1530409232014438385b9@mail.gmail.com> References: <4149DA4C.6030409@comcast.net> <200409230333.29662.russell@coker.com.au> <4c4ba1530409232014438385b9@mail.gmail.com> Message-ID: <200409242059.15724.russell@coker.com.au> On Fri, 24 Sep 2004 13:14, Tom London wrote: > Still happening with latest Rawhide with Dan's latest > (selinux-policy-strict-1.17.20-3) This is bizarre, I can't reproduce it. Could you please give us full details of your boot setup, the root device, that type of storage, and anything else that seems remotely relevant? -- 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 kwade at redhat.com Fri Sep 24 11:47:23 2004 From: kwade at redhat.com (Karsten Wade) Date: Fri, 24 Sep 2004 04:47:23 -0700 Subject: updated SELinux FAQ Message-ID: <1096026442.21077.6684.camel@erato.phig.org> Fedora Core 3 test 2: http://fedora.redhat.com/docs/selinux-faq-fc3test2/ (v. 1.3-1) Fedora Core 2: http://fedora.redhat.com/docs/selinux-faq-fc2/ (v. 1.2-8) 1. Notice the new URLs. These are permanent homes. Currently, the copies on people.redhat.com are up-to-date, and I will work out some form of redirect in the near future. 2. Content *should* be technically updated to match test2. If not, see 3. 3. If you have bugs or additional questions (and hopefully answers), use the bugzilla form that is linked from the first Tip box "Making changes/additions to the Fedora SELinux FAQ". 4. A few new questions in this version: Q: What is the SELinux targeted policy? Q: What daemons are protected by the targeted policy? Q: Which daemons will you add to the targeted policy? How about Sendmail, Postfix, MySQL, or PostgreSQL? Q: What about the strict policy? Does it even work? Q: How do I install/not install SELinux? Q: How do I switch the policy I'm using? Q: How do I enable/disable SELinux protection on specific daemons under the targeted policy? Q: Why does SELINUX=disabled not work for me? 5. Lifecycle comments: I'll maintain this FAQ as long as it is useful. This FAQ is particular to each version of Fedora Core. Each version of this FAQ will follow the version of Fedora to the Legacy Project, when the time comes. - 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 russell at coker.com.au Fri Sep 24 12:58:30 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 24 Sep 2004 22:58:30 +1000 Subject: What is SELinux targeted policy? In-Reply-To: References: Message-ID: <200409242258.30315.russell@coker.com.au> On Thu, 23 Sep 2004 04:33, "Alex Ackerman" wrote: > Does this mean the strict policy will not work on a Fedora Core system at > all or that it will take some customization prior to working effectively? > Also, are there plans to support te domains for either Sendmail or Postfix > via the SELinux policy in the near future? What about PostgreSQL/MySQL? The strict policy works well for reasonably default configurations. On all the machines I use seriously (IE not test machines) I run the strict policy. It's been working well for me for years. But using strict policy requires that you know how to write policy if you want to go too far from the defaults, if this is a problem for you then you want the targeted policy. We plan to continue slowly adding domains to the targeted policy. Sendmail, Postfix, PostgreSQL and MySQL are all good candidates for that. -- 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 Fri Sep 24 14:26:14 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 07:26:14 -0700 Subject: firefox, gaim, /lib/ld-2.3.3.so ? In-Reply-To: <1095999485.4597.15.camel@nexus.verbum.private> References: <4c4ba1530409232033577a175@mail.gmail.com> <1095999485.4597.15.camel@nexus.verbum.private> Message-ID: <4c4ba15304092407262cd2f41f@mail.gmail.com> When in strict/enforcing, mozilla fails to start because or the /lib/ld-2.3.3.so 'violation'. I get the .fonts.cache avc when running in permissive mode. I haven't modified the policy to allow the /lib/ld-2.3.3.so access to see the effect of this failing. Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to start firefox, thunderbird and gaim, but nothing else.. Could it also be a gtk2 problem? tom On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters wrote: > On Thu, 2004-09-23 at 20:33 -0700, Tom London wrote: > > After being on the road for a bit, I did a 'yum update' to grab the new stuff. > > > > After doing so (>300 packages), running strict/enforcing, > > firefox and gaim fail to start: > > > > Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied > > { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 > > scontext=user_u:user_r:user_mozilla_t > > tcontext=system_u:object_r:ld_so_t tclass=file > > That is bizarre. My guess is some recent glibc change. > > > Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied > > { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin > > name=.fonts.cache-1 dev=hda2 ino=2752979 > > scontext=user_u:user_r:user_mozilla_t > > tcontext=user_u:object_r:user_home_t tclass=file > > The fontconfig cache as it's currently implemented is going to be a > perennial problem for SELinux. Any application that uses fontconfig > will want to read and write to the cache file. > > Currently the fontconfig library has a bit of code: > FcBool > FcGlobalCacheSave (FcGlobalCache *cache, > const FcChar8 *cache_file) > { > /* ... */ > #if defined (HAVE_GETUID) && defined (HAVE_GETEUID) > /* Set-UID programs can't safely update the cache */ > if (getuid () != geteuid ()) > return FcFalse; > #endif > > But there's really no equivalent to that check for SELinux. > > A short term solution might be to give .fonts.cache-1 its own type by > patching fontconfig to put it in a ~/.fontconfig directory which has a > type user_font_cache_t that we can statically assign, and > when .fonts.cache-1 is created in that directory it should inherit the > type, so it won't just be user_home_t. Then for every user domain > except user_t we just dontaudit writes to it. > > Was mozilla actually not starting because of this? That would probably > be a bug in the fontconfig libraries. > > A longer term solution would be to make the fontconfig cache a daemon > that controls access to fonts more precisely. > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > -- Tom London From selinux at gmail.com Fri Sep 24 15:21:22 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 08:21:22 -0700 Subject: firefox, gaim, /lib/ld-2.3.3.so ? In-Reply-To: <4c4ba15304092407262cd2f41f@mail.gmail.com> References: <4c4ba1530409232033577a175@mail.gmail.com> <1095999485.4597.15.camel@nexus.verbum.private> <4c4ba15304092407262cd2f41f@mail.gmail.com> Message-ID: <4c4ba15304092408217886a026@mail.gmail.com> Still get /lib/ld-2.3.3.so avc with latest rawhide gtk2 download. I'm not sure its the right place, but I'll bugzilla this agains glibc. tom On Fri, 24 Sep 2004 07:26:14 -0700, Tom London wrote: > When in strict/enforcing, mozilla fails to start because or the > /lib/ld-2.3.3.so 'violation'. > > I get the .fonts.cache avc when running in permissive mode. I haven't > modified the policy to allow the /lib/ld-2.3.3.so access to see the > effect of this failing. > > Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to > start firefox, thunderbird and gaim, but nothing else.. Could it also > be a gtk2 problem? > > tom > > > > On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters wrote: > > On Thu, 2004-09-23 at 20:33 -0700, Tom London wrote: > > > After being on the road for a bit, I did a 'yum update' to grab the new stuff. > > > > > > After doing so (>300 packages), running strict/enforcing, > > > firefox and gaim fail to start: > > > > > > Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied > > > { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 > > > scontext=user_u:user_r:user_mozilla_t > > > tcontext=system_u:object_r:ld_so_t tclass=file > > > > That is bizarre. My guess is some recent glibc change. > > > > > Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied > > > { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin > > > name=.fonts.cache-1 dev=hda2 ino=2752979 > > > scontext=user_u:user_r:user_mozilla_t > > > tcontext=user_u:object_r:user_home_t tclass=file > > > > The fontconfig cache as it's currently implemented is going to be a > > perennial problem for SELinux. Any application that uses fontconfig > > will want to read and write to the cache file. > > > > Currently the fontconfig library has a bit of code: > > FcBool > > FcGlobalCacheSave (FcGlobalCache *cache, > > const FcChar8 *cache_file) > > { > > /* ... */ > > #if defined (HAVE_GETUID) && defined (HAVE_GETEUID) > > /* Set-UID programs can't safely update the cache */ > > if (getuid () != geteuid ()) > > return FcFalse; > > #endif > > > > But there's really no equivalent to that check for SELinux. > > > > A short term solution might be to give .fonts.cache-1 its own type by > > patching fontconfig to put it in a ~/.fontconfig directory which has a > > type user_font_cache_t that we can statically assign, and > > when .fonts.cache-1 is created in that directory it should inherit the > > type, so it won't just be user_home_t. Then for every user domain > > except user_t we just dontaudit writes to it. > > > > Was mozilla actually not starting because of this? That would probably > > be a bug in the fontconfig libraries. > > > > A longer term solution would be to make the fontconfig cache a daemon > > that controls access to fonts more precisely. > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > -- > Tom London > -- Tom London From selinux at gmail.com Fri Sep 24 15:50:02 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 08:50:02 -0700 Subject: fsck.ext3 on bootup In-Reply-To: <200409242059.15724.russell@coker.com.au> References: <4149DA4C.6030409@comcast.net> <200409230333.29662.russell@coker.com.au> <4c4ba1530409232014438385b9@mail.gmail.com> <200409242059.15724.russell@coker.com.au> Message-ID: <4c4ba1530409240850426c3b96@mail.gmail.com> OK. I'll attach the boot log, grub.conf Boot drive reports as: Hitachi IC35L060AVV207-0 : 40GB ATA 100 7200-RPM 3.5" 2MB Here is my mtab: /dev/hda2 on / type ext3 (rw) none on /proc type proc (rw) none on /sys type sysfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) usbfs on /proc/bus/usb type usbfs (rw) /dev/hda1 on /boot type ext3 (rw) none on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) nfsd on /proc/fs/nfsd type nfsd (rw) I notice that my initrd is dated 4 September. Is it possible that it was made with an 'older' mkinitrd that isn't 'doing the right thing'? I'll test this later today. tom On Fri, 24 Sep 2004 20:59:15 +1000, Russell Coker wrote: > On Fri, 24 Sep 2004 13:14, Tom London wrote: > > Still happening with latest Rawhide with Dan's latest > > (selinux-policy-strict-1.17.20-3) > > This is bizarre, I can't reproduce it. > > Could you please give us full details of your boot setup, the root device, > that type of storage, and anything else that seems remotely relevant? > > > > -- > 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 > -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: grub.conf Type: application/octet-stream Size: 693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: boot-log.bz2 Type: application/x-bzip Size: 11406 bytes Desc: not available URL: From russell at coker.com.au Fri Sep 24 16:20:15 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 25 Sep 2004 02:20:15 +1000 Subject: fsck.ext3 on bootup In-Reply-To: <4c4ba1530409240850426c3b96@mail.gmail.com> References: <4149DA4C.6030409@comcast.net> <200409242059.15724.russell@coker.com.au> <4c4ba1530409240850426c3b96@mail.gmail.com> Message-ID: <200409250220.15285.russell@coker.com.au> On Sat, 25 Sep 2004 01:50, Tom London wrote: > Here is my mtab: > /dev/hda2 on / type ext3 (rw) > > I notice that my initrd is dated 4 September. Is it possible that it > was made with an 'older' mkinitrd that isn't 'doing the right thing'? > I'll test this later today. Please test it with an initrd image made from the latest mkinitrd. If it still happens then I guess the reason why you see it and I don't would be because I use only LVM. If you report that you still see it with the latest initrd then I'll find a spare machine for a non-LVM install to test. -- 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 Sat Sep 25 04:19:28 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 21:19:28 -0700 Subject: fsck.ext3 on bootup In-Reply-To: <200409250220.15285.russell@coker.com.au> References: <4149DA4C.6030409@comcast.net> <200409242059.15724.russell@coker.com.au> <4c4ba1530409240850426c3b96@mail.gmail.com> <200409250220.15285.russell@coker.com.au> Message-ID: <4c4ba15304092421194618e27f@mail.gmail.com> OK. I made a new initrd using mkinitrd-4.1.12-1, rebooted, but the result is the same. Sorry.... Anything else I can try? tom Sep 24 20:57:26 fedora smartd: smartd startup succeeded Sep 24 20:57:26 fedora kernel: ACPI: Power Button (FF) [PWRF] Sep 24 20:57:26 fedora kernel: ACPI: Sleep Button (CM) [FUTS] Sep 24 20:57:26 fedora kernel: audit(1096084614.355:0): avc: denied { getattr } for pid=1585 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=1192 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file Sep 24 20:57:26 fedora acpid: acpid startup succeeded Sep 24 20:57:26 fedora kernel: EXT3 FS on hda2, internal journal Sep 24 20:57:27 fedora kernel: device-mapper: 4.1.0-ioctl (2003-12-10) initialised: dm at uk.sistina.com Sep 24 20:57:27 fedora kernel: audit(1096084616.708:0): avc: denied { getattr } for pid=1820 exe=/sbin/fsck.ext3 path=/dev/root dev=tmpfs ino=1192 scontext=system_u:system_r:fsadm_t tcontext=system_u:object_r:device_t tclass=blk_file Sep 24 20:57:27 fedora kernel: kjournald starting. Commit interval 5 seconds Sep 24 20:57:27 fedora kernel: EXT3 FS on hda1, internal journal Sep 24 20:57:27 fedora kernel: EXT3-fs: mounted filesystem with ordered data mode. On Sat, 25 Sep 2004 02:20:15 +1000, Russell Coker wrote: > On Sat, 25 Sep 2004 01:50, Tom London wrote: > > Here is my mtab: > > /dev/hda2 on / type ext3 (rw) > > > > I notice that my initrd is dated 4 September. Is it possible that it > > was made with an 'older' mkinitrd that isn't 'doing the right thing'? > > I'll test this later today. > > Please test it with an initrd image made from the latest mkinitrd. If it > still happens then I guess the reason why you see it and I don't would be > because I use only LVM. > > If you report that you still see it with the latest initrd then I'll find a > spare machine for a non-LVM install to test. > > > > -- > 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 > -- Tom London From selinux at gmail.com Sat Sep 25 05:25:12 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 22:25:12 -0700 Subject: firefox, gaim, /lib/ld-2.3.3.so ? In-Reply-To: <4c4ba15304092408217886a026@mail.gmail.com> References: <4c4ba1530409232033577a175@mail.gmail.com> <1095999485.4597.15.camel@nexus.verbum.private> <4c4ba15304092407262cd2f41f@mail.gmail.com> <4c4ba15304092408217886a026@mail.gmail.com> Message-ID: <4c4ba153040924222564c0bb2d@mail.gmail.com> This is curious.... I've straced gaim both under strict/enforcing and strict/permissive. It appears that under strict/enforcing, a call to 'mprotect(..., ..., PROT_READ|PROT_WRITE)' fails, and gaim segv faults. This same call succeeds under strict/permissive, and gaim then starts successfully. This also seems to be where the AVC to /lib/ld-2.3.3.so is produced. Here is the bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505 tom On Fri, 24 Sep 2004 08:21:22 -0700, Tom London wrote: > Still get /lib/ld-2.3.3.so avc with latest rawhide gtk2 download. > > I'm not sure its the right place, but I'll bugzilla this agains glibc. > > tom > > > > On Fri, 24 Sep 2004 07:26:14 -0700, Tom London wrote: > > When in strict/enforcing, mozilla fails to start because or the > > /lib/ld-2.3.3.so 'violation'. > > > > I get the .fonts.cache avc when running in permissive mode. I haven't > > modified the policy to allow the /lib/ld-2.3.3.so access to see the > > effect of this failing. > > > > Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to > > start firefox, thunderbird and gaim, but nothing else.. Could it also > > be a gtk2 problem? > > > > tom > > > > > > > > On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters wrote: > > > On Thu, 2004-09-23 at 20:33 -0700, Tom London wrote: > > > > After being on the road for a bit, I did a 'yum update' to grab the new stuff. > > > > > > > > After doing so (>300 packages), running strict/enforcing, > > > > firefox and gaim fail to start: > > > > > > > > Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied > > > > { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 > > > > scontext=user_u:user_r:user_mozilla_t > > > > tcontext=system_u:object_r:ld_so_t tclass=file > > > > > > That is bizarre. My guess is some recent glibc change. > > > > > > > Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied > > > > { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin > > > > name=.fonts.cache-1 dev=hda2 ino=2752979 > > > > scontext=user_u:user_r:user_mozilla_t > > > > tcontext=user_u:object_r:user_home_t tclass=file > > > > > > The fontconfig cache as it's currently implemented is going to be a > > > perennial problem for SELinux. Any application that uses fontconfig > > > will want to read and write to the cache file. > > > > > > Currently the fontconfig library has a bit of code: > > > FcBool > > > FcGlobalCacheSave (FcGlobalCache *cache, > > > const FcChar8 *cache_file) > > > { > > > /* ... */ > > > #if defined (HAVE_GETUID) && defined (HAVE_GETEUID) > > > /* Set-UID programs can't safely update the cache */ > > > if (getuid () != geteuid ()) > > > return FcFalse; > > > #endif > > > > > > But there's really no equivalent to that check for SELinux. > > > > > > A short term solution might be to give .fonts.cache-1 its own type by > > > patching fontconfig to put it in a ~/.fontconfig directory which has a > > > type user_font_cache_t that we can statically assign, and > > > when .fonts.cache-1 is created in that directory it should inherit the > > > type, so it won't just be user_home_t. Then for every user domain > > > except user_t we just dontaudit writes to it. > > > > > > Was mozilla actually not starting because of this? That would probably > > > be a bug in the fontconfig libraries. > > > > > > A longer term solution would be to make the fontconfig cache a daemon > > > that controls access to fonts more precisely. > > > > > > > > > > > > -- > > > fedora-selinux-list mailing list > > > fedora-selinux-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > > > > > > > > > > -- > > Tom London > > > > > -- > Tom London > -- Tom London From selinux at gmail.com Sat Sep 25 05:38:24 2004 From: selinux at gmail.com (Tom London) Date: Fri, 24 Sep 2004 22:38:24 -0700 Subject: /lib/tls/i[456]86/libdb-4.2.so - patch to types.fc Message-ID: <4c4ba15304092422385e87a316@mail.gmail.com> Running 'setfiles -vv $FC /lib' produces: setfiles: labeling files under /lib setfiles: relabeling /lib/tls/i586/libdb-4.2.so from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: conflicting specifications for /lib/tls/i486/libdb-4.2.so and /lib/tls/i586/libdb-4.2.so, using system_u:object_r:shlib_t. setfiles: relabeling /lib/tls/i486/libdb-4.2.so from system_u:object_r:lib_t to system_u:object_r:shlib_t Suggest this patch: --- types.fc 2004-09-23 11:02:38.000000000 -0700 +++ /tmp/types.fc 2004-09-24 22:35:40.913346939 -0700 @@ -302,7 +302,7 @@ /lib(64)?/[^/]*/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /lib(64)?/security/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t /lib(64)?/tls/i686/cmov/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t -/lib(64)?/tls/i486/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t +/lib(64)?/tls/i[456]86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t # # /sbin tom -- Tom London From selinux at gmail.com Sat Sep 25 17:49:10 2004 From: selinux at gmail.com (Tom London) Date: Sat, 25 Sep 2004 10:49:10 -0700 Subject: setenforce notice to dbus, 13 minute delay? Message-ID: <4c4ba15304092510492e9cfac7@mail.gmail.com> I notice that when I do 'setenforce', dbus is notified. But there appears to be a significant delay, e.g., 13-15 minutes, before dbus logs it. Is this just log buffer 'flush buffer' timing? Is this to be expected? thanks, tom Sep 25 10:29:54 fedora kernel: audit(1096133394.349:0): avc: granted { setenforce } for pid=4107 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Sep 25 10:43:21 fedora dbus: avc: received setenforce notice (enforcing=0) -- Tom London From walters at redhat.com Sat Sep 25 18:04:56 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 25 Sep 2004 14:04:56 -0400 Subject: setenforce notice to dbus, 13 minute delay? In-Reply-To: <4c4ba15304092510492e9cfac7@mail.gmail.com> References: <4c4ba15304092510492e9cfac7@mail.gmail.com> Message-ID: <1096135496.4452.40.camel@nexus.verbum.private> On Sat, 2004-09-25 at 10:49 -0700, Tom London wrote: > I notice that when I do 'setenforce', dbus is notified. > But there appears to be a significant delay, e.g., 13-15 minutes, > before dbus logs it. Up until fairly recently, the reload only happened when a permission was actually checked. It was later changed to use a thread, so you should see the reload message right away. That change was done in the D-BUS CVS, not sure if it's in the 0.22 in rawhide. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From selinux at gmail.com Sat Sep 25 18:03:43 2004 From: selinux at gmail.com (Tom London) Date: Sat, 25 Sep 2004 11:03:43 -0700 Subject: cups.te: ptal_t needs to read usbfs_t Message-ID: <4c4ba15304092511033ca5e5f1@mail.gmail.com> When hpoj starts, it produces the following: Sep 25 10:28:24 fedora kernel: audit(1096133304.072:0): avc: denied { read } for pid=2769 exe=/usr/sbin/ptal-mlcd dev=usbfs ino=2309 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbfs_t tclass=dir ptal_t already has 'r_dir_file(ptal_t, usbdevfs_t)'. Suggest adding 'r_dir_file(ptal_t, usbfs_t)' [Are both still needed?] tom --- cups.te 2004-09-23 11:02:38.000000000 -0700 +++ /tmp/cups.te 2004-09-25 10:57:11.147771270 -0700 @@ -156,6 +156,7 @@ allow ptal_t printer_device_t:chr_file { ioctl read write }; allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; r_dir_file(ptal_t, usbdevfs_t) +r_dir_file(ptal_t, usbfs_t) allow cupsd_t ptal_var_run_t:sock_file { write setattr }; allow cupsd_t ptal_t:unix_stream_socket { connectto }; allow cupsd_t ptal_var_run_t:dir { search }; -- Tom London From selinux at gmail.com Sat Sep 25 18:27:06 2004 From: selinux at gmail.com (Tom London) Date: Sat, 25 Sep 2004 11:27:06 -0700 Subject: hald - r/w access to /dev/usb/lp0? Message-ID: <4c4ba153040925112714a5f9ac@mail.gmail.com> When haldaemon starts, and typically just after the text 'login:' appears but before the graphical stuff takes over, I get: Sep 25 10:28:57 fedora kernel: audit(1096133337.944:0): avc: denied { read write } for pid=3187 exe=/usr/sbin/hald name=lp0 dev=tmpfs ino=5073 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printer_device_t tclass=chr_file referring to /dev/usb/lp0. Does hald need read/write access to the printer_device? Seems strange, but if so, we need to add to hald.te. If not, any idea what's happening? tom -- Tom London From russell at coker.com.au Sat Sep 25 19:34:51 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 05:34:51 +1000 Subject: hald - r/w access to /dev/usb/lp0? In-Reply-To: <4c4ba153040925112714a5f9ac@mail.gmail.com> References: <4c4ba153040925112714a5f9ac@mail.gmail.com> Message-ID: <200409260534.51592.russell@coker.com.au> On Sun, 26 Sep 2004 04:27, Tom London wrote: > When haldaemon starts, and typically just after the text 'login:' > appears but before the graphical stuff takes over, I get: > > Sep 25 10:28:57 fedora kernel: audit(1096133337.944:0): avc: denied > { read write } for pid=3187 exe=/usr/sbin/hald name=lp0 dev=tmpfs > ino=5073 scontext=system_u:system_r:hald_t > tcontext=system_u:object_r:printer_device_t tclass=chr_file > > referring to /dev/usb/lp0. > > Does hald need read/write access to the printer_device? Does hald need it right now? Probably, but I'm not sure. Will it need such access in the future to perform the tasks that it is designed for? Definitely! There is a lot of variation among printer hardware and hald is the correct program to inform you of what type of printer you have just connected. I've attached a patch to add the access. -- 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: 515 bytes Desc: not available URL: From selinux at gmail.com Sat Sep 25 19:54:13 2004 From: selinux at gmail.com (Tom London) Date: Sat, 25 Sep 2004 12:54:13 -0700 Subject: hald - r/w access to /dev/usb/lp0? In-Reply-To: <200409260534.51592.russell@coker.com.au> References: <4c4ba153040925112714a5f9ac@mail.gmail.com> <200409260534.51592.russell@coker.com.au> Message-ID: <4c4ba15304092512542d749951@mail.gmail.com> Understand and agree about read access, but the AVC shows it wanting write access as well. Your patch allows read/getattr/ioctl. but not write. I can certainly imagine a dialog protocol that would require both read and write, but I'm not certain if this is in fact used here. What do you think? tom On Sun, 26 Sep 2004 05:34:51 +1000, Russell Coker wrote: > On Sun, 26 Sep 2004 04:27, Tom London wrote: > > When haldaemon starts, and typically just after the text 'login:' > > appears but before the graphical stuff takes over, I get: > > > > Sep 25 10:28:57 fedora kernel: audit(1096133337.944:0): avc: denied > > { read write } for pid=3187 exe=/usr/sbin/hald name=lp0 dev=tmpfs > > ino=5073 scontext=system_u:system_r:hald_t > > tcontext=system_u:object_r:printer_device_t tclass=chr_file > > > > referring to /dev/usb/lp0. > > > > Does hald need read/write access to the printer_device? > > Does hald need it right now? Probably, but I'm not sure. > > Will it need such access in the future to perform the tasks that it is > designed for? Definitely! There is a lot of variation among printer > hardware and hald is the correct program to inform you of what type of > printer you have just connected. I've attached a patch to add the access. > > -- > 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 > > > > -- Tom London From russell at coker.com.au Sat Sep 25 21:03:22 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 07:03:22 +1000 Subject: hald - r/w access to /dev/usb/lp0? In-Reply-To: <4c4ba15304092512542d749951@mail.gmail.com> References: <4c4ba153040925112714a5f9ac@mail.gmail.com> <200409260534.51592.russell@coker.com.au> <4c4ba15304092512542d749951@mail.gmail.com> Message-ID: <200409260703.22135.russell@coker.com.au> On Sun, 26 Sep 2004 05:54, Tom London wrote: > Understand and agree about read access, but the AVC > shows it wanting write access as well. > > Your patch allows read/getattr/ioctl. but not write. I can certainly > imagine a dialog protocol that would require both read and write, > but I'm not certain if this is in fact used here. > > What do you think? I think we should allow write as well, I've attached a new patch. If it wanted write access to fixed_disk_device_t or something then we would have to look into it seriously. But write to a printer doesn't seem so important and it's something that is needed for some status queries. If hald ever goes as far as querying the paper size then it'll definitely need such access. -- 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: 506 bytes Desc: not available URL: From selinux at gmail.com Sun Sep 26 02:01:25 2004 From: selinux at gmail.com (Tom London) Date: Sat, 25 Sep 2004 19:01:25 -0700 Subject: reconnecting USB p rinter Message-ID: <4c4ba1530409251901fa541f6@mail.gmail.com> Running strict/enforcing, w/USB printer. Reconnecting printer (after pulling the plug) yields the following: Sep 25 18:46:47 fedora kernel: audit(1096163207.182:0): avc: denied { search } for pid=7592 exe=/usr/sbin/hal_lpadmin name=cups dev=hda2 ino=4474131 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:cupsd_etc_t tclass=dir Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc: denied { read } for pid=7593 exe=/usr/bin/python name=printconf_tui.py dev=hda2 ino=4309021 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printconf_t tclass=file Sep 25 18:46:48 fedora kernel: audit(1096163208.050:0): avc: denied { getattr } for pid=7593 exe=/usr/bin/python path=/usr/share/printconf/util/printconf_tui.py dev=hda2 ino=4309021 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:printconf_t tclass=file Sep 25 18:46:49 fedora kernel: audit(1096163209.538:0): avc: denied { read } for pid=7595 exe=/usr/bin/perl name=urandom dev=tmpfs ino=965 scontext=system_u:system_r:hald_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Attached patch to cups.te adds allow rules for these. Please correct/edit/etc. tom -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: diff-cups Type: application/octet-stream Size: 368 bytes Desc: not available URL: From russell at coker.com.au Sun Sep 26 11:47:53 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 21:47:53 +1000 Subject: fsck.ext3 on bootup In-Reply-To: <4c4ba15304092421194618e27f@mail.gmail.com> References: <4149DA4C.6030409@comcast.net> <200409250220.15285.russell@coker.com.au> <4c4ba15304092421194618e27f@mail.gmail.com> Message-ID: <200409262147.53832.russell@coker.com.au> On Sat, 25 Sep 2004 14:19, Tom London wrote: > OK. I made a new initrd using mkinitrd-4.1.12-1, rebooted, but the > result is the same. > > Sorry.... Anything else I can try? It seems that a device node /dev/root is created when you boot from a non-LVM device. This is probably a bug in the boot scripts which may tie in with the following bugzilla (about root= parameter being ignored in the case of LVM systems). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133236 Anyway I have attached a policy patch that will work around the SE Linux aspects of this issue. -- 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: 588 bytes Desc: not available URL: From russell at coker.com.au Sun Sep 26 13:14:37 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 26 Sep 2004 23:14:37 +1000 Subject: reconnecting USB p rinter In-Reply-To: <4c4ba1530409251901fa541f6@mail.gmail.com> References: <4c4ba1530409251901fa541f6@mail.gmail.com> Message-ID: <200409262314.37967.russell@coker.com.au> On Sun, 26 Sep 2004 12:01, Tom London wrote: > Running strict/enforcing, w/USB printer. > > Reconnecting printer (after pulling the plug) yields the following: allow hald_t urandom_device_t:chr_file { read }; The above line should go unconditionally in hald.te not in cups.te. The reason is that hald might access urandom_device_t for many things other than printer configuration, and we don't want the other things to suddenly stop working if we remove the cups policy. Also for neat policy I think it's best not to put {} around a single item. I've attached a diff between the policy in my tree for hal and cups and that of the CVS. Please note that removing the dontaudit from cups.te is deliberate, there is a matching allow rule later in the same file. -- 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: 1626 bytes Desc: not available URL: From aquynh at gmail.com Sun Sep 26 15:25:22 2004 From: aquynh at gmail.com (aq) Date: Mon, 27 Sep 2004 00:25:22 +0900 Subject: checkinstall on Fc3T2 Message-ID: <9cde8bff0409260825130739c4@mail.gmail.com> hello, I am compiling openbox-3.2 from source code (yes, FC3T2 is test edition, so nobody makes packages for it). I run "./configure", then "make". But when I run checkinstall to make a rpm package of openbox, I got various errors (for ex, "Segmentation fault mkdir data 2 & > /dev/null). I guess the problem is that the "checkinstall" has insufficient privilege. What should I do to fix this problem? thank you a lot, AQ From selinux at gmail.com Sun Sep 26 18:28:44 2004 From: selinux at gmail.com (Tom London) Date: Sun, 26 Sep 2004 11:28:44 -0700 Subject: reconnecting USB p rinter In-Reply-To: <200409262314.37967.russell@coker.com.au> References: <4c4ba1530409251901fa541f6@mail.gmail.com> <200409262314.37967.russell@coker.com.au> Message-ID: <4c4ba153040926112828a7c55@mail.gmail.com> Applied, and fixes above mentioned issues. However, there is another problem here. The second time I disconnect the printer, I get a horde of AVCs, all from hald_t apparently attempting to access 'everything', from apmd_t through xfs_t (with the kitchen sink in between).... 'ps agxZ' yields: root:sysadm_r:sysadm_t 4686 pts/2 S 0:00 -bash system_u:system_r:hald_t 5443 ? Ss 0:00 cupsd root:sysadm_r:sysadm_t 5571 pts/2 R+ 0:00 ps agxZ That's not right, is it? Shouldn't cupsd be running in cupsd_t? It looks like when hald restarts cupsd after the 'first reconnection', its not transitioning it to cupsd_t. The following patch adds a domain_auto_trans(hald_t, cupsd_exec_t, cupsd_t) to cups.te This makes the 'new' cupsd run in cupsd_t. This doesn't fix everything, as there are still about 170 AVCs. Do we need to add a bunch of 'domain_auto_trans' rules for hald_t (for apmd_t, crond_t, ......)? dontaudits? I attach the AVCs from a 'disconnect/reconnect' cycle running a policy with the hald_t->cupsd_t auto_trans rule. Help appreciated! tom On Sun, 26 Sep 2004 23:14:37 +1000, Russell Coker wrote: > On Sun, 26 Sep 2004 12:01, Tom London wrote: > > Running strict/enforcing, w/USB printer. > > > > Reconnecting printer (after pulling the plug) yields the following: > > allow hald_t urandom_device_t:chr_file { read }; > > The above line should go unconditionally in hald.te not in cups.te. The > reason is that hald might access urandom_device_t for many things other than > printer configuration, and we don't want the other things to suddenly stop > working if we remove the cups policy. > > Also for neat policy I think it's best not to put {} around a single item. > > I've attached a diff between the policy in my tree for hal and cups and that > of the CVS. Please note that removing the dontaudit from cups.te is > deliberate, there is a matching allow rule later in the same file. > > -- > 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 > > > > -- Tom London -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usb-avcs Type: application/octet-stream Size: 41297 bytes Desc: not available URL: From russell at coker.com.au Sun Sep 26 21:27:44 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 27 Sep 2004 07:27:44 +1000 Subject: reconnecting USB p rinter In-Reply-To: <4c4ba153040926112828a7c55@mail.gmail.com> References: <4c4ba1530409251901fa541f6@mail.gmail.com> <200409262314.37967.russell@coker.com.au> <4c4ba153040926112828a7c55@mail.gmail.com> Message-ID: <200409270727.44674.russell@coker.com.au> On Mon, 27 Sep 2004 04:28, Tom London wrote: > That's not right, is it? Shouldn't cupsd be running in cupsd_t? Correct. > The following patch adds a > domain_auto_trans(hald_t, cupsd_exec_t, cupsd_t) > to cups.te Good work, I've put that in my tree. Also we should remove the can_exec_any() from hald.te ASAP, it's a time bomb allowing large numbers of undesired programs to run in hald_t. > This makes the 'new' cupsd run in cupsd_t. > This doesn't fix everything, as there are still about 170 AVCs. > > Do we need to add a bunch of 'domain_auto_trans' rules for > hald_t (for apmd_t, crond_t, ......)? dontaudits? I'll look into that later. -- 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 dwalsh at redhat.com Mon Sep 27 15:00:49 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 27 Sep 2004 11:00:49 -0400 Subject: /lib/tls/i[456]86/libdb-4.2.so - patch to types.fc In-Reply-To: <4c4ba15304092422385e87a316@mail.gmail.com> References: <4c4ba15304092422385e87a316@mail.gmail.com> Message-ID: <41582B21.5000703@redhat.com> Tom London wrote: >Running 'setfiles -vv $FC /lib' produces: > >setfiles: labeling files under /lib >setfiles: relabeling /lib/tls/i586/libdb-4.2.so from >system_u:object_r:shlib_t to system_u:object_r:lib_t >setfiles: conflicting specifications for /lib/tls/i486/libdb-4.2.so >and /lib/tls/i586/libdb-4.2.so, using system_u:object_r:shlib_t. >setfiles: relabeling /lib/tls/i486/libdb-4.2.so from >system_u:object_r:lib_t to system_u:object_r:shlib_t > >Suggest this patch: > >--- types.fc 2004-09-23 11:02:38.000000000 -0700 >+++ /tmp/types.fc 2004-09-24 22:35:40.913346939 -0700 >@@ -302,7 +302,7 @@ > /lib(64)?/[^/]*/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t > /lib(64)?/security/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t > /lib(64)?/tls/i686/cmov/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t >-/lib(64)?/tls/i486/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t >+/lib(64)?/tls/i[456]86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t > > # > # /sbin > >tom > > /lib(64)?/tls/i.86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t is already in the latest policy. From nalin at redhat.com Mon Sep 27 16:39:54 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 27 Sep 2004 12:39:54 -0400 Subject: /lib/tls/i[456]86/libdb-4.2.so - patch to types.fc In-Reply-To: <41582B21.5000703@redhat.com> References: <4c4ba15304092422385e87a316@mail.gmail.com> <41582B21.5000703@redhat.com> Message-ID: <20040927163954.GA4801@redhat.com> On Mon, Sep 27, 2004 at 11:00:49AM -0400, Daniel J Walsh wrote: > /lib(64)?/tls/i.86/[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t > > is already in the latest policy. I think that we're inevitably going to need a similar addition for /usr/lib. There's also a reference to /lib/tls/i686/cmov in the policy, which brings up a question. The hwcap logic in the dynamic linker includes the ability to distinguish between many other specialized variations of libraries. So, how exhaustive is the policy intended to be? Nalin From don.patterson at tresys.com Mon Sep 27 19:21:26 2004 From: don.patterson at tresys.com (Don Patterson) Date: Mon, 27 Sep 2004 15:21:26 -0400 Subject: setools-1.4.1 patch Message-ID: <20040927192132.XKML14769.mm-ismta4.bizmailsrvcs.net@ICEMAN> A new bug report (with a patch attached) has been entered into Fedora bugzilla (http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133811) which addresses a few bugs in the setools-1.4.1 package that have been brought to our attention. Also, an updated setools-1.4.1 tarball is available from our website at http://www.tresys.com/selinux/selinux_policy_tools.html. Thanks. Don Patterson Tresys Technology http://www.tresys.com From smooge at gmail.com Tue Sep 28 19:05:12 2004 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 28 Sep 2004 13:05:12 -0600 Subject: /var/tmp/badcontext Message-ID: <80d7e409040928120549a367d8@mail.gmail.com> What should users do with the files listed in /var/tmp/badcontext? For the last 3 days I have had over 10000 files listed since I installed it. I was wondering if I should be running some command after a yum upgrade that I didnt know about ;). 17287 /var/tmp/badcontext.HNjBUG2517 52272 /var/tmp/badcontext.XzqEZB4859 22518 /var/tmp/badcontext.YGZFP27816 -- Stephen J Smoogen. Professional System Administrator From dwalsh at redhat.com Tue Sep 28 20:07:22 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 28 Sep 2004 16:07:22 -0400 Subject: /var/tmp/badcontext In-Reply-To: <80d7e409040928120549a367d8@mail.gmail.com> References: <80d7e409040928120549a367d8@mail.gmail.com> Message-ID: <4159C47A.8010703@redhat.com> Stephen J. Smoogen wrote: >What should users do with the files listed in /var/tmp/badcontext? > >For the last 3 days I have had over 10000 files listed since I >installed it. I was wondering if I should be running some command >after a yum upgrade that I didnt know about ;). > > 17287 /var/tmp/badcontext.HNjBUG2517 > 52272 /var/tmp/badcontext.XzqEZB4859 > 22518 /var/tmp/badcontext.YGZFP27816 > > > > restorecon -f /var/tmp/badcontext.YGZFP27816 Will fix the context, then delete the files. We are investigating how do handle this better. Also some of the bad contexts are not really bad, IE the tools not smart enough to realize that the context is valid. Setfiles is just reporting files that don't match the regular expessions in the file_contexts file. So cache files created by mozilla get marked as bad even though they are valid. From smooge at gmail.com Tue Sep 28 20:13:52 2004 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 28 Sep 2004 14:13:52 -0600 Subject: /var/tmp/badcontext In-Reply-To: <4159C47A.8010703@redhat.com> References: <80d7e409040928120549a367d8@mail.gmail.com> <4159C47A.8010703@redhat.com> Message-ID: <80d7e40904092813135dafe4be@mail.gmail.com> On Tue, 28 Sep 2004 16:07:22 -0400, Daniel J Walsh wrote: > Stephen J. Smoogen wrote: > > >What should users do with the files listed in /var/tmp/badcontext? > > > >For the last 3 days I have had over 10000 files listed since I > >installed it. I was wondering if I should be running some command > >after a yum upgrade that I didnt know about ;). > > > > 17287 /var/tmp/badcontext.HNjBUG2517 > > 52272 /var/tmp/badcontext.XzqEZB4859 > > 22518 /var/tmp/badcontext.YGZFP27816 > > > restorecon -f /var/tmp/badcontext.YGZFP27816 > > Will fix the context, then delete the files. We are investigating how > do handle this better. Also > some of the bad contexts are not really bad, IE the tools not smart > enough to realize that the context is > valid. Setfiles is just reporting files that don't match the regular > expessions in the file_contexts file. > > So cache files created by mozilla get marked as bad even though they are > valid. When you say delete.. do you mean it whacks the file on the disk or some other copy... Looking at the files.. my entire home directory is considered to be in an invalid context. I am not sure I want those files deleted.. And I am not sure /usr/lib/libstdc++.so.2.9 /usr/lib/libstdc++-libc6.1-1.so.2 /usr/lib/libstdc++.so.2.7.2 /usr/lib/libsmbclient.so.0 /usr/lib/sendmail /usr/lib/libboost_signals.so.1 /usr/lib/libboost_unit_test_framework.so.1 /usr/lib/locale/locale-archive /usr/lib/libboost_thread.so.1 /usr/lib/libkrbafs.so.0 /usr/lib/libboost_filesystem.so.1 would be good to kill.. I wouldnt mind losing all of /etc/gconf :). Is there anything else that can be done? -- Stephen J Smoogen. Professional System Administrator From nalin at redhat.com Tue Sep 28 20:26:00 2004 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 28 Sep 2004 16:26:00 -0400 Subject: /var/tmp/badcontext In-Reply-To: <80d7e40904092813135dafe4be@mail.gmail.com> References: <80d7e409040928120549a367d8@mail.gmail.com> <4159C47A.8010703@redhat.com> <80d7e40904092813135dafe4be@mail.gmail.com> Message-ID: <20040928202600.GD15529@redhat.com> On Tue, Sep 28, 2004 at 02:13:52PM -0600, Stephen J. Smoogen wrote: > On Tue, 28 Sep 2004 16:07:22 -0400, Daniel J Walsh wrote: > > Stephen J. Smoogen wrote: > > > > >What should users do with the files listed in /var/tmp/badcontext? > > > > > >For the last 3 days I have had over 10000 files listed since I > > >installed it. I was wondering if I should be running some command > > >after a yum upgrade that I didnt know about ;). > > > > > > 17287 /var/tmp/badcontext.HNjBUG2517 > > > 52272 /var/tmp/badcontext.XzqEZB4859 > > > 22518 /var/tmp/badcontext.YGZFP27816 > > > > > restorecon -f /var/tmp/badcontext.YGZFP27816 > > > > Will fix the context, then delete the files. [snip] > > When you say delete.. do you mean it whacks the file on the disk or > some other copy... Yikes! No, running restorecon will reset the file contexts, after which you can/should delete the /var/tmp/badcontext.blahfoo file. Nalin From deff at zoznam.sk Wed Sep 29 16:20:12 2004 From: deff at zoznam.sk (deff) Date: Wed, 29 Sep 2004 18:20:12 +0200 Subject: FC2 Selinux boot failure Message-ID: <200409291820.12275.deff@zoznam.sk> My fedora core 2 selinux ceased to function. dmesg: Security Scaffold v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode There is already a security framework initialized, register_security failed. selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary sestatus -v: SELinux status: disabled What's wrong? Can't manage to boot it at least to permissive. Only thing I've messed recently was nss authentification via ldap. deff From smooge at gmail.com Wed Sep 29 17:47:29 2004 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 29 Sep 2004 11:47:29 -0600 Subject: Conflicting types message Message-ID: <80d7e409040929104739d1b584@mail.gmail.com> /etc/cron.daily/fixfiles.cron: logging to /dev/null /usr/sbin/setfiles: conflicting specifications for /lib/tls/i486/libdb-4.2.so and /lib/tls/i586/libdb-4.2.so, using system_u:object_r:shlib_t. Null message body; hope that's ok I got this morning from the badcontexts file. Do not know enough about SElinux to figure out what is causing this... -- Stephen J Smoogen. Professional System Administrator From russell at coker.com.au Wed Sep 29 17:51:31 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 30 Sep 2004 03:51:31 +1000 Subject: FC2 Selinux boot failure In-Reply-To: <200409291820.12275.deff@zoznam.sk> References: <200409291820.12275.deff@zoznam.sk> Message-ID: <200409300351.31189.russell@coker.com.au> On Thu, 30 Sep 2004 02:20, deff wrote: > My fedora core 2 selinux ceased to function. Did you upgrade the kernel? -- 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 dwalsh at redhat.com Wed Sep 29 18:47:18 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Sep 2004 14:47:18 -0400 Subject: FC2 Selinux boot failure In-Reply-To: <200409300351.31189.russell@coker.com.au> References: <200409291820.12275.deff@zoznam.sk> <200409300351.31189.russell@coker.com.au> Message-ID: <415B0336.508@redhat.com> Russell Coker wrote: >On Thu, 30 Sep 2004 02:20, deff wrote: > > >>My fedora core 2 selinux ceased to function. >> >> > >Did you upgrade the kernel? > > > Todays kernel lost the tmpfs change again. From russell at coker.com.au Wed Sep 29 19:12:44 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 30 Sep 2004 05:12:44 +1000 Subject: ReiserFS Message-ID: <200409300512.44632.russell@coker.com.au> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134111 We are having some discussions of ReiserFS in the Red Hat bugzilla. fs_use_xattr reiserfs system_u:object_r:fs_t; It seems to me that the easiest solution is to remove the above line from fs_use and add the following to genfs_contexts: genfscon reiserfs / system_u:object_r:nfs_t The reason for this hack is that we already have the policy for home directories on NFS. ReiserFS will never work for a root FS and isn't worth any more effort than this hack. Another suggestion was to entirely remove ReiserFS support from Fedora (IE no reiserfs.ko file in the kernel package). -- 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 Wed Sep 29 19:17:35 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 30 Sep 2004 05:17:35 +1000 Subject: ReiserFS In-Reply-To: <200409300512.44632.russell@coker.com.au> References: <200409300512.44632.russell@coker.com.au> Message-ID: <200409300517.35322.russell@coker.com.au> On Thu, 30 Sep 2004 05:12, Russell Coker wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134111 > > We are having some discussions of ReiserFS in the Red Hat bugzilla. > > fs_use_xattr reiserfs system_u:object_r:fs_t; > > It seems to me that the easiest solution is to remove the above line from > fs_use and add the following to genfs_contexts: > > genfscon reiserfs / system_u:object_r:nfs_t allow mount_t unlabeled_t:dir search; I almost forgot to mention that mount_t needs search access to a directory of type unlabeled_t for the above hack to work. Not sure why, but it's fairly harmless. -- 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 deff at zoznam.sk Wed Sep 29 20:08:32 2004 From: deff at zoznam.sk (deff) Date: Wed, 29 Sep 2004 22:08:32 +0200 Subject: FC2 Selinux boot failure In-Reply-To: <415B0336.508@redhat.com> References: <200409291820.12275.deff@zoznam.sk> <200409300351.31189.russell@coker.com.au> <415B0336.508@redhat.com> Message-ID: <200409292208.32775.deff@zoznam.sk> On Wednesday 29 September 2004 20:47, Daniel J Walsh wrote: > Russell Coker wrote: > >On Thu, 30 Sep 2004 02:20, deff wrote: > >>My fedora core 2 selinux ceased to function. > > > >Did you upgrade the kernel? > > Todays kernel lost the tmpfs change again. I'm using official 2.6.8-521smp kernel. Is there any way I can find out what's wrong? From dwalsh at redhat.com Wed Sep 29 20:42:48 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Sep 2004 16:42:48 -0400 Subject: FC2 Selinux boot failure In-Reply-To: <200409292208.32775.deff@zoznam.sk> References: <200409291820.12275.deff@zoznam.sk> <200409300351.31189.russell@coker.com.au> <415B0336.508@redhat.com> <200409292208.32775.deff@zoznam.sk> Message-ID: <415B1E48.1060804@redhat.com> deff wrote: >On Wednesday 29 September 2004 20:47, Daniel J Walsh wrote: > > >>Russell Coker wrote: >> >> >>>On Thu, 30 Sep 2004 02:20, deff wrote: >>> >>> >>>>My fedora core 2 selinux ceased to function. >>>> >>>> >>>Did you upgrade the kernel? >>> >>> >>Todays kernel lost the tmpfs change again. >> >> > >I'm using official 2.6.8-521smp kernel. Is there any way I can find out what's >wrong? > > > Sorry I answered the wrong question. Today's rawhide kernel is broken. Not sure what your problem is. Dan >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > >