SELinux Integrated Logging Tool

SELinux Integrated Logging Tool

[Brandon Pollet]

After releasing information about my Dynamic Policy Enforcement  
system last week, I wanted to share some of the other projects that  
we have developed at the University of Tulsa over the last year.

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
that enhances standard Unix-based permissions, and allows for greater  
overall system
security. While a wide array of configuration tools are currently  
available, system
administration of SELinux is still cumbersome. One strategic area of  
improvement is
kernel event logging, specifically for Security-Enhanced Linux  
generated events. This
thesis describes SILT, a tool designed to enhance SELinux logging. A  
flexible interface
supports command-line and graphical logging configuration. Backend  
scripts tune the
logging facility, according to user direction. SILT provides a  
convenient mechanism
for administrators to manage logging events effectively, allowing for  
improved system
maintenance.

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.

Re: SELinux Integrated Logging Tool

[James Morris]

On Fri, 17 Jun 2005, Brandon Pollet wrote:

> 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

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.


- James
-- 
James Morris
<jmorris@redhat.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.

Re: SELinux Integrated Logging Tool

[Steve G]

>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.

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.

dumb newbie questions

[R. Steven Rainwater]

I've just installed CentOS 4.1 on a box and have run into what I think
are selinux related issues. (CentOS is basically a renamed RedHat
Enterprise Linux). 

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
print "hello\n";

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):

1. Why would some of my scripts run and some not - they're all pretty
much the same, they all do file I/O, print to stdout, a couple access an
SQL server on another box. But I can't find anything common to the ones
that don't work. I realize this might be hard to answer without seeing
the code but I'll take even a theory at this point.

2. How do I get a new scripts or program to run? One FAQ came near to
answering this but was incomplete. It said I should run the offending
program, then extract the warning line from the messages file and run it
through a program called audit2allow. Audit2allow seems to need an input
file so I copied one of the warning lines from the log into a text file,
test.txt, and did 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



--
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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> 2. How do I get a new scripts or program to run? One FAQ came near to
> answering this but was incomplete. It said I should run the offending
> program, then extract the warning line from the messages file and run it
> through a program called audit2allow. Audit2allow seems to need an input
> file so I copied one of the warning lines from the log into a text file,
> test.txt, and did this:
> 
> audit2allow test.txt

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
> 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.

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.

Re: dumb newbie questions

[Casey Schaufler]

--- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:


> 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.

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
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Ivan Gyurdiev]

On Sun, 2005-06-19 at 09:40 -0700, Casey Schaufler wrote:
> 
> --- Ivan Gyurdiev <gyurdiev@redhat.com> wrote:
> 
> 
> > 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.
> 
> 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".

You're misrepresenting the point of my response...

Who writes the policy is not important.
Well - it is important, but that's not what I was talking
about here. I am all for improvements in the way SELinux
is distributed, and documented, so that more people can 
write policy.

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.

Re: dumb newbie questions

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:

> 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
> talking about here.

Yes, it's important. And an issue.

> I am all for improvements in the way SELinux
> is distributed, and documented, so that more people
> can write policy.

I am a strong advocate of the above.

> What I think is a problem is when people use the
> output of audit2allow as the policy... which is
> what I see happening.

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
disparaging constitute the best available
documentation and they recommend it. If there
were documentation that described how it
ought to be done maybe you could get it done
properly.

> 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
casey@schaufler-ca.com

__________________________________________________
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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> 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.

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.

Re: dumb newbie questions

[Casey Schaufler]

--- Ivan Gyurdiev <ivg2@cornell.edu> wrote:

> 
> > 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.
> 
> 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.

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
supporting SELinux properly SELinux will
die on the vine. You will not get developers
into the SELinux camp without sufficient
and readily available tools and documentation.
Oh, and respect, too.

I hope that when I bring the project I
have underway out I can include a rational
SELinux policy as part of the package.
I do not have faith that the "SELinux People"
will understand it sufficiently to provide
a policy for it.

> Anyway, I think Steven (Smalley) has mentioned that
> more efforts to decentralize policy will occur
> after Tresys' binary modules work is merged.

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
applications it impacts can't even be repaired
by their maintainers. Harumph.



Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Sun, Jun 19, 2005 at 02:31:51PM -0700, Casey Schaufler wrote:
 
> 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
> applications it impacts can't even be repaired
> by their maintainers. 

 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.

Re: dumb newbie questions

[Casey Schaufler]

> 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.

