Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: SELinux Integrated Logging Tool Date: Fri, 17 Jun 2005 15:01:21 -0500
This project was developed by Nicholas Davis and it is titled "Improving the Logging Facility in Security Enhanced Linux." The abstract for this paper and a link to a PDF version of it appear below. Please post any feedback or questions you may have. Thank you Abstract
Security-Enhanced Linux offers a robust Mandatory Access Control
protection scheme
Link http://personal.utulsa.edu/~brandon-pollet/SILT-Davis.pdf -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: James Morris <jmorris_at_redhat.com> subject: Re: SELinux Integrated Logging Tool Date: Fri, 17 Jun 2005 19:43:16 -0400 (EDT)
> This project was developed by Nicholas Davis and it is titled This looks potentially useful for general syslogd management, but I'm not sure how it's SELinux specific. Also, SELinux now makes more use of the audit subsystem and auditd is the preferred mechanism for SELinux logging.
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Steve G <linux_4ever_at_yahoo.com> subject: Re: SELinux Integrated Logging Tool Date: Sat, 18 Jun 2005 08:39:49 -0700 (PDT)
>This project was developed by Nicholas Davis and it is titled I read through it. I don't see what it has to do with SE Linux at all. It looks like a general purpose syslog configurator. This is something that *is* needed and people may like to use the tool for that purpose. It really does look interesting, but for reasons other than SE Linux. As James said, auditd is the way forward. It uses a more reliable communication interface and is designed specifically to fill the audit niche. I have a "gui" config tool that is based on dialog. I will probably put it on the web, but I am reluctant to include it with the audit package at this point. If I find time, I will probably extend it to include building auditctl rules. There is a recent tool in the audit package, ausearch, that lets you search for any event based on many criteria. At this point, the intention is to meet CAPP needs, but future work is going to allow searching based on labels. There is also a feature that many people don't know about and that is the ability to interpret the logs so that its easier to understand. A sample use would be: ausearch -i -m AVC. I will be at OLS next month for the audit BoF. I would like to share with attendees some of the possibilities for future development. This includes event notification and an audit log explorer (not to be confused with a viewer). -Steve Grubb Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: dumb newbie questions Date: Sat, 18 Jun 2005 18:38:51 -0500
I moved all the files for an existing Apache website to the new server including a variety of Perl programs and Perl CGI scripts, all of which have been working fine for a year on a Red Hat 9 box. Some of these scripts worked fine on the new box but others failed to run at all. After spending hours trying to debug the problem, I wrote a simple one line Perl program like so:
#!/usr/bin/perl
I would think a script this simple shouldn't fail to run in any normal, functional environment but - it failed to run. This was all the more baffling because some of the scripts that do run do little more than print a few lines to stdout. After another hour or so of poking around it finally occured to me to check the message log (should've done that first!) and I discovered the source of the problem. Lots of cryptic entries like this: kernel: audit(1119056704.257:0): avc: denied { read write } for pid=3020 comm=test.pl path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:devpts_t tclass=chr_file I tried everything I could think of. Regardless of permissions, owners, or what user I run them as (even root!) the scripts continued to not run. I found and read several FAQs on selinux but most of them seem to be written with the assumption that I already know a bunch of selinux terminology - roles, contexts, type enforcement, domain transitions, etc. As best I can tell so far, each time I add a new program to the server I'm going to have to do something to selinux to allow the new program to run (except that maybe sometimes I don't because some of the scripts I moved over work fine?). Is there any chance someone can answer two dumb questions without using a lot of selinux jargon (or point me to a document that can do this):
audit2allow test.txt The result message from audit2allow was "allow httpd_sys_script_t devpt_t:chr_file { read write };". The "allow" sounded hopeful but when I tried to run my script again it still didn't work. So I think there must be some additional step that was left out of the FAQ. Any suggestions appreciated.
-Steve
-- subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 02:45:58 -0400
> 2. How do I get a new scripts or program to run? One FAQ came near to I wish FAQs would stop recommending this, since that's what everyone does to get their scripts to run. audit2allow is a helper program for policy writers, and nothing more. It's a mistake to pipe its output into anything... instead you should provide that to the SELinux people, so they can write proper policy.
> The result message from audit2allow was "allow httpd_sys_script_t This particular error means that your script cannot write to the terminal. I also suspect the terminal is labeled incorrectly, but someone else would have to comment on that - I am still not understanding the different devpts* types very well. Why do you need your scripts to write to the terminal? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 09:40:15 -0700 (PDT)
> I wish FAQs would stop recommending this, since If only the "SELinux people" can write "proper" policy SELinux has no place in the linux mainline. I suggest that the "SELinux People" would do well to provide documentation that is sufficient for the developer in question to create a "proper" policy rather than asserting that it's only something that they can do. The attitute presented is akin to saying that no one but RedHat should create Makefiles because, after all, they are the "Distribution People".
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 15:51:58 -0400
You're misrepresenting the point of my response...
Who writes the policy is not important.
What I think is a problem is when people use the output of audit2allow as the policy... which is what I see happening. To me that largely defeats the purpose of SELinux... -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 13:14:52 -0700 (PDT)
> You're misrepresenting the point of my response... Well, maybe a little.
> Who writes the policy is not important. I think it is. The developer, who understands the intent of the application and it behavior, ought to be in charge of the SELinux policy.
> Well - it is important, but that's not what I was Yes, it's important. And an issue.
> I am all for improvements in the way SELinux I am a strong advocate of the above.
> What I think is a problem is when people use the
A developer will use the best tools available.
Since audit2allow appears to be the best tool
available for the development of policy that is
what will be used. It appears to be the best
tool available because the FAQs you are
> To me that largely defeats the purpose of SELinux... You are correct in that bad policies are bad for SELinux. I believe that having policies created by someone other than the developer of the application, except as a first-pass effort to help the developer along, is a virtual guarantee that the SELinux will join the ranks of those systems used to prove that it is impossible to produce a useable secure OS.
Casey Schaufler
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 16:57:17 -0400
> I think it is. The developer, who understands On the other hand you might argue that the developer of the application is biased toward the application.. and likely to allow things that shouldn't be allowed. Anyway, I think Steven (Smalley) has mentioned that more efforts to decentralize policy will occur after Tresys' binary modules work is merged. Re: audit2allow - I have no problem with the tool, as long as people realize it's a tool instead of an automated policy writer. There's two problems with using it to make policy - 1) it will allow everything, and 2) it will not organize everything into understandable modules. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 14:31:51 -0700 (PDT)
> Yes, the developer will do that. It's the old useability VS security argument all over. I doubt that you're arguing for removing the chmod() syscall, although that's a logical step from your position. SELinux provides a mechanism by which the system can constrain an application. Great. What I don't condone is the uneducated application of this mechanism to applications on a production system. I agree that the rote use of audit2allow is a bad idea. I also take the position that the developer and/or maintainer of an application is the person responsible for the behavior of the application, and that includes the behavior under SELinux.
If you can't get developers to buy into
I hope that when I bring the project I
> Anyway, I think Steven (Smalley) has mentioned that
Yes, he has. I hope that effort is successful.
I strongly dislike the direction of RedHat
shipping a binary only policy, and one that
so few people understand, and that the
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 23:10:36 +0100
> Yes, he has. I hope that effort is successful. as the bun-fight over crond demonstrated (at least to me), the maintainers _can_ listen - if you have enough time, patience and flexibility. for those people who missed it, crond (not the vixie cron, the other one) did not properly support selinux, and needed it. a long _long_ time was spent explaining to the maintainer of crond that yes, selinux really _does_ have a concept of "system". the poor guy had added the concept of "*system*" to cater for the fact that unix-on-its-own doesn't have a clue about "system" privileges, and he had added some extra field into his internal data structures in order to be able to distinguish between "system" level cron jobs [run as root] and those that were explicitly to be run under the username of "root". after about 10-15 email exchanges, he eventually explained things clearly enough for it to get through our thick heads, and _then_ we had enough of an understanding of what he had created, in order to be able to successfully convince him that yes, selinux's "system_u" needs to ride "on the back of" his pseudo-created "*system*" concept. from there i kind of lost the plot a bit (i overdid it a bit :) and he and dan managed to finish it off and write an acceptable patch. i put it to you, therefore, casey, that it is _your_ job - and mine - to explain selinux clearly enough, to be patient enough, to listen enough. the one about openssh (the file handle one where an exec() had happened and the file handle hadn't been closed) was _way_ over my head, but heck - there were people here who understood it. one step at a time. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 17:28:26 -0700 (PDT)
> i put it to you, therefore, casey, that it
I do not know enough about SELinux to explain it.
I do not know how to do a policy.
I would like to. But there is no source of information. Oh sure, I've been referred to papers written about Flux back in the previous century. They are not helpful. Finally, I do not see how a scheme under which the policy is generated after the fact by people other than the developers can possibly make sense. But, that's just me.
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 23:13:57 +0100
no, no, and definitely no. i made the mistake, 8 months ago, of making that recommendation. russell kindly put me right about it: you could likely, with enough searching, find his response. the person doing the application is EXTREMELY unlikely to have the expertise and knowledge sufficient to get selinux and to get selinux policy right. heck - it took me (and i pride myself on being a knowledge sponge) TWO MONTHS to go from being an ill-educated pain-in-the-ass to being an over-confident pain-in-the-ass. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 17:16:55 -0700 (PDT)
> > I think it is. The developer, who understands
My point, and I hope that someday I'll
In the MLS Unix world it was difficult to train people who where disinterested in the program even when their jobs depended on it. Once people became engaged with MLS, and that required lots of D O C U M E N T A T I O N, they learned how they could take advantage of it. Then they learned to quit worrying and love the bomb.
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 20:21:24 +0100
i _would_ agree with you... if it wasn't for this:
and that this is true _irrespective_ of whether selinux exists or not. yes? i think this can be said (i invite people to disagree). based on the above three statements (*) being true, it can be concluded that when you introduce selinux, the expectation for ordinary applications developers to "get it right" simply becomes an absolute nonsense. the mere _introduction_ of security-aware selinux developers and the use of a formally structured policy makes it possible to draw application developers' attention to security deficiencies in their programs, and they can then be invited to fix them. a [possibly too] simple example is that of the debian initscripts, one of which attempted to do a touch on /etc in order to detect whether /etc/mtab could potentially be written to [instead of doing touch on /etc/mtab itself!] because selinux "strict" policy quite rightly bans all but appropriate programs to have write permission to /etc (and this particular initscript most certainly ain't one of those programs!), the entire behaviour of the debian initscripts (in this case, mounting and managing the initial filesystem partitions!) went off down a different path, causing some quite serious recovery problems. the solution was NOT to "fix selinux" but instead the solution was to fix the initscript. ... but would that have been detected if it wasn't for the strictness of selinux being Mandatory Access Control, such that an avc message comes up? of course it wouldn't have been. there are plenty other (better) examples. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 13:41:06 -0700 (PDT)
> i _would_ agree with you... if it wasn't for this: Careful there, son. You're talking to someone who's spent the past 15 years in the forefront of the effort to address this issue. It has been 10 years since this statement was true.
> * that application developers are notoriously This is true. More to the point, developers of applications that manipulate or enforce policy, or that should and don't often are ignorant of the facilities available to them.
> * that languages like c and c++ and processors like
Careful there, it's a poor workman who
> and that this is true _irrespective_ of whether I've agreed some, and disagreed some, but in either case, the presence of SELinux makes very little difference.
> yes? Let's go with 65% yes
> i think this can be said (i invite people to One of two things has to be true. Either: 1. Developers need to be able to get it right
> the mere _introduction_ of security-aware selinux Should the application development community accept SELinix policy as the standard of good taste you will have an argument of merit. As you point out, understanding is the key. If developers understand SELinux policy well enough to accept the judgements proclaimed by the application of said policy I would suggest that they are perfectly qualified to write it themselves.
> a [possibly too] simple example is that of the
This is an example of a programming flaw.
Most security problems we see today are
> because selinux "strict" policy quite rightly bans Which was true, SELinux or no.
> ... but would that have been detected if it wasn't Well, this is the open source world. Many eyes.
> of course it wouldn't have been. Horsefeathers.
> there are plenty other (better) examples. Of course there are. And there are a whole bunch SELinux isn't going to find, too. And once SELinux is used to find all the problems, and they get fixed, we can turn SELinux off because it's unnecessary. Right?
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Valdis.Kletnieks_at_vt.edu subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 17:01:38 -0400
> bunch SELinux isn't going to find, too. And This presupposes two very unlikely events:
Other than that, yes, you could turn it off once your system is 100% secured and infallible.
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Casey Schaufler <casey_at_schaufler-ca.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 14:36:28 -0700 (PDT)
> This presupposes two very unlikely events:
Nope, just that all the problems that the
"policy" would find are found. Since the
policy will not find things it does not
> 2) That no further software upgrades happen, Or changes that are made to get around the SELinux policy that has arbitrarily been imposed on an application.
> Other than that, yes, you could turn it off once You could turn it off well before then and still gain complete benefit. Let's face it, SELinux, even with the strict policy, is not going to identify all flaws any more than a Biba integrity policy would.
Casey Schaufler
Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Christopher Warner <chris_at_servertogo.com> subject: Re: dumb newbie questions Date: Wed, 22 Jun 2005 05:48:25 -0400
It seemed to me that I could not write a proper policy for the program in question without knowing how the program was designed and worked. Needless to say that me seeing the "source" is an issue and avenue that can't be explored. This led me to, subsequently, reverting to stracing the program. Which led to me finding that basically, the program in question does many things incorrectly or at least what one would deem as being grossly incorrect. IE: Using system calls instead of /proc etc etc (etc etc being more irregularity). Even if I wrote a decent policy for the program it would mean allowing it to do things it should not do. Breaking policy across the board for everything else all together. The last statement made was "Then I don't understand why we are using Selinux". We eventually agreed that I would need the design spec of the program and that I would write policy based off of that. I've not received the design spec yet and I've spent the last 6 months learning and working with Selinux, whilst fulfilling my day duties. Implementing it into the in-house distribution and then trying to write policy. I'm at a lost currently as to why I would even attempt at writing the policy for this program. It disheartens me as I feel the last 6 months were completely wasted in terms of anything involving the goal of security. The problem I see here is two fold in my case, First, the assumption that Selinux is a security cure all if it's just implemented or activated (a poor assumption made by the person in charge). This, only education and understanding of the product in question can fix. Secondly, and more importantly is that there is very little in the terms of updated and concise documentation where one can just point others (developers/sysadmins/etc) to. So that they can receive a decent overview and make an educated decision. Security is a philospohy and Selinux enforces this philosophy. Thats what it boils down to. The only useful reference is the O'Reilly book on Selinux. It covers creating policy but it doesn't address how policy interacts or how you'd go about writing a decent policy. This also has to be taken into account. We need more documentation and it should reiterate the fact that Selinux is pointless if proper policy is not or can not be written.
On Mon, 2005-06-20 at 14:36 -0700, Casey Schaufler wrote:
-- .-Christopher Warner---------------------------------------------. | my email is recycled to be sure; bcc my personal email address | `----------------------------------------------------------------' -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <gyurdiev_at_redhat.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 16:41:35 -0400
> > If only the "SELinux people" can write "proper" Steven, to write custom selinux policy you need to download the selinux-policy-*-sources package. After doing that, you can go to domains/misc/local.te, and place your policy there. Then do make load; make install, and hope that it works.
To actually write policy you need to understand the
SELinux policy language. There are several books
on this, but I'm not the best person to ask about
a reference. I am sure others on this list will
be able to help you. Casey has a point that currently
it is difficult for the person who has had no
experience with SELinux to write customized policy.
That's why we try to limit the places where the user
would need such a policy, and provide a GUI to control
the operation of the existing policy
I highly recommend _against_ using the output of audit2allow as the policy, although it will be helpful to you to establish what went wrong. audit2allow is a tool which prints the audit messages from the log, and generates rules that will make them go away. You can then take those rules and place them in the policy sources, and recompile policy. Surely you can see why this is a bad thing, if used carelessly - some things should not necessarily be allowed, and this tool will allow them. It also attempts to create no organization of rules at all. SELinux rules are usually organized through macros that you can use to write better policy source. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 22:34:47 -0500
On Sun, 2005-06-19 at 16:41 -0400, Ivan Gyurdiev wrote:
Ouch. I normally don't have to read several books to get a one line "hello world" perl script to run reliably on a new box. :-(
On Sun, 2005-06-19 at 23:13 +0100, Luke Kenneth Casson Leighton wrote:
Ouch again. I simply don't have two months to get this system up and running. I've never had that many security problems on our servers and we've been running normal Linux for years, so I don't think the extra security of selinux will really be that helpful, especially if I can't easily admin my boxes or install and run new programs when I need to. I'm begining to think the best route would be to completely disable selinux and go back to normal linux mode. What's the best way to do that? I've found two ways of getting rid of selinux:
>From what the FAQs say, I'm guessing #1 is the way to go? It sounds like When I've got a few months of free time available (ha!), I can set up a test box and play around with selinux again. -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Valdis.Kletnieks_at_vt.edu subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 00:45:36 -0400
Oh? You learned C without a book, or Perl, or any of the other languages? :) perl -e 'print "Hello World!\n"' doesn't generate any AVCs on my system when run as a normal user. So that's a straw man. Or are you saying that you let people write more complex Perl CGIs for your system (complex enough that they're running external commands or using Mysql or the other usual suspects for SELinux issues) and these people *don't* have Perl knowledge equivalent to reading several books on it? ;)
> Ouch again. I simply don't have two months to get this system up and It's a matter of trade-offs - if you do a 'chown -R root:root /' and change the root password to "", it's *really* easy to admin the boxes. ;) Also, "We haven't had many security problems in the past" doesn't prove anything. I've heard that from sites that leaked like a sieve security-wise and simply didn't *know* they'd been 0wnz0red for months. Also, just because the defenses you had 3 and 5 years ago stopped most of the hackers 3 and 5 years ago doesn't mean that they're sufficient to stop next year's hackers.... If you have 2 minutes rather than 2 months, kick the system to 'permissive' mode.
> I'm begining to think the best route would be to completely disable Note that in "permissive" mode, each AVC message will only fire the first time it gets hit - which means that most likely, in the first hour or so of uptime you'll accumulate the majority of warnings you'll get. If nothing else, "permissive" mode is better than "disabled" security-wise - even if it doesn't stop an attack, at least you get the audit trail that something odd happened. Also, your system may be the exception, but the vast majority of people who see "7% performance hit" and immediately label it as "intolerable" are people who are running poorly tuned systems that could get back a lot more than 7% with just a little bit of work.
> When I've got a few months of free time available (ha!), I can set up a You probably want to run in permissive mode *before* that, so that when you start playing around, you have the AVC messages in hand to start thinking about. As has been pointed out in other recent postings, 'audit2allow' is a poor substitute for looking at the AVC's your current policy generates and *thinking* about what is needed... And although you'll get *most* of the avc messages fairly quickly, a lot of them will only trip on rare corner-case occasions (for instance, if you have a monthly summary/whatever process, and base your policy on the 3 weeks of the month that said process doesn't run, your policy will likely kill that monthly process....)
-- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 09:45:17 -0500
I quoted the source of my one line perl test script and error message it generated in a previous post. It doesn't run on my system, which is using CentOS 4.1. All my scripts have been working fine on a non-selinux box. I'm not writing any new scripts (other than the one line test script), just trying to move an existing website and associated scripts to an selinux box. Some of the perl scripts run fine, other don't run at all, generating the avc errors. See my previous post for the details. -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <gyurdiev_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 11:14:34 -0400
> I quoted the source of my one line perl test script and error message it ...and I've pointed out that your script doesn't run, because httpd scripts are not allowed to write to the terminal. You can either customize your policy, which requires some understanding of SELinux, or argue that we should allow httpd scripts to write to the terminal in general. This has nothing to do with how simple the script is - security requirements are not proportional to code complexity.
> All my scripts have been working fine on a non-selinux SELinux is not supposed to be transparent. That was my misunderstanding when I first encountered it, and I have accepted this requirement since then. If you are interested in the extra security offered, then you have to put in some extra effort in making your applications run on top of this system. Hopefully as the policy becomes more mature, this will be less of an issue.
> I'm not writing any new scripts (other than the one line test You haven't provided any avc errors other than the /dev/pts/0 one. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 10:29:29 -0500
What I wasn't understanding is why selinux thinks it's an httpd script. It seemed like a pretty generic "hello world" program to me. I'm assuming now, that selinux makes guesses about what sort of program it is by where it's located? My hello world program works in my home directory but not in the httpd perl directory. I still don't entirely understand why this should be but at least I know about it now and can look out for it. What can I say, I chose the subject line for a reason... :-) -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <gyurdiev_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 11:44:08 -0400
No - it doesn't guess anything - it makes this decision based on the SELinux context of the file (which eventually determines the SELinux context of the process). See my other mail. This context is stored in the filesystem extended attributes (xattr).
> What can I say, I chose the subject line for a reason... :-) :) -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 11:40:17 -0500
Okay, this is begining to make a little sense. So looking at my test script again, when it's sitting in my home directory ls -alZ shows this: -rwxrwxr-x rsr:rsr root:object_r:user_home_t test.pl If I run it there it works fine. But when I move it anywhere in the /var/www tree, ls -alZ shows this: -rwxrwxr-x rsr:rsr root:object_r:httpd_sys_content_t test.pl And here it doesn't run (for me or root) but it will run for Apache. So that means that when I copy or move a script, the context automagically changes to correspond to whatever security rules are allowed within that directory? That still sounds to me like "context" means it runs if I put it in one directory but doesn't run if I put it in another. It also seems that with the "user_home_t" context the program can use stdout and run normally but with "httpd_sys_content_t" it can't use stdout and can only be run from Apache. I've discovered the chcon utility, so now I'm wondering if what I need to do is change the context of my script to something that will allow both Apache to run it as a CGI and ALSO allow root or another user to run the script normally with stdout. But how do I find out what context to set it to? Is there a list of available contexts and what permissions they have? -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <gyurdiev_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 12:59:13 -0400
> Okay, this is begining to make a little sense. So looking at my test You need to make the distinction between move (as in mv) and copy (as in cp). The former doesn't change context (just like it doesn't change permissions).
> And here it doesn't run (for me or root) but it will run for Apache.
That might be a bug in policy...
> So Context in SELinux is mostly determined based on location. It uses organization based on the directory structure to label things properly. As Stephen explained, it matches based on regular expressions on the path.
> I've discovered the chcon utility, so now I'm wondering if what I need So, as Eric mentioned, SELinux shouldn't be transitioning to a different context when executing a web script from the user shell. It sounds to me like this isn't what's happening, however. It sounds like unconfined_t simply can't access those files, which I suspect is a bug. Are you sure the denial you got when running your script as root from a shell said: scontext=...httpd.. ? It would help if you could double check that. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Karl MacMillan <kmacmillan_at_tresys.com> subject: RE: dumb newbie questions Date: Mon, 20 Jun 2005 13:35:49 -0400
I'd state this differently - the context is determined based on the intended usage or contents of the file/resource. This is often related to the location but not necessarily. For example, most of the files under the document root for apache are meant to be publicly viewable web pages, but not all (.htaccess for example). Karl --- Karl MacMillan Tresys Technology http://www.tresys.com (410) 290-1411 ext 134From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 14:06:58 -0400
>>Okay, this is begining to make a little sense. So looking at my test -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 13:06:34 -0500
No problem. Here's the whole thing with a little more detail. The perl script "test.pl":
#!/usr/bin/perl
Experiment #1: The script is located in /var/www/cgi-bin: ls -alZ shows: -rwxrwxr-x apache:apache root:object_r:httpd_sys_content_t test.pl Hit through apache I get "Hello!" in my browser as expected. Executed locally from the command line as Root, the script silently fails (produces no output). Four errors appear in the message log: Jun 20 12:56:22 orac2 kernel: audit(1119290182.484:0): avc: denied { read write } for pid=20536 comm=test.pl name=0 dev=devpts ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:devpts_t tclass=chr_file Jun 20 12:56:22 orac2 kernel: audit(1119290182.484:0): avc: denied { read write } for pid=20536 comm=test.pl path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:devpts_t tclass=chr_file Jun 20 12:56:22 orac2 kernel: audit(1119290182.485:0): avc: denied { read write } for pid=20536 comm=test.pl path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:devpts_t tclass=chr_file Jun 20 12:56:22 orac2 kernel: audit(1119290182.486:0): avc: denied { read write } for pid=20536 comm=test.pl path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:httpd_sys_script_t tcontext=root:object_r:devpts_t tclass=chr_file Executed locally by user 'rsr', the script also fails and produces four identical error messages except that scontext now starts with 'user_u' instead of 'root' in each error. Experiment #2: I used 'cp' to copy the file to /home/rsr ls -alZ shows: -rwxrwxr-x apache:apache root:object_r:user_home_t test.pl Executed locally from the command line as user 'rsr', the script runs as expected, printing "Hello!". Executed locally from the command line as root, the script runs as expected, printing "Hello!". No errors appear in the messages log when run from /home/rsr. Let me know if I left anything useful out... -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Daniel J Walsh <dwalsh_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 14:18:48 -0400
>On Mon, 2005-06-20 at 11:59, Ivan Gyurdiev wrote: Basically we have a domain_auto_trans(sysadm_t, httpd_sys_script_exec_t, httpd_sys_script_t) I have been ifdefing these out for targeted policy, but I am wondering if we want these for strict policy either. Fix will be in selinux-policy-targeted-1.23.18-16 Dan -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Russell Coker <russell_at_coker.com.au> subject: Re: dumb newbie questions Date: Fri, 24 Jun 2005 16:22:59 +1000
If you don't have such a domain transition then the program will have different security contexts for running from a user login vs running from Apache. As the login session generally has more access the likely result is that some bugs or configuration issues will result in the script working properly when run from a terminal but not working when Apache runs them. Also running in different domains means different types for files that are created, in the default policy the only example of this is files under /tmp. If a cgi-bin script creates a directory under /tmp of a fixed name (yes we know it's bad but lots of scripts do it anyway) and then creates files under it then running the script once as sysadm_t or unconfined_t may then prevent the script from working when it is run from Apache. This leads to potential situations where a script that has been working fine suddenly stops working for no clear reason just because it was once run from a terminal session. One of the advantages that SE Linux offers is that bad use of temporary file names cease to be open security holes and become DOS attacks instead. -- 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 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 19:57:38 +0100
did you do a restorecon /var/www/{whereveryouputit}/test.pl after doing the mv? -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 11:56:41 -0400
SELinux performs security transitions upon execve() based on the security context of the program file, where the security context of the file is an attribute associated with the file's inode similar to the file's owner/group/mode information (but stored via extended attributes, man 5 attr, as with ACLs). To initialize the security context when a file is installed, there is a file_contexts configuration file that specifies file security contexts based on pathname regular expressions. Programs like rpm and install know to set the inode attribute at install-time based on this configuration. restorecon can also be used to manually reset the inode attribute to the one specified in the file_contexts configuration. But in general, after initialization, the inode attribute should be maintained through a combination of policy rules and (when necessary for fine-grained labeling) security-aware applications so that it reflects the real security state of the inode. At runtime, we don't want to base security decisions on pathnames, which are merely a way (among potentially many different ways) to refer to the object and don't reflect the real security state of the referenced object. We instead want to base decisions on the security attribute of the object, which is properly stored (or at least associated) with the inode. At install-time, we can infer some aspects of the security properties of the file from its location under the assumption of secure development and distribution. After installation, we want to track the real security state of the system. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 20:05:07 +0100
> What can I say, I chose the subject line for a reason... :-) :) use ls -Z a _lot_. then go through the file named file_contexts checking the regexps to make sure that the file context you see with ls -Z matches one of the regexps you see in the file_contexts file. if it don't look like it's correct (because you did a mv rather than cp with the option to set the file context when the file is in its new location) then do a restorecon. but most critically, remember that only certain areas have been "allocated" as suitable areas for cgi-scripts. look in httpd.fc (or is it apache.fc) to see what those areas are. you will expect to see a line like: /var/www/cgi-bin/* -- httpd_cgi_exec_t which means that anything executed from /var/www/cgi-bin/ will be given an selinux context of httpd_cgi_exec_t.
[... but remember what i said above about file_contexts: if you then put
files _into_ /var/www/cgi-bin/ you must double check that (in this
case) they have (e.g.) a context of httpd_cgi_exec_t (by using ls -Z)
and if they _don't_ then you _must_ do restorecon
/var...../mynewscript.
so. if you just blop files into /var/www/my-home-grown-cgi-server-directory and then don't also modify httpd.fc to reflect this new location (with an appropriate regexp) then no amount of restorecon'ing will help you. hope this helps. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 12:28:32 -0400
Hmmm...well, SELinux is designed to provide transparency as much as possible (e.g. it allows default domain transitions and file type transitions to reduce the need to modify applications, and the ability to configure policy means that you get to choose where to make functionality vs. security tradeoffs).
> If you are interested in the extra security offered, then -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 19:49:09 +0100
On Sun, Jun 19, 2005 at 10:34:47PM -0500, R. Steven Rainwater wrote:
> Ouch again. I simply don't have two months to get this system up and i wouldn't recommend either of these. what i _would_ recommend is that you install the "targetted" policy rather than the "strict" one. ... but if you absolutely absolutely must "get rid" of selinux, then use 1. not 2. remember that you will need to relabel your filesystem if you wish to reintroduce selinux, because 1) will create files without an selinux permission (equivalent to chmod 000 on files) and 2) will allow files to be created that would otherwise be banned, such that they are likely to have the _wrong_ [unpredictable] selinux file contexts. the targetted policy allows anything that isn't constrained by selinux to happily do what it likes - as long as it doesn't stomp on the toes of anything that _is_ constrained. e.g. if you haven't got a web server installed then you can write your own program, run as root, to bind to port 80. [on a "strict" system, if you haven't added the apache.te policy in then NOTHING can bind to port 80, even if you're running as root.] l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: dumb newbie questions Date: Sun, 19 Jun 2005 23:17:00 +0100
> What I think is a problem is when people use the output that's exactly what i do as a first approximation, because i don't have enough info in my head about all those macros. some of those macros expand out to TWENTY THOUSAND statements.
> To me that largely defeats the purpose of SELinux... *shrug* what else would an inexperienced person use? _after_ doing audit2allow, you can at least go back and look at some of the macros. if you want a useful tool, then what you want is an analyser that will suggest appropriate macros to use AFTER someone has done repeated application of audit2allow. an se-lint, if you will. and yes, i am aware that even doing the audit2allow "thing" doesn't help you in the slightest if you haven't a clue about domain transitions. l. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <ivg2_at_cornell.edu> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 00:11:01 -0400
> some of those macros expand out to TWENTY THOUSAND statements. ..which is a completely irrelevant statistic. What's important is how accurate the macro's header explains what the macro does. I highly dislike policy which doesn't make use of proper macros - it looks like a random collection of allow rules with no sense of purpose of any kind. That's part of the reason I don't like audit2allow. To me, the structure of policy should follow the structure of code - if you have a shared library somewhere, you should have a macro (or several of them) that can be called by whatever links to that library. Otherwise you just end up adding the same allow rules all over the place, and they're not organized in a logical module. -- Ivan Gyurdiev <ivg2@cornell.edu> Cornell University -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Trevor Vaughan <peiriannydd_at_gmail.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 09:12:37 -0400
I'm also relatively new to the SELinux game and have run into some similar PERL + Apache quirks. Basically, it looks like you have a PERL script running from within the Apache context (i.e. run by Apache) and the script is attempting to write to a character device, probably the terminal (as mentioned in a previous post). The rule that you generated with audit2allow will work but you REALLY need to think about whether or not you need to give Apache RW access to the terminal. Try this:
Also, are you running in strict or targeted mode? It sounds like targeted mode, if not, you might want to try that first. Finally, as mentioned in another post, you'll need to get the policy sources, add what you need to change, and re-compile them to make this work. I would not recommend adding any raw devices to the Apache directive, but that's up to you. Personally, I've found that the SELinux additions work great for boxes that are stripped down servers and where the system linkages are well understood but that when you start linking all around the system (especially with PERL) you may get unexpected results. However, most of these can be fixed from within the script and, if not, solved with a read-only context. Any time that you need to change something to provide write access, I would take a good, hard, look at the situation at hand. Good Luck, Trevor
> kernel: audit(1119056704.257:0): avc: denied { read write } for pid=3020 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 10:21:19 -0500
On Mon, 2005-06-20 at 08:12, Trevor Vaughan wrote:
Actually, the script is one that I run from a terminal to manually perform certain types of maintenance on the website. It's designed to be called remotely through Apache or run from the command line, in which case it spits out status messages to stdout. That's why I wrote the one-liner "hello world" test script to track down the problem. Shouldn't the root user be able to run a script that writes to stdout?
> 1. Run the script from your home directory as a Wow, amazingly, it did. I moved the script to my home directory changed the owner to me, ran it, and it printed "hello world" with no errors. I changed the owner back to root and ran it from my home directory - it still works. Looks like the owner setting doesn't make any difference. I moved the script back to within the /var/www area where it normally lives and I could no longer run it as myself or as root. This is totally bizarre - why would the directory location affect it? Is this normal or a bug in my setup? Is there a way to tell selinux that a user (or root) should be able to run a Perl script that uses stdout regardless of it's physical location? A rule like that might fix me up. Failing that, is there an easy way to get a list of directories where selinux won't allow programs using stdout to run? Not to complain but if selinux breaks (fixes?) something as universal as the ability of a program to use stdout, there should be a big red warning label in the docs, saying "Look out! Programs that use stdout will not work unless you put them in certain directories!" But that's just me...
> 2. Write a PERL script, to be run from within Apache, Yes, this was already working in most cases. The above discovery looks to be the source of my problems. If I can't figure out how to fix it, I could move copies of the non-working scripts to a directory where they'll run. Or maybe use symlinks if selinux allows it. One copy in the /var/www tree to be run by Apache and one copy somewhere else to be run locally when needed. Yuck.
> Also, are you running in strict or targeted mode? My /etc/selinux/config file says:
SELINUX=enforcing
Just for kicks I tried setting it to SELINUX=disabled and rebooted. There was no discernable difference in speed. Valdis indicated the error messages should die down after a few days, so maybe permissive is the way to go. I'll keep beating on it today and maybe I can get things working with selinux. If not, I can use permissive as Plan B. -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Ivan Gyurdiev <gyurdiev_at_redhat.com> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 11:40:47 -0400
> This is totally bizarre - why would the directory location affect it? The directory location does not affect it. The security type does. SELinux does not pay attention to the user - it pays attention to the security context. You can see the security context by typing ls -Z <file>. When you copy files into directories, you're changing their security context, much like changing permissions.
> Is this normal or a bug in my setup? This is probably normal.
> Everything not specifically allowed on SELinux is forbidden. If you have no good reason for a certain privilege, then you're not granted that privilege. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: Stephen Smalley <sds_at_tycho.nsa.gov> subject: Re: dumb newbie questions Date: Mon, 20 Jun 2005 12:20:41 -0400
The question is whether the script should be allowed to write to a local pty on the server. Naturally, you don't want that happening when it is run by apache. It is possible to configure policy such that the script runs with a different set of permissions when run directly by a user than when run by apache, but that then makes it harder to performing testing and debugging of the script by a user under the same conditions (policy) as when it is run by apache.
> This is totally bizarre - why would the directory location affect it? Is SELinux doesn't care about stdout; it care about what objects you can access. In this case, it is preventing the script from accessing a local pty on the server, for good reason. But if stdout referred to a pipe back to the apache daemon or to a socket back to the client, then it would presumably allow the script to access it.
> Yes, this was already working in most cases. The above discovery looks As noted, you can configure policy to run the script in a different domain depending on the caller. Or you can use runcon to force it to run in a particular domain, e.g. runcon `id -Z` -- /path/to/script. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.From: R. Steven Rainwater <srainwater_at_ncc.com> subject: cgiemail and senmail policy Date: Thu, 30 Jun 2005 17:11:15 -0500
Jun 30 16:47:33 orac kernel: audit(1120168053.409:0): avc: denied { write } for pid=27969 comm=sendmail path=/tmp/filegvNeNa dev=dm-0 ino=948452 scontext=root:system_r:system_mail_t tcontext=root:object_r:httpd_sys_script_rw_t tclass=file Jun 30 16:47:33 orac kernel: audit(1120168053.410:0): avc: denied { write } for pid=27969 comm=sendmail path=/tmp/filegvNeNa dev=dm-0 ino=948452 scontext=root:system_r:system_mail_t tcontext=root:object_r:httpd_sys_script_rw_t tclass=file Jun 30 16:47:33 orac kernel: audit(1120168053.410:0): avc: denied { write } for pid=27969 comm=sendmail path=/tmp/filegvNeNa dev=dm-0 ino=948452 scontext=root:system_r:system_mail_t tcontext=root:object_r:httpd_sys_script_rw_t tclass=file Jun 30 16:47:33 orac kernel: audit(1120168053.410:0): avc: denied { read write } for pid=27969 comm=sendmail path=/tmp/tmpfKM8Top (deleted) dev=dm-0 ino=948418 scontext=root:system_r:system_mail_t tcontext=root:object_r:httpd_sys_script_rw_t tclass=file
Jun 30 16:47:33 orac kernel: audit(1120168053.510:0): avc: denied {
search } for pid=27969 comm=sendmail name=www dev=dm-0 ino=556110
scontext=root:system_r:system_mail_t
Jun 30 16:47:33 orac kernel: audit(1120168053.511:0): avc: denied { getattr } for pid=27969 comm=sendmail path=/var/www dev=dm-0 ino=556110 scontext=root:system_r:system_mail_t tcontext=system_u:object_r:httpd_sys_content_t tclass=dir The system is using selinux-policy-targeted-1.17.30-2.88.
-Steve
-- subject: Re: cgiemail and senmail policy Date: Sun, 03 Jul 2005 10:21:27 -0400
>I'm running a CentOS 4.1 (Red Hat EL) box with an Apache web server. I ftp://people.redhat.com/dwalsh/SELinux/RHEL4/u1 Dan -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |