6:24 p.m.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127900
I reported the bug in at the url above, and was told it was because I
needed to relabel the file. I just moved it from /home/user
to /var/www/html. I don't think it is reasonable to have to relabel
every time a file is moved around to work around possible problems with
SELinux. This could be especially bad with web servers where the users
only have ftp access. They upload files and move them around, but don't
have the ability to run the commands necessary to relabel. Hence I
believe even SELinux targeted should be off by default in FC3, or I
would expect to see lots of such bug reports from users.
My personal view of SELinux at this point is it sounds nice, but if it
requires running relabel constantly it isn't worth the trouble. The
process needs to be automated.
11:06 p.m.
On Wed, 2004-10-06 at 16:24 -0700, Nathan Grennan wrote:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127900
I reported the bug in at the url above, and was told it was because I
needed to relabel the file. I just moved it from /home/user
to /var/www/html.
You can copy instead of moving, that will cause the newly created file
to inherit the target directory's security context.
I don't think it is reasonable to have to relabel
every time a file is moved around to work around possible problems with
SELinux.
It's a good thing that a bit of work is required to expose your personal
data to the web server.
This could be especially bad with web servers where the users
only have ftp access. They upload files and move them around, but don't
have the ability to run the commands necessary to relabel.
If you upload via FTP directly to the web site, then it will Just Work.
If you upload to your home directory and then rename to the website
directory (which seems rather odd to me), then yes, you will need to
relabel. And normal users can do this, just run:
chcon -t httpd_user_content_t filename
Hence I
believe even SELinux targeted should be off by default in FC3,
You can disable SELinux protection just for Apache if you like, run
system-config-securitylevel.
2:07 a.m.
On Thu, 2004-10-07 at 00:06 -0400, Colin Walters wrote:
You can copy instead of moving, that will cause the newly created
file
to inherit the target directory's security context.
So the move command is obsolete, and all users will figure this out and
accept it?
It's a good thing that a bit of work is required to expose your
personal
data to the web server.
It should be obvious that I am exposing it when I move it
to /var/www/html.
If you upload via FTP directly to the web site, then it will Just
Work.
If you upload to your home directory and then rename to the website
directory (which seems rather odd to me), then yes, you will need to
relabel. And normal users can do this, just run:
I have seen users accidentally upload data to /home/user, instead
of /home/public_html and then move it. A user may also want to upload
big files like isos before a release to /home/user, and then move them
into /home/user/public_html when the time is right. Users will do all
kinds of things you can think of doing.
You can disable SELinux protection just for Apache if you like, run
system-config-securitylevel.
So it is good to be broken out of the box? This is also just one case
with one service. I am sure many more such problems will come up. I
think that SELinux should be more transparent to the user before
becoming the default.
7:46 a.m.
On Thu, 2004-10-07 at 03:07, Nathan G. Grennan wrote:
So the move command is obsolete, and all users will figure this out
and
accept it?
The mv command preserve protections by default, as expected. A similar
issue would arise if the original ownership and mode bits on the file
prior to moving prevented access by apache, right?
It should be obvious that I am exposing it when I move it
to /var/www/html.
As above, do you expect mv to rewrite the DAC ownership and mode bits
when you move a file to /var/www/html? And note that the pathname by
which you access a file tells us nothing useful about its protection
requirements; a single file may have many names via multiple hard links,
bind mounts, etc, and letting people bypass protection by using a
different name is a classic security flaw.
I have seen users accidentally upload data to /home/user, instead
of /home/public_html and then move it. A user may also want to upload
big files like isos before a release to /home/user, and then move them
into /home/user/public_html when the time is right. Users will do all
kinds of things you can think of doing.
And they already have to deal with setting mode bits. Running
restorecon on the file as an extra step is just an education issue.
So it is good to be broken out of the box? This is also just one
case
with one service. I am sure many more such problems will come up. I
think that SELinux should be more transparent to the user before
becoming the default.
Improved transparency is certainly a good thing, but you are imposing an
unfair requirement on SELinux that does not exist for the existing DAC
protections and total transparency would just mean no protection at
all.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
10:41 a.m.
On Thu, 2004-10-07 at 08:46 -0400, Stephen Smalley wrote:
The mv command preserve protections by default, as expected. A
similar
issue would arise if the original ownership and mode bits on the file
prior to moving prevented access by apache, right?
Security contexts are generally hidden, their are so many more, and are
a lot more complex. Owner/Group/Permissions/Umask are setup in such a
way that they generally not a problem, unlike security contexts.
And they already have to deal with setting mode bits. Running
restorecon on the file as an extra step is just an education issue.
I think this is asking too much, especially when the complexity level is
such that users won't generally be manually setting security context,
but letting the system figure out the correct context for them via
restorecon. That says to me it is more of a automation problem than it
is a education problem.
Improved transparency is certainly a good thing, but you are imposing
an
unfair requirement on SELinux that does not exist for the existing DAC
protections and total transparency would just mean no protection at
all.
I think overall it what it comes down to is that SELinux micro-manages
security way too much. SELinux's level of security might be suitable in
some situations, but will be too much of a burden in most situations.
10:44 a.m.
On Thu, 2004-10-07 at 11:41, Nathan Grennan wrote:
I think overall it what it comes down to is that SELinux
micro-manages
security way too much. SELinux's level of security might be suitable in
some situations, but will be too much of a burden in most situations.
http://www.nsa.gov/selinux/papers/inevit-abs.cfm
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
11:06 a.m.
On Thu, 2004-10-07 at 08:41 -0700, Nathan Grennan wrote:
I think this is asking too much, especially when the complexity level
is
such that users won't generally be manually setting security context,
but letting the system figure out the correct context for them via
restorecon. That says to me it is more of a automation problem than it
is a education problem.
No. As I said in my other mail, particularly in the Apache case, either
the user needs to be aware of them, or you need much higher-level
domain-specific tools built that handle it automatically.
The Apache policy is somewhat special in that it defines new types that
users are allowed to change to and from; typically, users are not
allowed to relabel files. Generally SELinux is otherwise transparent -
when you create a file in your home directory it automatically gets the
type user_home_t.
However, as we move towards finer-grained controls on user applications
like Mozilla, users will have to become more generally aware of security
contexts and how to change them.
11:07 a.m.
On Thu, 07 Oct 2004 08:41:30 -0700, Nathan Grennan
Security contexts are generally hidden, their are so many more, and
are
a lot more complex. Owner/Group/Permissions/Umask are setup in such a
way that they generally not a problem, unlike security contexts.
I think there is a strong point about complexity of the settings
space. The fact that ownership permission and umask use a small finite
settings space makes the ui for changing those settings managable
across a number of tools.
For example lftp client understands chmod. does it understand restorecon?
I think this is asking too much, especially when the complexity level
is
such that users won't generally be manually setting security context,
but letting the system figure out the correct context for them via
restorecon
I think there is a point here too.. but let me rephrase it by asking a
question. Is there ever any value in having files in a path NOT be
the correct security context for that path?
If there is never any value in leaving security contexts 'stale' after
a mv operation, and it is always expected that a user will be required
to run restorecon for useful operation. It seems reasonable to me that
mv should be applying the correct context for the new path location
automatically.
Are there tools in userspace with 'reasonable' ui that would let a
user manually change context on a subset of files contrary to what
restorecon would do? If there is a lack of tools that let users
delibrately create out of sync security contexts, thats a major
difference between how ownership and permissions are handled.
-jef"notice all those if's....."spaleta
11:56 a.m.
On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
I think there is a strong point about complexity of the settings
space. The fact that ownership permission and umask use a small finite
settings space makes the ui for changing those settings managable
across a number of tools.
Security contexts are simply security equivalence classes, i.e.
everything with the same security context is handled identically as far
as the security policy is concerned. The permissions granted to a given
security context (the parallel to your DAC mode bits) are defined
centrally in the policy configuration, and you can analyze the entire
policy there, including the maximum possible privilege escalation and
information flows allowed. Contrast with DAC mode bits or ACLs, where
the policy is effectively scattered throughout the filesystem and
neither privilege escalation nor information flow are bounded in any
way.
For example lftp client understands chmod. does it understand
restorecon?
Not yet, AFAIK. Nor will it likely ever if SELinux is disabled by
default and it remains limited to a very small user community.
I think there is a point here too.. but let me rephrase it by asking
a
question. Is there ever any value in having files in a path NOT be
the correct security context for that path?
Yes, there is value in customizing your file contexts beyond the default
settings.
Are there tools in userspace with 'reasonable' ui that would
let a
user manually change context on a subset of files contrary to what
restorecon would do? If there is a lack of tools that let users
delibrately create out of sync security contexts, thats a major
difference between how ownership and permissions are handled.
chcon(1) is the equivalent to chown/chmod.
Mandatory access control is a (to steal a term) disruptive technology,
but one that is fundamentally necessary if one is ever going to be able
to effectively control or even reliably monitor what is truly happening
on computing systems. With only DAC, the code that acts on our behalf
operates without any restraint and with precious little protection
against subversion. If you want to have a hope of confining the damage
caused by flawed and/or malicious program, protecting your application
security mechanisms against tampering and bypass, separating your
sensitive information from your public information, protecting
information on which your operations depend from corruption, or ensuring
that your data is processed as required, then MAC is a necessary
building block, not optional.
As far as freedom is concerned, one always has the option of disabling
SELinux at install time or post-install; I don't think anyone has any
plans to change that. But disabling by default has a huge impact on
uptake of this disruptive technology and on bringing sufficient
resources to bear to fully integrate it into the entire system.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:23 p.m.
On Thu, 2004-10-07 at 12:56 -0400, Stephen Smalley wrote:
On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
> I think there is a point here too.. but let me rephrase it by asking a
> question. Is there ever any value in having files in a path NOT be
> the correct security context for that path?
Yes, there is value in customizing your file contexts beyond the default
settings.
The point of the original question (as I interpreted it), is there value
in having mv, rename, and similar operations not update the file's
security context to the correct one of the new path? In the case where
the file *should* have a different security context than other files
have by default in that path, then the user/admin can manually change
things.
The common operation should have the expected result. So, the question
is, shouldn't the desired behavior of the mv, rename, and similar
operations be to update the context of the file by default?
> Are there tools in userspace with 'reasonable' ui that would let a
> user manually change context on a subset of files contrary to what
> restorecon would do? If there is a lack of tools that let users
> delibrately create out of sync security contexts, thats a major
> difference between how ownership and permissions are handled.
chcon(1) is the equivalent to chown/chmod.
Mandatory access control is a (to steal a term) disruptive technology,
but one that is fundamentally necessary if one is ever going to be able
to effectively control or even reliably monitor what is truly happening
on computing systems. With only DAC, the code that acts on our behalf
operates without any restraint and with precious little protection
against subversion. If you want to have a hope of confining the damage
caused by flawed and/or malicious program, protecting your application
security mechanisms against tampering and bypass, separating your
sensitive information from your public information, protecting
information on which your operations depend from corruption, or ensuring
that your data is processed as required, then MAC is a necessary
building block, not optional.
Most people do not complain about MAC due to the fact that it does what
it does. Most complaints on SELinux are because it's far too complex to
get it to do what it does. Complexity is the bane of security. Lack of
education on security is the biggest security problem of them all.
SELinux adds a lot of complexity and increases the amount of education a
user/admin needs to operate a secured system.
The SELinux configuration syntax makes it vastly too difficult to
configure things for the common case. The format makes it possible to
do just about anything, yes, but when you just know that binary foo only
needs to do X and Y to files A and B, it requires an extensive
background in SELinux to be able to configure properly.
Simplifying the config syntax could make SELinux far more usable. The
current syntax requires the admin to think in terms of SELinux
mechanics, not in terms of what they want the system to do. You can't
just write "/bin/foo can only perform read operations, and only
on /etc/foo.rc," you need to write, "/bin/foo is this
context, /etc/foo.rc is this context, and the traits between these are
this" and so on. Low-level implementation details are directly exposed.
It's a poor design that only makes sense to the SELinux designers.
Think user interface design and usability. The config files are the
SELinux user interface exposed to administrators. It should be a syntax
and format that is ideal for how administrators think and the work they
want to do, not a syntax and format that is ideal for SELinux
developers.
A security system that is too complicated to use properly can be a lot
worse than a weaker security system that its users can easily understand
and configure.
Design the exposed UI for the end users of the system. Don't just
expose the raw UI that developers understand. And the config files are
definitely UI.
As far as freedom is concerned, one always has the option of disabling
SELinux at install time or post-install; I don't think anyone has any
plans to change that. But disabling by default has a huge impact on
uptake of this disruptive technology and on bringing sufficient
resources to bear to fully integrate it into the entire system.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
1:50 p.m.
On Thu, 2004-10-07 at 13:23 -0400, Sean Middleditch wrote:
On Thu, 2004-10-07 at 12:56 -0400, Stephen Smalley wrote:
> On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
> > I think there is a point here too.. but let me rephrase it by asking a
> > question. Is there ever any value in having files in a path NOT be
> > the correct security context for that path?
>
> Yes, there is value in customizing your file contexts beyond the default
> settings.
The point of the original question (as I interpreted it), is there value
in having mv, rename, and similar operations not update the file's
security context to the correct one of the new path?
Yes. As Stephen said, moving a file doesn't change its DAC permissions,
so it shouldn't change its MAC label either.
The common operation should have the expected result. So, the
question
is, shouldn't the desired behavior of the mv, rename, and similar
operations be to update the context of the file by default?
You might as well argue that moving a file into ~/public_html should
make it automagically readable by Apache, even if the file mode is 600.
Most people do not complain about MAC due to the fact that it does
what
it does. Most complaints on SELinux are because it's far too complex to
get it to do what it does. Complexity is the bane of security. Lack of
education on security is the biggest security problem of them all.
SELinux adds a lot of complexity and increases the amount of education a
user/admin needs to operate a secured system.
One certainly needs to learn more, but fundamental advancements like
this will always require learning new things. That's just life.
The SELinux configuration syntax makes it vastly too difficult to
configure things for the common case. The format makes it possible to
do just about anything, yes, but when you just know that binary foo only
needs to do X and Y to files A and B,
There is a *lot* more than just files that require protection.
Processes, file descriptors, ports, sysv shmem, etc.
Simplifying the config syntax could make SELinux far more usable.
The
current syntax requires the admin to think in terms of SELinux
mechanics, not in terms of what they want the system to do. You can't
just write "/bin/foo can only perform read operations, and only
on /etc/foo.rc,"
Having something like that in the policy would add more confusion,
because it would be a huge special case. The SELinux policy is simple
in that the essentials only deal with types - there is the same
conceptual model for files, as well as processes, TCP ports, etc.
This would also make it much harder to write a tool like apol which can
analyze a security policy to determine information flow - can my web
administrator with control over httpd_t access any nurse_t processes or
any health_record_t files?
you need to write, "/bin/foo is this
context, /etc/foo.rc is this context, and the traits between these are
this" and so on. Low-level implementation details are directly exposed.
It's not "implementation details" - types are fundamental to
understanding and using MAC, they cannot be hidden.
10:47 a.m.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] On Behalf Of Colin Walters
> Simplifying the config syntax could make SELinux far more usable. The
> current syntax requires the admin to think in terms of SELinux
> mechanics, not in terms of what they want the system to do. You can't
> just write "/bin/foo can only perform read operations, and only
> on /etc/foo.rc,"
Having something like that in the policy would add more confusion,
because it would be a huge special case. The SELinux policy is simple
in that the essentials only deal with types - there is the same
conceptual model for files, as well as processes, TCP ports, etc.
This would also make it much harder to write a tool like apol which can
analyze a security policy to determine information flow - can my web
administrator with control over httpd_t access any nurse_t processes or
any health_record_t files?
Not only can this type of analysis not be done on the existing DAC
mechanism, if it could that answer could change at any time. With SELinux we
can answer questions like this and know that the answer will remain the same
as long as the policy doesn't change. Also, the flow of information in a
system can help you answer many interesting questions beyond the disclosure
of sensitive information. For example, integrity questions like who/what can
write information to the config files for trusted applications.
Karl
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134
> you need to write, "/bin/foo is this
> context, /etc/foo.rc is this context, and the traits between these are
> this" and so on. Low-level implementation details are directly exposed.
It's not "implementation details" - types are fundamental to
understanding and using MAC, they cannot be hidden.
3:06 p.m.
Design the exposed UI for the end users of the system. Don't
just
expose the raw UI that developers understand. And the config files are
definitely UI.
I'd say that new ways to configure it will evolve out of the current environment.
Remember when IPTables first came out? You had to be a network guru and write
your own script. Now you can choose between many programs that let you configure
iptables. For example, shorewall or firewall builder. I think over time (and as
the needs are made clearer) better tools will be created out of necessity or
simply seeing a better way.
This is really what's missing...a healthy set of competing utilities and policy
writing tools. I've been toying with doing something along the lines of firewall
builder in my spare time. Gotta clear a back-log of projects first, though.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
10:25 a.m.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] On Behalf Of Steve G
>Design the exposed UI for the end users of the system. Don't just
>expose the raw UI that developers understand. And the config files are
>definitely UI.
I'd say that new ways to configure it will evolve out of the current
environment.
Remember when IPTables first came out? You had to be a network guru and
write
your own script. Now you can choose between many programs that let you
configure
iptables. For example, shorewall or firewall builder. I think over time
(and as
the needs are made clearer) better tools will be created out of necessity
or
simply seeing a better way.
This is really what's missing...a healthy set of competing utilities and
policy
writing tools. I've been toying with doing something along the lines of
firewall
builder in my spare time.
Steve - I agree with you here. The underlying policy language does a good
job of representing the SELinux model, but policy writers need some tools
and frameworks to allow them to work at a higher level and more directly
encode the security goals they care about. This might, for example, allow
them to focus on how information flows through an email relay so that they
can ensure that every email must pass through a virus scanner. For an
experienced policy writer, I assert that it is fairly straightforward to
accomplish this in the existing policy language, but for others some more
support is necessary.
We are actively working on this problem and have some interesting concepts
in development. I hope that we will have something more concrete to share in
the coming months.
Karl
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134
Gotta clear a back-log of projects first,
though.
-Steve Grubb
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
12:46 p.m.
Once upon a time, Stephen Smalley <sds(a)epoch.ncsc.mil> said:
> For example lftp client understands chmod. does it understand
restorecon?
Not yet, AFAIK. Nor will it likely ever if SELinux is disabled by
default and it remains limited to a very small user community.
That doesn't really have much to do with SELinux being enabled or
disabled; it has more to do with coming up with a standard FTP extension
to handle additional security settings, getting it in an RFC, and
getting software authors to implement it. It could be done as a SITE
command, but it still needs to be well-specified before anyone would
support it.
The basic fact is that FTP isn't going away for a long time to come.
With things like Kerberos and IPsec or even STARTTLS, FTP doesn't need
to go away.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
11:40 a.m.
On Thu, 2004-10-07 at 08:41 -0700, Nathan Grennan wrote:
I think overall it what it comes down to is that SELinux
micro-manages
security way too much. SELinux's level of security might be suitable in
some situations, but will be too much of a burden in most situations.
Not to put SELinux in bad company, but the level of security provided by
SELinux is very similar to what is provided by the Windows NT/XP
security system and that doesn't seem to bother people too much. Of
course, MS essentially turns it off to prevent that!
I think the crux of this thread is that there are likely to be cases
(especially short-term) where SELinux poses a burden. While some of
these cases may be reasonably common (hosting customers FTP-ing up
files, etc), I really don't think they justify disabling SELinux as a
whole out-of-the-box. If RH was to do that, they might as well stop
spending any time developing SELinux and all of us Fedora users might as
well stick with the standard UNIX security system. If you find that
SELinux doesn't work in your environment due to various reasons, it is
quite easy to disable it though a much better alternative would be to
work with the RH folks to get it to work properly in your environment.
And don't forget - that may mean changing some of YOUR practices to make
it work.
--
David Hollis <dhollis(a)davehollis.com>
noon
On Thu, 2004-10-07 at 12:40, David Hollis wrote:
Not to put SELinux in bad company, but the level of security provided
by
SELinux is very similar to what is provided by the Windows NT/XP
security system and that doesn't seem to bother people too much. Of
course, MS essentially turns it off to prevent that!
AFAIK, Windows does not provide mandatory access control. ACLs != MAC.
If you find that
SELinux doesn't work in your environment due to various reasons, it is
quite easy to disable it though a much better alternative would be to
work with the RH folks to get it to work properly in your environment.
And don't forget - that may mean changing some of YOUR practices to make
it work.
Or alternatively, customize the policy to fit your needs. That is why
SELinux is flexible - because no single policy meets everyone's needs.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:11 p.m.
On Thu, 2004-10-07 at 19:00, Stephen Smalley wrote:
Or alternatively, customize the policy to fit your needs. That is
why
SELinux is flexible - because no single policy meets everyone's needs.
while that is true it sure should be possible to have a policy that can
be used by default and doesn't change existing "this works" practice.
Even if that policy allows a bit more than you would want.
12:15 p.m.
On Thu, 2004-10-07 at 13:11, Arjan van de Ven wrote:
while that is true it sure should be possible to have a policy that
can
be used by default and doesn't change existing "this works" practice.
Even if that policy allows a bit more than you would want.
Hmmm...well, what I heard one person say was "apache can read everything
the customer can write" (and possibly worse, it may have been "apache
can read or write or execute anything the customer can write"). You can
certainly adjust the apache policy to fit that model, but I doubt you
want it as the default.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
12:19 p.m.
On Thu, 2004-10-07 at 19:11 +0200, Arjan van de Ven wrote:
On Thu, 2004-10-07 at 19:00, Stephen Smalley wrote:
> Or alternatively, customize the policy to fit your needs. That is why
> SELinux is flexible - because no single policy meets everyone's needs.
while that is true it sure should be possible to have a policy that can
be used by default and doesn't change existing "this works" practice.
Even if that policy allows a bit more than you would want.
If such a policy can me made I would be happy. In the beginning I
thought SELinux sounded good, but experience with it suggests that
writing policy to such a fine-grained is just too labor intensive and
problematic.
12:55 p.m.
On Thu, 2004-10-07 at 19:11 +0200, Arjan van de Ven wrote:
On Thu, 2004-10-07 at 19:00, Stephen Smalley wrote:
> Or alternatively, customize the policy to fit your needs. That is why
> SELinux is flexible - because no single policy meets everyone's needs.
while that is true it sure should be possible to have a policy that can
be used by default and doesn't change existing "this works" practice.
Even if that policy allows a bit more than you would want.
The standard apache policy tries to capture a "typical" Apache setup.
There will always be people doing things outside these bounds; I saw a
bug report from someone who had configured Apache to load modules from
his user's home directory.
We never want SELinux to get to the point where all these weird things
people do work out of the box, because then it's equivalent to no
protection at all.
Apache is an extremely flexible piece of software. One thing I think
that's often misunderstood is that SELinux is explicitly designed to be
a layer explicitly *separate* from the Unix configuration. This does
mean you might have to configure something twice - if you want Apache to
bind on some weird port, you will have to do that both in httpd.conf and
in the SELinux policy.
But the flip side of this, and it's a very important feature I think, is
that it allows you to separate the job of administering Apache from the
system security policy. For example, with SELinux you can give someone
full access to Apache configuration *without* giving them the equivalent
of root system access. They can load any modules they want, change the
MIME setup, use mod_rewrite, whatever. But they can't use Apache to
escalate their privileges beyond what the system security policy allows.
You just can't do that with sudo or whatever.
One main point of the "The Inevitablity Of Failure" is that a
misconfigured daemon is not fundamentally different from a compromised
one.
1:52 p.m.
On Oct 7, 2004, at 18:40, David Hollis wrote:
Not to put SELinux in bad company, but the level of security provided
by
SELinux is very similar to what is provided by the Windows NT/XP
security system and that doesn't seem to bother people too much. Of
course, MS essentially turns it off to prevent that!
That's esentially wrong. Windows does support Discretionary Access
Control which, althogh it's a little bit more advanced than UNIX DAC,
it's not Mandatory Access Control. Don't get confused: SELinux is
Mandatory Access Control, while uid/gid/masks are Discretionary Access
Control.
They are such different beasts: With DAC, permissions over resources
are managed by their owners (root or users). In a MAC-based system, a
policy governs how the system security behaves, and the policy is set
up by an administrator and obeyed by everyone.
1:56 p.m.
On Thu, 2004-10-07 at 14:52, Felipe Alfaro Solana wrote:
They are such different beasts: With DAC, permissions over resources
are managed by their owners (root or users). In a MAC-based system, a
policy governs how the system security behaves, and the policy is set
up by an administrator and obeyed by everyone.
Right. Two other important differentiators between DAC and MAC beyond
the issue of administratively-defined policy include:
2) Control over all processes and objects in the system (e.g. not just
files),
3) Control based on all security-relevant information, not just user
identity (e.g. role in which the user is acting, function and
trustworthiness of the program, sensitivity/integrity of the data).
DAC cannot protect against flawed or malicious programs.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
10:30 a.m.
-----Original Message-----
From: fedora-devel-list-bounces(a)redhat.com [mailto:fedora-devel-list-
bounces(a)redhat.com] On Behalf Of Stephen Smalley
On Thu, 2004-10-07 at 14:52, Felipe Alfaro Solana wrote:
> They are such different beasts: With DAC, permissions over resources
> are managed by their owners (root or users). In a MAC-based system, a
> policy governs how the system security behaves, and the policy is set
> up by an administrator and obeyed by everyone.
Right. Two other important differentiators between DAC and MAC beyond
the issue of administratively-defined policy include:
2) Control over all processes and objects in the system (e.g. not just
files),
3) Control based on all security-relevant information, not just user
identity (e.g. role in which the user is acting, function and
trustworthiness of the program, sensitivity/integrity of the data).
DAC cannot protect against flawed or malicious programs.
This can't be stressed enough. SELinux is a disruptive technology, but it is
the first time that a security technology that solves some of the
fundamental security problems that are plaguing computers is available in a
mainstream operating system.
Karl
Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
2:20 a.m.
On Thu, 2004-10-07 at 01:24, Nathan Grennan wrote:
I don't think it is reasonable to have to relabel
every time a file is moved around to work around possible problems with
SELinux.
sounds like apache should automatically relabel or something on start.
The goal of the default selinux policy is to be invisible unless you're
an exploit. Seems like it's not ;(
3:26 a.m.
On Thu, 2004-10-07 at 09:20 +0200, Arjan van de Ven wrote:
sounds like apache should automatically relabel or something on
start.
In one of my examples I mention users uploading data via ftp, where that
is their only access. They wouldn't be able to restart httpd.
The goal of the default selinux policy is to be invisible unless
you're
an exploit. Seems like it's not ;(
Exactly.
8 a.m.
On Thu, 2004-10-07 at 03:20, Arjan van de Ven wrote:
On Thu, 2004-10-07 at 01:24, Nathan Grennan wrote:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127900
> I don't think it is reasonable to have to relabel
> every time a file is moved around to work around possible problems with
> SELinux.
sounds like apache should automatically relabel or something on start.
Consider the parallel for DAC: would you recommend having apache run
chown/chmod -R on /var/www on every start? Not a good idea for
relabeling either.
The goal of the default selinux policy is to be invisible unless
you're
an exploit. Seems like it's not ;(
Teaching users to use restorecon in the same manner as chmod/chown if
they want to export data to one of the confined services like apache is
not an undue burden. Note that SELinux isn't preventing the user from
doing what he wants; it is just preventing a confined service (apache)
from accessing a file whose protections indicate that it shouldn't be
accessible. No different than the user moving a file there without
applying chown/chmod appropriately.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
8:52 a.m.
On Thu, 07 Oct 2004 09:00:01 -0400, Stephen Smalley <sds(a)epoch.ncsc.mil> wrote:
Teaching users to use restorecon in the same manner as chmod/chown
if
they want to export data to one of the confined services like apache is
not an undue burden.
Education about needing to be aware of the contexts now is one issue,
but we are going to definitely need to expose the security context
information in the tools most people use to check file properties if
we want it to be easy to deal with. I know ls in rawhide exposes the
contexts via -Z but I haven't poked around with nautilus to see if
security context information is exposed there. And of course having
nautilus be able to run the restorecon via a right click menu entry on
a directory or file is going to be needed for smooth operation for a
segment of the userbase.
And are there any tools aimed at helping users figure out what file
security context settings are needed for specific service/daemons?
-jef
9:01 a.m.
--On Thursday, October 07, 2004 9:52 AM -0400 Jeff Spaleta
<jspaleta(a)gmail.com> wrote:
I know ls in rawhide exposes the
contexts via -Z but I haven't poked around with nautilus to see if
security context information is exposed there. And of course having
nautilus be able to run the restorecon via a right click menu entry on
a directory or file is going to be needed for smooth operation for a
segment of the userbase.
And are there any tools aimed at helping users figure out what file
security context settings are needed for specific service/daemons?
Also, does find have facilities to match security contexts? It's a common
tool for finding violations of other policies, like rogue suid binaries.
9:23 a.m.
On Thu, 2004-10-07 at 10:01, Kenneth Porter wrote:
Also, does find have facilities to match security contexts? It's
a common
tool for finding violations of other policies, like rogue suid binaries.
find /etc -context system_u:object_r:shadow_t -print
find /etc -printf "%p %Z\n"
But a better tool for this purpose is likely setfiles, e.g.:
/usr/sbin/setfiles -qnv /etc/selinux/targeted/contexts/files/file_contexts /etc
/sbin/fixfiles check is similar, but seems to only log to a file
(fixfiles is a script written by RedHat that calls setfiles internally).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
9:16 a.m.
On Thu, 2004-10-07 at 09:52, Jeff Spaleta wrote:
Education about needing to be aware of the contexts now is one
issue,
but we are going to definitely need to expose the security context
information in the tools most people use to check file properties if
we want it to be easy to deal with. I know ls in rawhide exposes the
contexts via -Z but I haven't poked around with nautilus to see if
security context information is exposed there. And of course having
nautilus be able to run the restorecon via a right click menu entry on
a directory or file is going to be needed for smooth operation for a
segment of the userbase.
Good ideas, please submit an RFE. AFAIK, nautilus doesn't know about
security contexts at all.
And are there any tools aimed at helping users figure out what file
security context settings are needed for specific service/daemons?
Ideally, they only need to run restorecon on the path, and restorecon
will fetch the proper security context from the file_contexts
configuration and apply it.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
9:25 a.m.
Once upon a time, Stephen Smalley <sds(a)epoch.ncsc.mil> said:
> The goal of the default selinux policy is to be invisible unless
you're
> an exploit. Seems like it's not ;(
Teaching users to use restorecon in the same manner as chmod/chown if
they want to export data to one of the confined services like apache is
not an undue burden.
Lots of web users use FTP to upload files. FTP has a chmod command; it
does not have commands to alter SELinux labels (and even if such
commands were added, you aren't liable to get WSFTP and such to change
just to support a few Linux servers).
Not all users have shell access either.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:27 a.m.
On Thu, 2004-10-07 at 10:25, Chris Adams wrote:
Lots of web users use FTP to upload files. FTP has a chmod command;
it
does not have commands to alter SELinux labels (and even if such
commands were added, you aren't liable to get WSFTP and such to change
just to support a few Linux servers).
Not all users have shell access either.
If they upload to the right location in the first place, then they
likely won't have a problem - the new files will inherit the security
context of the parent directory. It is only when they upload to a
location with different protection defaults and then move to the new
location. Even copying would work fine, as noted, as it doesn't
preserve protections by default unless you specify the corresponding
option.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
10:12 a.m.
--On Thursday, October 07, 2004 10:27 AM -0400 Stephen Smalley
<sds(a)epoch.ncsc.mil> wrote:
> Not all users have shell access either.
If they upload to the right location in the first place, then they
likely won't have a problem - the new files will inherit the security
context of the parent directory. It is only when they upload to a
location with different protection defaults and then move to the new
location. Even copying would work fine, as noted, as it doesn't
preserve protections by default unless you specify the corresponding
option.
Does FTP support moving? If not, then the issue of not having shell access
goes away, because the user can't upload and then move.
10:30 a.m.
Once upon a time, Kenneth Porter <shiva(a)sewingwitch.com> said:
Does FTP support moving? If not, then the issue of not having shell
access
goes away, because the user can't upload and then move.
Yes, FTP has a "rename" command (well, pair of commands actually, RNFR
<oldname> and then RNTO <newname>) that will move a file. I think it
works like the rename() system call (i.e. not across filesystems), but
I'm not sure (that may be FTP server specific). I'm pretty sure that
the popular Windows FTP clients like WSFTP allow you to "drag and drop"
files from one directory to another on the server and use the rename
commands. SFTP has the same issue (it has a rename command as well).
We sell web hosting, and believe me, customers will upload their files
to just about anywhere on the server they have write access (and they'll
try other places without knowing why). Shared web hosting is a perfect
environment for SELinux, but this would be a killer. Explaining that
their CGIs have to have execute permission is hard enough.
Also, as someone else mentioned, people do intentionally upload things
in one place (out of the web directory) and then move them into place
after the upload is complete. This is especially common when uploading
a whole new version of a site.
I would love to say "use something else" or "only do it this way" but
that isn't practical as a web hosting seller. If you tell customers
things like that, they go elsewhere.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
10:52 a.m.
On Thu, 2004-10-07 at 10:30 -0500, Chris Adams wrote:
We sell web hosting, and believe me, customers will upload their
files
to just about anywhere on the server they have write access (and they'll
try other places without knowing why). Shared web hosting is a perfect
environment for SELinux, but this would be a killer. Explaining that
their CGIs have to have execute permission is hard enough.
I think that explaining what your users need to do for SELinux in this
case is quite similar to explaining execute permissions.
CGI scripts for example in the default Apache policy need to be
httpd_user_script_exec_t. CGI script data needs to be
httpd_user_script_ro_t or httpd_user_script_rw_t. There's no way for
SELinux to automatically guess what data you want writable by the CGI
and what you don't.
You simply need to have users be aware of chcon -t if you want the
additional security. Although:
Also, as someone else mentioned, people do intentionally upload
things
in one place (out of the web directory) and then move them into place
after the upload is complete. This is especially common when uploading
a whole new version of a site.
There could be higher level tools built here that would automatically
set corresponding types when a new site is uploaded. You'd have your
users upload their website into a "staging" area, and then a cron job
would move it into place atomically and relabel it as necessary.
I think it'd also be very useful to have tools that parsed the SELinux
audit logs and warned an administrator if a user's web site seemed not
to be set up correctly; you could even have it automatically relabel
there too, but there are tradeoffs.
11:36 a.m.
On Thu, Oct 07, 2004 at 11:52:09AM -0400, Colin Walters wrote:
On Thu, 2004-10-07 at 10:30 -0500, Chris Adams wrote:
> We sell web hosting, and believe me, customers will upload their files
> to just about anywhere on the server they have write access (and they'll
> try other places without knowing why). Shared web hosting is a perfect
> environment for SELinux, but this would be a killer. Explaining that
> their CGIs have to have execute permission is hard enough.
I think that explaining what your users need to do for SELinux in this
case is quite similar to explaining execute permissions.
CGI scripts for example in the default Apache policy need to be
httpd_user_script_exec_t. CGI script data needs to be
httpd_user_script_ro_t or httpd_user_script_rw_t. There's no way for
SELinux to automatically guess what data you want writable by the CGI
and what you don't.
You simply need to have users be aware of chcon -t if you want the
additional security. Although:
That's surely not the whole story if SELinux is on by default and Apache
is covered by the targetted policy. The fact seems to be that you have
to know and understand SELinux to be able to do the normal things you do
with Apache, e.g. write CGI scripts, or change httpd.conf. I can't help
thinking this will be a large source of user confusion.
And the stderr-eating behaviour is very annoying.
# service httpd configtest
#
... should print "OK".
joe
1:02 p.m.
On Thu, 2004-10-07 at 17:36 +0100, Joe Orton wrote:
That's surely not the whole story if SELinux is on by default and
Apache
is covered by the targetted policy. The fact seems to be that you have
to know and understand SELinux to be able to do the normal things you do
with Apache, e.g. write CGI scripts, or change httpd.conf. I can't help
thinking this will be a large source of user confusion.
That's absolutely true. We're trying to fundamentally improve Linux
security here, and people will have to learn new things. But with the
targeted policy and boolean support, it's also extremely easy to turn
off enforcement just for Apache if you like; run system-config-
securitylevel or setsebool httpd_disable_trans true. Yet another
alternative is to just run in permissive mode and figure out what you
need to change to alter the policy for your needs.
3:33 p.m.
On Thu, 2004-10-07 at 17:36 +0100, Joe Orton wrote:
That's surely not the whole story if SELinux is on by default and
Apache
is covered by the targetted policy. The fact seems to be that you have
to know and understand SELinux to be able to do the normal things you do
with Apache, e.g. write CGI scripts, or change httpd.conf.
Following up on this a bit - it would be possible to weaken the Apache
policy so that there are not separate types for user versus system
content, or CGI script executables versus CGI data. You'd just have a
single type, httpd_content_t. Then an administrator wouldn't have to
know how to run chcon to relabel executable CGI scripts or mark data as
readonly by the CGI script.
However, you lose a number of advantages of the normal Apache policy,
such as compromised (or misconfigured) CGI scripts not being able to
delete your entire website.
11:38 a.m.
On Thu, Oct 07, 2004 at 04:33:34PM -0400, Colin Walters wrote:
On Thu, 2004-10-07 at 17:36 +0100, Joe Orton wrote:
> That's surely not the whole story if SELinux is on by default and Apache
> is covered by the targetted policy. The fact seems to be that you have
> to know and understand SELinux to be able to do the normal things you do
> with Apache, e.g. write CGI scripts, or change httpd.conf.
Following up on this a bit - it would be possible to weaken the Apache
policy so that there are not separate types for user versus system
content, or CGI script executables versus CGI data. You'd just have a
single type, httpd_content_t. Then an administrator wouldn't have to
know how to run chcon to relabel executable CGI scripts or mark data as
readonly by the CGI script.
I'm just not convinced it's the right decision to apply SELinux policy
to Apache *by default*. New administrators have enough problems trying
to configure stuff as it is, without placing this invisible tripwire in
front of them.
It won't endear people to FC3 as a good web server platform if the PHP,
CGI scripts etc, hell, even running httpd -t "just doesn't work" out of
the box when it did in past releases. They will go back to "chuck away
the packaged stuff and build from sources" as that'll be the first thing
people will tell them when they ask the mailing lists and IRC channels.
joe
11:58 a.m.
On Fri, 8 Oct 2004 17:38:37 +0100, Joe Orton <jorton(a)redhat.com> wrote:
On Thu, Oct 07, 2004 at 04:33:34PM -0400, Colin Walters wrote:
> On Thu, 2004-10-07 at 17:36 +0100, Joe Orton wrote:
>
> > That's surely not the whole story if SELinux is on by default and Apache
> > is covered by the targetted policy. The fact seems to be that you have
> > to know and understand SELinux to be able to do the normal things you do
> > with Apache, e.g. write CGI scripts, or change httpd.conf.
>
> Following up on this a bit - it would be possible to weaken the Apache
> policy so that there are not separate types for user versus system
> content, or CGI script executables versus CGI data. You'd just have a
> single type, httpd_content_t. Then an administrator wouldn't have to
> know how to run chcon to relabel executable CGI scripts or mark data as
> readonly by the CGI script.
I'm just not convinced it's the right decision to apply SELinux policy
to Apache *by default*. New administrators have enough problems trying
to configure stuff as it is, without placing this invisible tripwire in
front of them.
It won't endear people to FC3 as a good web server platform if the PHP,
CGI scripts etc, hell, even running httpd -t "just doesn't work" out of
the box when it did in past releases. They will go back to "chuck away
the packaged stuff and build from sources" as that'll be the first thing
people will tell them when they ask the mailing lists and IRC channels.
They can also install everything as setuid and root.. and give someone
the root password to help them set it up.. if they listen to the wrong
people on mailling lists and IRC channels.
People can also just turn off selinux with a one liner and a reboot if
they dont have the time, inclination, or energy to learn a new
security mechanism.
--
Stephen J Smoogen.
Professional System Administrator
12:13 p.m.
On Fri, 2004-10-08 at 10:58 -0600, Stephen J. Smoogen wrote:
People can also just turn off selinux with a one liner and a reboot
if
they dont have the time, inclination, or energy to learn a new
security mechanism.
Far better to just disable protection for Apache using
system-config-securitylevel.
12:07 p.m.
On Fri, 2004-10-08 at 17:38 +0100, Joe Orton wrote:
I'm just not convinced it's the right decision to apply
SELinux policy
to Apache *by default*. New administrators have enough problems trying
to configure stuff as it is,
I agree, Apache is a very complex daemon, with a lot of configuration
possibilities. That is a very good reason for applying SELinux policy,
since the policy prevents a misconfigured or compromised apache from
damaging your system.
without placing this invisible tripwire in
front of them.
When people get permission denials, they will likely know to look in
both /var/log/httpd/error_log; we just need to get people to know to
look in /var/log/messages as well.
It won't endear people to FC3 as a good web server platform if
the PHP,
CGI scripts etc,
With a weakened Apache policy, these should generally require no
configuration. But it will give less protection as well.
hell, even running httpd -t "just doesn't work"
True. But really, the syntax parsing should be a separate application.
If the policy allowed the regular daemon access to the system
administrator's terminal, then it could take over an existing root
shell.
out of
the box when it did in past releases. They will go back to "chuck away
the packaged stuff and build from sources"
That's bad advice. First of all, if they really want, they can disable
enforcement just for Apache quite easily, as has been mentioned earlier.
Second of all, reinstalling from sources will not be a reliable means to
disable SELinux protection for Apache. It might work because the new
binaries will inherit the generic sbin_t type, and so no transition will
occur. But if the system is later relabeled, those files could be reset
to the httpd_exec_t type, and then the transition will happen again.
9:44 a.m.
On Thu, Oct 07, 2004 at 09:25:26AM -0500, Chris Adams wrote:
Lots of web users use FTP to upload files. FTP has a chmod command;
it
does not have commands to alter SELinux labels (and even if such
commands were added, you aren't liable to get WSFTP and such to change
just to support a few Linux servers).
Not all users have shell access either.
Switch to DAV maybe?
FTP sucks for all sorts of other reasons... :-)
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
9:52 a.m.
New subject: DAV
Steven Pritchard wrote:
On Thu, Oct 07, 2004 at 09:25:26AM -0500, Chris Adams wrote:
>Lots of web users use FTP to upload files. FTP has a chmod command; it
>does not have commands to alter SELinux labels (and even if such
>commands were added, you aren't liable to get WSFTP and such to change
>just to support a few Linux servers).
>
>Not all users have shell access either.
Switch to DAV maybe?
I have yet to find any usable DAV client/server implementations for
linux (though I admit that I haven't looked *that* hard) that support
~user directories.
-- Rex
10:49 a.m.
New subject: DAV
On Thu, Oct 07, 2004 at 09:52:33AM -0500, Rex Dieter wrote:
Steven Pritchard wrote:
>On Thu, Oct 07, 2004 at 09:25:26AM -0500, Chris Adams wrote:
>
>>Lots of web users use FTP to upload files. FTP has a chmod command; it
>>does not have commands to alter SELinux labels (and even if such
>>commands were added, you aren't liable to get WSFTP and such to change
>>just to support a few Linux servers).
>>
>>Not all users have shell access either.
>
>
>Switch to DAV maybe?
I have yet to find any usable DAV client/server implementations for
linux (though I admit that I haven't looked *that* hard) that support
~user directories.
The *client* doesn't care about ~user directories. Having a DAV server
which can manipulate files in ~user directories under ownership of said
user requires running the server as root, which is really not something
you want to do.
joe
10:55 a.m.
New subject: DAV
Joe Orton wrote:
On Thu, Oct 07, 2004 at 09:52:33AM -0500, Rex Dieter wrote:
>I have yet to find any usable DAV client/server implementations
for
>linux (though I admit that I haven't looked *that* hard) that support
>~user directories.
The *client* doesn't care about ~user directories. Having a DAV server
which can manipulate files in ~user directories under ownership of said
user requires running the server as root, which is really not something
you want to do.
So, my point is validated? DAV and ~user directories don't mix?
-- Rex
10:57 a.m.
New subject: DAV
On Thu, Oct 07, 2004 at 04:49:10PM +0100, Joe Orton wrote:
The *client* doesn't care about ~user directories. Having a DAV
server
which can manipulate files in ~user directories under ownership of said
user requires running the server as root, which is really not something
you want to do.
Your apache needs to have setfsuid rights, that is all
11:41 a.m.
New subject: DAV
On Thu, Oct 07, 2004 at 11:57:27AM -0400, Alan Cox wrote:
On Thu, Oct 07, 2004 at 04:49:10PM +0100, Joe Orton wrote:
> The *client* doesn't care about ~user directories. Having a DAV server
> which can manipulate files in ~user directories under ownership of said
> user requires running the server as root, which is really not something
> you want to do.
Your apache needs to have setfsuid rights, that is all
Are you talking about capabilities or SELinux policy there? Does the
capability bit not then allow children to setfsuid(0) and write files as
root?
joe
11:51 a.m.
New subject: DAV
On Thu, Oct 07, 2004 at 05:41:38PM +0100, Joe Orton wrote:
> Your apache needs to have setfsuid rights, that is all
Are you talking about capabilities or SELinux policy there? Does the
capability bit not then allow children to setfsuid(0) and write files as
root?
You have control over how its inherited depending on whether you admit to
being capability aware or not. In the sane case you'd turn it off when
execing just as you make sure files all get closed.
Alan
1:58 p.m.
New subject: DAV
On Thu, Oct 07, 2004 at 12:51:36PM -0400, Alan Cox wrote:
On Thu, Oct 07, 2004 at 05:41:38PM +0100, Joe Orton wrote:
> > Your apache needs to have setfsuid rights, that is all
>
> Are you talking about capabilities or SELinux policy there? Does the
> capability bit not then allow children to setfsuid(0) and write files as
> root?
You have control over how its inherited depending on whether you admit to
being capability aware or not. In the sane case you'd turn it off when
execing just as you make sure files all get closed.
It's not CGI scripts which is the issue, the issue is whether or not an
OpenSSL buffer overflow gives you remote root or just the privileges of
the "apache" user as it currently does.
joe
2:04 p.m.
New subject: DAV
On Thu, Oct 07, 2004 at 07:58:20PM +0100, Joe Orton wrote:
It's not CGI scripts which is the issue, the issue is whether or
not an
OpenSSL buffer overflow gives you remote root or just the privileges of
the "apache" user as it currently does.
That would be a problem yes. You'd end up with apache able to access any
files in the system. I guess mod_webdav should never have been mod_
2:14 p.m.
New subject: DAV
On Thu, 2004-10-07 at 15:04 -0400, Alan Cox wrote:
On Thu, Oct 07, 2004 at 07:58:20PM +0100, Joe Orton wrote:
> It's not CGI scripts which is the issue, the issue is whether or not an
> OpenSSL buffer overflow gives you remote root or just the privileges of
> the "apache" user as it currently does.
That would be a problem yes. You'd end up with apache able to access any
files in the system. I guess mod_webdav should never have been mod_
Definitely agreed there. It should work like ssh+sftp, where ssh execs
a helper program running under the user's uid. Doing things this way,
in a separate process, also allows the SELinux policy to confine them
separately.
5:03 p.m.
New subject: DAV
On Thu, Oct 07, 2004 at 03:14:23PM -0400, Colin Walters wrote:
On Thu, 2004-10-07 at 15:04 -0400, Alan Cox wrote:
> On Thu, Oct 07, 2004 at 07:58:20PM +0100, Joe Orton wrote:
> > It's not CGI scripts which is the issue, the issue is whether or not an
> > OpenSSL buffer overflow gives you remote root or just the privileges of
> > the "apache" user as it currently does.
>
> That would be a problem yes. You'd end up with apache able to access any
> files in the system. I guess mod_webdav should never have been mod_
Definitely agreed there. It should work like ssh+sftp, where ssh execs
a helper program running under the user's uid. Doing things this way,
in a separate process, also allows the SELinux policy to confine them
separately.
I don't see how this makes sense with HTTP. The code with the buffer
overflows is the HTTP parsing and SSL handling. THat's also the code
which you must trust to determine what "user context" a request might be
for.
joe
5:51 p.m.
New subject: DAV
On Thu, Oct 07, 2004 at 11:03:53PM +0100, Joe Orton wrote:
I don't see how this makes sense with HTTP. The code with the
buffer
overflows is the HTTP parsing and SSL handling. THat's also the code
which you must trust to determine what "user context" a request might be
A samba like httpd would take the first request running as a non-user with just
some basic auth rights and if neccessary start a server as that user via
a priviledged single purpose helper. It would then hand the socket to that
process (or could use http redirects except some DAV clients shit themselves
when this occurs)
Architecture is easy here, code is another matter !
11:23 a.m.
Hi.
Steven Pritchard <steve(a)silug.org> wrote:
Switch to DAV maybe?
FTP sucks for all sorts of other reasons... :-)
If it takes selinux to make ftp go away, I'm all for it.
--
Dare to slack: When birds fly in the right formation, they need only exert
half the effort. Even in nature, teamwork results in collective lazyness.
-- Despair Inc. calendar, May 2001
10:54 a.m.
On Thu, 2004-10-07 at 09:25 -0500, Chris Adams wrote:
Once upon a time, Stephen Smalley <sds(a)epoch.ncsc.mil> said:
> > The goal of the default selinux policy is to be invisible unless you're
> > an exploit. Seems like it's not ;(
>
> Teaching users to use restorecon in the same manner as chmod/chown if
> they want to export data to one of the confined services like apache is
> not an undue burden.
Lots of web users use FTP to upload files. FTP has a chmod command; it
does not have commands to alter SELinux labels
Yes, that is a problem. Ideally we would get such support added.
Having SELinux support in the kernel and a few core utilities is only
the beginning - I'd like to see support for SELinux throughout all the
Linux tools, and for it to become as standard a part of Linux security
as the normal DAC is. With the default targeted policy I think we're on
the right path.
7178
days inactive
7180
days old
56 comments
18 participants
participants (18)
-
Alan Cox -
Arjan van de Ven -
Chris Adams -
Colin Walters -
David Hollis -
Felipe Alfaro Solana -
Jef Spaleta -
Joe Orton -
Karl MacMillan -
Kenneth Porter -
Nathan Grennan -
Ralf Ertzinger -
Rex Dieter -
Sean Middleditch -
Stephen John Smoogen -
Stephen Smalley -
Steve G -
Steven Pritchard