I do not know enough about SELinux to explain it.
I do not know how to do a policy.
I do not have a clue why the existing policy
module is deemed sensible.

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
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Sun, Jun 19, 2005 at 01:14:52PM -0700, Casey Schaufler wrote:
> 
> 
> --- Ivan Gyurdiev <ivg2@cornell.edu> wrote:
> 
> > 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.
 
 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.

Re: dumb newbie questions

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:


> > 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.
>  
>  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.

My point, and I hope that someday I'll
come up with the right set of words to
make it clear, is that if it is indeed
the case that application developers
cannot be trained to get the SELinux policy
correct that that is a fatal deficiency
in the facility. SELinux cannot survive,
even with the backing of the NSA and RedHat,
if the developer community does not get
behind it and that will not happen until
developers have the information and tools
they need to become expert in the generation
of policies.

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
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Sun, Jun 19, 2005 at 05:16:55PM -0700, Casey Schaufler wrote:
> 
> 
> --- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
> wrote:
> 
> 
> > > 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.
> >  
> >  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.
> 
> My point, and I hope that someday I'll
> come up with the right set of words to
> make it clear, is that if it is indeed
> the case that application developers
> cannot be trained to get the SELinux policy
> correct that that is a fatal deficiency
> in the facility. 

 i _would_ agree with you... if it wasn't for this:

 * that security in unix is glaringly deficient;

 * that application developers are notoriously ignorant of security issues;

 * that languages like c and c++ and processors like the x86 _invite_ 
 security issues.

 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.

Re: dumb newbie questions

[Casey Schaufler]

--- Luke Kenneth Casson Leighton <lkcl@lkcl.net>
wrote:


>  i _would_ agree with you... if it wasn't for this:
> 
>  * that security in unix is glaringly deficient;

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
> ignorant of security issues;

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
> the x86 _invite_ security issues.

Careful there, it's a poor workman who
blames his tools. Further, in today's
world it's not the underlying system that
is typically at fault, it's the lack of
security design at the higher levels.

>  and that this is true _irrespective_ of whether
> selinux exists or not.

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
> 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.

One of two things has to be true. Either:
1. Developers need to be able to get it right
  - or -
2. SELinux policy developers have to understand
   the applications the are writing policy for
   to the same level as the application developers.

>  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.

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
> 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!]

This is an example of a programming flaw.
Most security problems we see today are
programming flaws.

 
>  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.

Which was true, SELinux or no.

>  ... 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?

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
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 481 bytes --]

On Mon, 20 Jun 2005 13:41:06 PDT, Casey Schaufler said:

> 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?

This presupposes two very unlikely events:

1) That *all* the problems are found
2) That no further software upgrades happen, introducing more problems.

Other than that, yes, you could turn it off once your system is
100% secured and infallible.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dumb newbie questions

[Casey Schaufler]

--- Valdis.Kletnieks@vt.edu wrote:

> This presupposes two very unlikely events:
> 
> 1) That *all* the problems are found

Nope, just that all the problems that the
"policy" would find are found. Since the
policy will not find things it does not
find ...

> 2) That no further software upgrades happen,
> introducing more problems.

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
> your system is
> 100% secured and infallible.

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
casey@schaufler-ca.com


		
____________________________________________________ 
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.

Re: dumb newbie questions

[Christopher Warner]

Pardon my tardiness to this thread. None the less i'm going to have to
agree with Casey on this issue. Monday, while this thread was in
commencement. I was having a 2 hour meeting discussing Selinux and it's
use/implementation for this company I work for. Specifically how it will
work/interact with one of the applications we sell.

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:
> 
> --- Valdis.Kletnieks@vt.edu wrote:
> 
> > This presupposes two very unlikely events:
> > 
> > 1) That *all* the problems are found
> 
> Nope, just that all the problems that the
> "policy" would find are found. Since the
> policy will not find things it does not
> find ...
> 
> > 2) That no further software upgrades happen,
> > introducing more problems.
> 
> 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
> > your system is
> > 100% secured and infallible.
> 
> 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
> casey@schaufler-ca.com
> 
> 
> 		
> ____________________________________________________ 
> 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.
-- 
.-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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> > 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".
> 
> You're misrepresenting the point of my response...
> 
> Who writes the policy is not important.
> Well - it is important, but that's not what I was talking
> about here. I am all for improvements in the way SELinux
> is distributed, and documented, so that more people can 
> write policy.
> 
> 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... 

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 
(system-config-securitylevel)

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.

Re: dumb newbie questions

[R. Steven Rainwater]

