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.
