On Mar 5, 2008, at 9:32 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ronald van den Blink wrote:
On Mar 5, 2008, at 5:43 PM, Christopher J. PeBenito wrote:
On Wed, 2008-03-05 at 17:16 +0100, Ronald van den Blink wrote:
On Mar 5, 2008, at 5:05 PM, Christopher J. PeBenito wrote:
On Wed, 2008-03-05 at 16:47 +0100, selinux@xxxxxx wrote:
Unfortunately there are 3 forces at work. The first is that
for the
most part, ports should always be labeled, because, for example,
port 80
is always going to be regarded as the http port. The second
is that
thats not always the case for non well-defined ports (your
situation).
The third is that portcons (the port labeling statements) only
work in
the base module. So, though we want to make a happy medium
between the
first two, we can't overcome the final one within the
constraints
of the
current toolchain.
Agree with that. But wouldn't the situation be a little less
complicated
if you decide not to define any ports above 1024 in the reference
policy?
That breaks people that just want to use reference policy.
Does this mean that any module in the refpol that needs (for
instance)
port 8080 but isn't a http-cache-daemon uses
corenetwork_httpd_cache
and get's all the other ports defined there as well? Isn't that
breaking the least priviliges idea? Because you're opening up more
ports then needed?
It depends on how far you want/need to take least privilege. By
this
argument, having all of the shared libraries in /lib and /usr/lib
being
the same label would be bad. You have to evaluate the impact on
your
security goals.
Well, that's exactly the reason why we choose not to label the
libraries
in /opt/jboss/lib (or whatever the exact place is) lib_t but
jboss_lib_t, we don't want those lib's to be shared. In our view it
is a
security risk to declare a range of (unprivileged) ports as (in our
case) http_cache and use them for just one of the ports ;) But,
that's
just one of the reasons. We are still wondering if it is a good
approach
to stop declaring ports > 1024 in corenetwork and make a generic
handler
so modules can create ports > 1024 on the fly if needed.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
--
This message was distributed to subscribers of the selinux mailing
list.
If you no longer wish to subscribe, send mail to
majordomo@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx
with
the words "unsubscribe selinux" without quotes as the message.
I like Stephen suggestion of removing corenetwork ports altogether is
defining them via semanage. This would allow flexibility where a user
wants to allow apache to listen on a special port but not port 80.
Currently you can not remove a port that is defined in corenetwork.
The problem with removing corenetwork and adding all the ports via
semanage would take a very long time with the current tool chain.
I think that that is definitely a better way of working then the way
we do it right now. If we choose this (semanage) as the way to go you
give people more flexibility and security.
How much work has to be done if this is the change we want?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