Thanks for the replies so far. I understand that using audit2allow is
the wrong way to fix my problem but that still doesn't get me any closer
to making my perl scripts work.

On Sun, 2005-06-19 at 16:41 -0400, Ivan Gyurdiev wrote:
> To actually write policy you need to understand the
> SELinux policy language. There are several books
> on this...

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: 
>  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.

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:

1. adding SELINUX=disabled to /etc/sysconfig/selinux

2. or, add SELINUX=permissive

>From what the FAQs say, I'm guessing #1 is the way to go? It sounds like
option 2 will fill up my message log with more warnings. One of the FAQs
also says having selinux turned on slows the system down by 7%, so I'm
guess I'll get my 7% back with option 1 but not option 2?

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.

Re: dumb newbie questions

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]

On Sun, 19 Jun 2005 22:34:47 CDT, "R. Steven Rainwater" said:
> 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. :-(

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
> 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.

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
> 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:
> 
> 1. adding SELINUX=disabled to /etc/sysconfig/selinux
> 
> 2. or, add SELINUX=permissive
> 
> >From what the FAQs say, I'm guessing #1 is the way to go? It sounds like
> option 2 will fill up my message log with more warnings. One of the FAQs
> also says having selinux turned on slows the system down by 7%, so I'm
> guess I'll get my 7% back with option 1 but not option 2?

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
> test box and play around with selinux again.

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....)


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: dumb newbie questions

[R. Steven Rainwater]

On Sun, 2005-06-19 at 23:45, Valdis.Kletnieks@vt.edu wrote:
> On Sun, 19 Jun 2005 22:34:47 CDT, "R. Steven Rainwater" said:
> 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.

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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> I quoted the source of my one line perl test script and error message it
> generated in a previous post. 

...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
> box.

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
> 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. 

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.

Re: dumb newbie questions

[R. Steven Rainwater]

On Mon, 2005-06-20 at 10:14, Ivan Gyurdiev wrote:
> > I quoted the source of my one line perl test script
> >and error message it generated in a previous post. 
> 
> ...and  I've pointed out that your script doesn't run,
> because httpd scripts are not allowed to write to the 
> terminal.

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.

Re: dumb newbie questions

[Ivan Gyurdiev]

On Mon, 2005-06-20 at 10:29 -0500, R. Steven Rainwater wrote:
> On Mon, 2005-06-20 at 10:14, Ivan Gyurdiev wrote:
> > > I quoted the source of my one line perl test script
> > >and error message it generated in a previous post. 
> > 
> > ...and  I've pointed out that your script doesn't run,
> > because httpd scripts are not allowed to write to the 
> > terminal.
> 
> 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?

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.

Re: dumb newbie questions

[R. Steven Rainwater]

On Mon, 2005-06-20 at 10:44, Ivan Gyurdiev wrote:
> On Mon, 2005-06-20 at 10:29 -0500, R. Steven Rainwater wrote:
> > I'm assuming now, that selinux makes guesses about what
> > sort of program it is by where it's located?
> 
> 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).

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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> 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

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...
cc-ed dwalsh

>  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.

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
> 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.

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.

RE: dumb newbie questions

[Karl MacMillan]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov] On
> Behalf Of Ivan Gyurdiev
> Sent: Monday, June 20, 2005 12:59 PM
> To: R. Steven Rainwater
> Cc: Daniel J Walsh; SELinux@tycho.nsa.gov
> Subject: Re: dumb newbie questions
> 
> >  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.
> 
> 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'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 134

> 
> > 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.
> 
> 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.



--
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.

Re: dumb newbie questions

[R. Steven Rainwater]

On Mon, 2005-06-20 at 11:59, Ivan Gyurdiev wrote:
> 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.

No problem. Here's the whole thing with a little more detail.

The perl script "test.pl":

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello!\n"

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.

Re: dumb newbie questions

[Daniel J Walsh]

R. Steven Rainwater wrote:

>On Mon, 2005-06-20 at 11:59, Ivan Gyurdiev wrote:
>  
>
>>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.
>>    
>>
>
>No problem. Here's the whole thing with a little more detail.
>
>The perl script "test.pl":
>
>#!/usr/bin/perl
>print "Content-type: text/html\n\n";
>print "Hello!\n"
>
>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
>
>  
>
Ok there is a bug in policy.

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.

Re: dumb newbie questions

[Russell Coker]

On Tuesday 21 June 2005 04:18, Daniel J Walsh <dwalsh@redhat.com> wrote:
> Ok there is a bug in policy.
>
> 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.

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.

Re: dumb newbie questions

[Daniel J Walsh]

Ivan Gyurdiev wrote:

>>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
>>    
>>
>
>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...
>cc-ed dwalsh
>
>  
>
>> 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.
>>    
>>
>
>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
>>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.
>>    
>>
>
>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.
>  
>
The latest targeted policy does/should not transition from unconfined_t 
to httpd_sys_script_t.  So the script should be allowed to output to the
terminal.  If you update policy that is.

-- 



--
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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Mon, Jun 20, 2005 at 11:40:17AM -0500, R. Steven Rainwater wrote:
> On Mon, 2005-06-20 at 10:44, Ivan Gyurdiev wrote:
> > On Mon, 2005-06-20 at 10:29 -0500, R. Steven Rainwater wrote:
> > > I'm assuming now, that selinux makes guesses about what
> > > sort of program it is by where it's located?
> > 
> > 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).
> 
> 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
 
 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.

Re: dumb newbie questions

[Stephen Smalley]

On Mon, 2005-06-20 at 10:29 -0500, R. Steven Rainwater wrote: 
> 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.

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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Mon, Jun 20, 2005 at 10:29:29AM -0500, R. Steven Rainwater wrote:

> 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.

Re: dumb newbie questions

[Stephen Smalley]

On Mon, 2005-06-20 at 11:14 -0400, Ivan Gyurdiev wrote: 
> SELinux is not supposed to be transparent. 
> That was my misunderstanding when I first encountered it,
> and I have accepted this requirement since then. 

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
> 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.

-- 
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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

allo steven, i didn't notice it was you doin the asking :)
long time no talk!

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
> 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:
> 
> 1. adding SELINUX=disabled to /etc/sysconfig/selinux
> 
> 2. or, add SELINUX=permissive

 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.

Re: dumb newbie questions

[Luke Kenneth Casson Leighton]

On Sun, Jun 19, 2005 at 03:51:58PM -0400, Ivan Gyurdiev wrote:

> What I think is a problem is when people use the output
> of audit2allow as the policy... which is what I see happening.

 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.

Re: dumb newbie questions

[Ivan Gyurdiev]

>  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.

Re: dumb newbie questions

[Trevor Vaughan]

Hi Steven,

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:

1. Run the script from your home directory as a normal user. (This should work).
2. Write a PERL script, to be run from within Apache, that writes a
file that is inside the web directory (whatever that may be on your
system, probably /var/httpd/htdocs or the like).  (This should work
since it is within the httpd system space.)

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
> 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


--
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.

Re: dumb newbie questions

[R. Steven Rainwater]

Thanks for your comments, Trevor. I think you've helped me stumble into
the answer (or at least into the right questions).

On Mon, 2005-06-20 at 08:12, Trevor Vaughan wrote:
> 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

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
> normal user. (This should work).

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,
> that writes a file that is inside the web directory

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
SELINUX=targeted

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.

Re: dumb newbie questions

[Ivan Gyurdiev]

> 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.

> 
> 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...

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.

Re: dumb newbie questions

[Stephen Smalley]

On Mon, 2005-06-20 at 10:21 -0500, R. Steven Rainwater 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?

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
> 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?

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
> 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.

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.

cgiemail and senmail policy

[R. Steven Rainwater]

I'm running a CentOS 4.1 (Red Hat EL) box with an Apache web server. I
thought I'd worked out all the problems with my cgi scripts but a new
one cropped up today. We use the good ol' MIT cgiemail program to handle
form submissions that get sent via sendmail. When someone submits a
form, I get a series of avc errors and no email gets sent. What's the
best way to fix this (i.e. to make Apache able to use cgiemail to send
email via sendmail)?  Here are the errors I'm getting:
 
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
tcontext=system_u:object_r:httpd_sys_content_t tclass=dir

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


--
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.

Re: cgiemail and senmail policy

[Daniel J Walsh]

R. Steven Rainwater wrote:

>I'm running a CentOS 4.1 (Red Hat EL) box with an Apache web server. I
>thought I'd worked out all the problems with my cgi scripts but a new
>one cropped up today. We use the good ol' MIT cgiemail program to handle
>form submissions that get sent via sendmail. When someone submits a
>form, I get a series of avc errors and no email gets sent. What's the
>best way to fix this (i.e. to make Apache able to use cgiemail to send
>email via sendmail)?  Here are the errors I'm getting:
> 
>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
>tcontext=system_u:object_r:httpd_sys_content_t tclass=dir
>
>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
>
>  
>
Upgrade to    the latest RHEL policy on.

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.