Unreserved portnumbers in corenetwork

Unreserved portnumbers in corenetwork

[selinux]

Gents,

We're building a policy for JBoss. Jboss uses atleast port 8080 and 8083.
Besides this, the application we use on JBoss also opens port 8443 (https)

While building the jboss-module we ofcourse want to claim these ports and
patch corenetwork. However, this is where our problem arises; HTTP has
claimed some of the ports we need and http-cache has claimed 8080
allready.

But http and http-cache allow to open more ports (80, 443, 488, 8008,
8009) than we really need. We think this is against the SElinux policy of
least privilege.

So how do we deal with these kinds of port conflicts? Maybe corenetwork
isn't the best place to define unreserved (> 1024) ports?

Cheers,

Bart


--
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: Unreserved portnumbers in corenetwork

[Christopher J. PeBenito]

On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
> We're building a policy for JBoss. Jboss uses atleast port 8080 and 8083.
> Besides this, the application we use on JBoss also opens port 8443 (https)
> 
> While building the jboss-module we ofcourse want to claim these ports and
> patch corenetwork. However, this is where our problem arises; HTTP has
> claimed some of the ports we need and http-cache has claimed 8080
> allready.
> 
> But http and http-cache allow to open more ports (80, 443, 488, 8008,
> 8009) than we really need. We think this is against the SElinux policy of
> least privilege.
> 
> So how do we deal with these kinds of port conflicts? Maybe corenetwork
> isn't the best place to define unreserved (> 1024) ports?

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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[selinux]

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

If you decide to do that, you could create a portcon that allows a single
active module to claim a port above 1024 on a per module basis. A second
module could claim another one, as long as it's not equal to the first
(active) one.

In this way you create a generic handler for modules that need ports above
1024 and can create a reference policy with modules with the same ports.
As long as they are not both active, you wouldn't have any problem.




--
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: Unreserved portnumbers in corenetwork

[Christopher J. PeBenito]

On Wed, 2008-03-05 at 16:47 +0100, selinux@a61.nl 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.

> If you decide to do that, you could create a portcon that allows a single
> active module to claim a port above 1024 on a per module basis. A second
> module could claim another one, as long as it's not equal to the first
> (active) one.
> 
> In this way you create a generic handler for modules that need ports above
> 1024 and can create a reference policy with modules with the same ports.
> As long as they are not both active, you wouldn't have any problem.

If I understand what your suggesting, then I don't see how thats
implementable with the current toolchain.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[Ronald van den Blink]

On Mar 5, 2008, at 5:05 PM, Christopher J. PeBenito wrote:

> On Wed, 2008-03-05 at 16:47 +0100, selinux@a61.nl 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?

>> If you decide to do that, you could create a portcon that allows a  
>> single
>> active module to claim a port above 1024 on a per module basis. A  
>> second
>> module could claim another one, as long as it's not equal to the  
>> first
>> (active) one.
>>
>> In this way you create a generic handler for modules that need  
>> ports above
>> 1024 and can create a reference policy with modules with the same  
>> ports.
>> As long as they are not both active, you wouldn't have any problem.
>
> If I understand what your suggesting, then I don't see how thats
> implementable with the current toolchain.
>
No it's not possible in the current toolchain, that's true. What we're  
suggesting is to make the reference policy more modulair by making  
ports <1024  available in corenetworks and providing ports > 1024 with  
a different handler.

Right now the reference policy is forcing module makers to give to  
much privileges (i.e. open up more ports then needed) or to edit the  
reference policy if they want to give exactly perfect privileges. This  
will in the end provide a security risk (if jboss get's exploited  
there are much to many ports open).

The ideal situation is that no port higher then 1024 is defined in  
corenetwork (in my opinion off course).


> -- 
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[Christopher J. PeBenito]

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@a61.nl 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.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[Ronald van den Blink]

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@a61.nl 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@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: Unreserved portnumbers in corenetwork

[Daniel J Walsh]

-----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@a61.nl 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@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.
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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfPA00ACgkQrlYvE4MpobNZ/ACgp8rwt081wACa3rfCWmyU5JJe
mfMAoNI9D8LA8pNCXQdv0DVEbirdvy+D
=9z2s
-----END PGP SIGNATURE-----

--
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: Unreserved portnumbers in corenetwork

[Stephen Smalley]

On Wed, 2008-03-05 at 15:32 -0500, 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@a61.nl 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@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.
> 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.

Should be a simple extension to semanage front end to take a set of port
contexts and update them in a single libsemanage transaction.  Just like
semodule lets you insert a set of modules together in a single
transaction.

-- 
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: Unreserved portnumbers in corenetwork

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Smalley wrote:
> On Wed, 2008-03-05 at 15:32 -0500, 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@a61.nl 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@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.
>> 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.
> 
> Should be a simple extension to semanage front end to take a set of port
> contexts and update them in a single libsemanage transaction.  Just like
> semodule lets you insert a set of modules together in a single
> transaction.
> 
Of course we have other problems.  How do you handle update?

Currently we just allow corenetwork to update all the ports.  But if we
move all the ports to semanage and out of the base policy, we have to
maintain the fact that a user removed port 8080 from http_port_t.

For example.

User installs SELinux rpm which includes a list of all defined ports.
semanage adds them.

A user decides he no longer wants to allow httpd_port_t to listen on
port 80.

semanage port -d 80

Later selinux policy is updated.

How do we stop the update procedure from re-adding port 80?

Another problem is we use the same types for both name_bind and
name_connect.

So if the user does not want to allow httpd_t to listen on port 80, and
we allow him to remove it, his confined firefox and squid will now not
be allowed to connect to port 80.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfPFhYACgkQrlYvE4MpobN+8gCgwIY0FwsdPPvy9O6fyT7LCoMi
CgsAoIt19/8cljfVolMGIxj9p+Cg7nlv
=h3k/
-----END PGP SIGNATURE-----

--
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: Unreserved portnumbers in corenetwork

[Joe Nall]

Why not just decouple the ports from the application by giving them  
names like port8080_t? This would allow multiple policies to be  
written to manage that resource, only one of which should be active at  
a time.  I think the real issue is the assumption that only one  
application will own ports like 80, 8080, 443 and 8443.

joe

--
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: Unreserved portnumbers in corenetwork

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joe Nall wrote:
> Why not just decouple the ports from the application by giving them
> names like port8080_t? This would allow multiple policies to be written
> to manage that resource, only one of which should be active at a time. 
> I think the real issue is the assumption that only one application will
> own ports like 80, 8080, 443 and 8443.
> 
> joe
I think the problem here is 65000 types.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfP/U8ACgkQrlYvE4MpobOkSACeO4El2XE56Vdunau/rTpggGjH
y3gAoMZ3c2QBfO37XKZg5p6jGUt5an/D
=UUGs
-----END PGP SIGNATURE-----

--
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: Unreserved portnumbers in corenetwork

[Joe Nall]

On Mar 6, 2008, at 8:18 AM, Daniel J Walsh wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Joe Nall wrote:
>> Why not just decouple the ports from the application by giving them
>> names like port8080_t? This would allow multiple policies to be  
>> written
>> to manage that resource, only one of which should be active at a  
>> time.
>> I think the real issue is the assumption that only one application  
>> will
>> own ports like 80, 8080, 443 and 8443.
>>
>> joe
> I think the problem here is 65000 types.


I was not suggesting preassigning all 65k ports by number, although  
the auto decl trick used to generate the mls sensitivities could do it  
in a few lines, but just to those ports which have many uses in the  
real world.

In the current fedora policy, the http related ports are all enumerated

find . -name \*.te -exec grep portcon {} /dev/null \; | grep http
./modules/kernel/corenetwork.te:portcon tcp 3128  
gen_context(system_u:object_r:http_cache_port_t,s0)
./modules/kernel/corenetwork.te:portcon udp 3130  
gen_context(system_u:object_r:http_cache_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 8080  
gen_context(system_u:object_r:http_cache_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 8118  
gen_context(system_u:object_r:http_cache_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 80  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 443  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 488  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 8008  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 8009  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 8443  
gen_context(system_u:object_r:http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 5988  
gen_context(system_u:object_r:pegasus_http_port_t,s0)
./modules/kernel/corenetwork.te:portcon tcp 5989  
gen_context(system_u:object_r:pegasus_https_port_t,s0)

The problem with 443 and 8443 being the same type is that they are  
often used by different applications on the same machine (httpd,  
tomcat) with different security requirements. 8080 and 8443 are very  
often the same application(JBoss, tomcat), but have different port  
types.

joe


--
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: Unreserved portnumbers in corenetwork

[Ronald van den Blink]

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@a61.nl 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@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.
> 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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ronald van den Blink wrote:
> 
> 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@a61.nl 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@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.
>> 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?
We could extend semanage to read a file

semanage port -a --input=portsfile


Where ports file looks like

- -t httpd_port_t -P tcp 80
- -t httpd_port_t -P tcp 8080
...


Which is fairly easy.  But extracting this data from policy would be
fairly difficult.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfPELcACgkQrlYvE4MpobMTlwCdFl7gPb10Y0sVJGe/DoUKKP78
d78AoIAzKJdI9cg/n9LpTEVwjjUTrvMZ
=P4Qk
-----END PGP SIGNATURE-----

--
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: Unreserved portnumbers in corenetwork

[Stephen Smalley]

On Wed, 2008-03-05 at 10:24 -0500, Christopher J. PeBenito wrote:
> On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
> > We're building a policy for JBoss. Jboss uses atleast port 8080 and 8083.
> > Besides this, the application we use on JBoss also opens port 8443 (https)
> > 
> > While building the jboss-module we ofcourse want to claim these ports and
> > patch corenetwork. However, this is where our problem arises; HTTP has
> > claimed some of the ports we need and http-cache has claimed 8080
> > allready.
> > 
> > But http and http-cache allow to open more ports (80, 443, 488, 8008,
> > 8009) than we really need. We think this is against the SElinux policy of
> > least privilege.
> > 
> > So how do we deal with these kinds of port conflicts? Maybe corenetwork
> > isn't the best place to define unreserved (> 1024) ports?
> 
> 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.

Perhaps all port context definitions should be moved to being handled
via semanage port?  Doesn't brickwall do something similar?

-- 
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: Unreserved portnumbers in corenetwork

[Christopher J. PeBenito]

On Wed, 2008-03-05 at 10:51 -0500, Stephen Smalley wrote:
> On Wed, 2008-03-05 at 10:24 -0500, Christopher J. PeBenito wrote:
> > On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
> > > We're building a policy for JBoss. Jboss uses atleast port 8080 and 8083.
> > > Besides this, the application we use on JBoss also opens port 8443 (https)
> > > 
> > > While building the jboss-module we ofcourse want to claim these ports and
> > > patch corenetwork. However, this is where our problem arises; HTTP has
> > > claimed some of the ports we need and http-cache has claimed 8080
> > > allready.
> > > 
> > > But http and http-cache allow to open more ports (80, 443, 488, 8008,
> > > 8009) than we really need. We think this is against the SElinux policy of
> > > least privilege.
> > > 
> > > So how do we deal with these kinds of port conflicts? Maybe corenetwork
> > > isn't the best place to define unreserved (> 1024) ports?
> > 
> > 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.
> 
> Perhaps all port context definitions should be moved to being handled
> via semanage port?

I don't think we actually need to move anything, we just have to allow
semanage to delete port labelings, since it can already add and modify
them.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Unreserved portnumbers in corenetwork

[Ronald van den Blink]

On Mar 6, 2008, at 2:37 PM, Christopher J. PeBenito wrote:

> On Wed, 2008-03-05 at 10:51 -0500, Stephen Smalley wrote:
>> On Wed, 2008-03-05 at 10:24 -0500, Christopher J. PeBenito wrote:
>>> On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
>>>> We're building a policy for JBoss. Jboss uses atleast port 8080  
>>>> and 8083.
>>>> Besides this, the application we use on JBoss also opens port  
>>>> 8443 (https)
>>>>
>>>> While building the jboss-module we ofcourse want to claim these  
>>>> ports and
>>>> patch corenetwork. However, this is where our problem arises;  
>>>> HTTP has
>>>> claimed some of the ports we need and http-cache has claimed 8080
>>>> allready.
>>>>
>>>> But http and http-cache allow to open more ports (80, 443, 488,  
>>>> 8008,
>>>> 8009) than we really need. We think this is against the SElinux  
>>>> policy of
>>>> least privilege.
>>>>
>>>> So how do we deal with these kinds of port conflicts? Maybe  
>>>> corenetwork
>>>> isn't the best place to define unreserved (> 1024) ports?
>>>
>>> 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.
>>
>> Perhaps all port context definitions should be moved to being handled
>> via semanage port?
>
> I don't think we actually need to move anything, we just have to allow
> semanage to delete port labelings, since it can already add and modify
> them.

Can I take the fast-lane by saying that we agree on the fact that  
something needs to be done to make it more flexible? And if the answer  
is yes, what is the consensus right now? Is it likely to assume that  
semanage is being allowed to delete port labelings?

And if we take that approach, aren't we still seeing the issue that  
someone has to decide which port-number is assigned to which  
applications for starters? Because I can see a issue here when new  
policy writers are creating policies and choosing "just to use  
http_cache because my port-number is in that range" and opening up to  
many ports.

Just to make the discussion a little bit bigger, if we speak of least  
privileged, why are we making general lib_t, usr_t etc.? Aren't we  
making a hole in our security model right then, because of giving to  
much read privileges by saying that everyone has to be able to read in  
lib_t? So actually giving app X read rights to the lib_t's of app Y?  
Of course you have to give access to lib_t first, but after that every  
lib_t labeled file is free to read. Or are we seeing things wrong.

If we are right, why aren't we just creating appX_lib_t and appY_lib_t  
(the way we are doing in our jboss policy)?





--
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: Unreserved portnumbers in corenetwork

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ronald van den Blink wrote:
> 
> On Mar 6, 2008, at 2:37 PM, Christopher J. PeBenito wrote:
> 
>> On Wed, 2008-03-05 at 10:51 -0500, Stephen Smalley wrote:
>>> On Wed, 2008-03-05 at 10:24 -0500, Christopher J. PeBenito wrote:
>>>> On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
>>>>> We're building a policy for JBoss. Jboss uses atleast port 8080 and
>>>>> 8083.
>>>>> Besides this, the application we use on JBoss also opens port 8443
>>>>> (https)
>>>>>
>>>>> While building the jboss-module we ofcourse want to claim these
>>>>> ports and
>>>>> patch corenetwork. However, this is where our problem arises; HTTP has
>>>>> claimed some of the ports we need and http-cache has claimed 8080
>>>>> allready.
>>>>>
>>>>> But http and http-cache allow to open more ports (80, 443, 488, 8008,
>>>>> 8009) than we really need. We think this is against the SElinux
>>>>> policy of
>>>>> least privilege.
>>>>>
>>>>> So how do we deal with these kinds of port conflicts? Maybe
>>>>> corenetwork
>>>>> isn't the best place to define unreserved (> 1024) ports?
>>>>
>>>> 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.
>>>
>>> Perhaps all port context definitions should be moved to being handled
>>> via semanage port?
>>
>> I don't think we actually need to move anything, we just have to allow
>> semanage to delete port labelings, since it can already add and modify
>> them.
> 
> Can I take the fast-lane by saying that we agree on the fact that
> something needs to be done to make it more flexible? And if the answer
> is yes, what is the consensus right now? Is it likely to assume that
> semanage is being allowed to delete port labelings?
> 
> And if we take that approach, aren't we still seeing the issue that
> someone has to decide which port-number is assigned to which
> applications for starters? Because I can see a issue here when new
> policy writers are creating policies and choosing "just to use
> http_cache because my port-number is in that range" and opening up to
> many ports.
> 
> Just to make the discussion a little bit bigger, if we speak of least
> privileged, why are we making general lib_t, usr_t etc.? Aren't we
> making a hole in our security model right then, because of giving to
> much read privileges by saying that everyone has to be able to read in
> lib_t? So actually giving app X read rights to the lib_t's of app Y? Of
> course you have to give access to lib_t first, but after that every
> lib_t labeled file is free to read. Or are we seeing things wrong.
> 
> If we are right, why aren't we just creating appX_lib_t and appY_lib_t
> (the way we are doing in our jboss policy)?
> 
> 
> 
> 
Lets not go overboard here.  The more separation of types, the more the
complexity of writing policy increases.  If you take you question to the
logical conclusion, you end up with every file on the system having a
different type, or 65000 port types.  We used to separate shlib_t from
lib_t but this caused more problems then it was worth.  Mainly labeling
getting screwed up.  The default labeling of a file when it gets created
in a directory is the parent directories label.  So managing different
labels within a directory can be a pain, and is prone to errors.

I would argue the proliferation of types and generation of excess avc's
does more harm then good.  To the point where people see an AVC and just
say SELinux broke something, rather then I wonder if my system is
compromised.

Now you have to look at what the risk of allowing the sshd daemon the
ability to read /usr/share/pixmaps?  If there is no security goal being
broken, there is little reason to prevent this.   If you take Minimal
Privledge to far you end up with an unusable system.

Finally remember the goal of SELinux, in my point of view, is to bring
MAC security to the greatest number of users, not just the TopSecret
crowd.  So usability and supportability have to be paramount or people
will just Turn off SELINUX!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfRQ0UACgkQrlYvE4MpobMdYQCePpcTu/qnBM3wpWIfqXCo70F1
g7AAnjwKxMhF/EByuD1G+0wMjW+0wzOO
=Aq2m
-----END PGP SIGNATURE-----

--
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: Unreserved portnumbers in corenetwork

[Christopher J. PeBenito]

On Fri, 2008-03-07 at 14:13 +0100, Ronald van den Blink wrote:
> On Mar 6, 2008, at 2:37 PM, Christopher J. PeBenito wrote:
> > On Wed, 2008-03-05 at 10:51 -0500, Stephen Smalley wrote:
> >> On Wed, 2008-03-05 at 10:24 -0500, Christopher J. PeBenito wrote:
> >>> On Wed, 2008-03-05 at 11:21 +0100, selinux@a61.nl wrote:
> >>>> We're building a policy for JBoss. Jboss uses atleast port 8080  
> >>>> and 8083.
> >>>> Besides this, the application we use on JBoss also opens port  
> >>>> 8443 (https)
> >>>>
> >>>> While building the jboss-module we ofcourse want to claim these  
> >>>> ports and
> >>>> patch corenetwork. However, this is where our problem arises;  
> >>>> HTTP has
> >>>> claimed some of the ports we need and http-cache has claimed 8080
> >>>> allready.
> >>>>
> >>>> But http and http-cache allow to open more ports (80, 443, 488,  
> >>>> 8008,
> >>>> 8009) than we really need. We think this is against the SElinux  
> >>>> policy of
> >>>> least privilege.
> >>>>
> >>>> So how do we deal with these kinds of port conflicts? Maybe  
> >>>> corenetwork
> >>>> isn't the best place to define unreserved (> 1024) ports?
> >>>
> >>> 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.
> >>
> >> Perhaps all port context definitions should be moved to being handled
> >> via semanage port?
> >
> > I don't think we actually need to move anything, we just have to allow
> > semanage to delete port labelings, since it can already add and modify
> > them.
> 
> Can I take the fast-lane by saying that we agree on the fact that  
> something needs to be done to make it more flexible? And if the answer  
> is yes, what is the consensus right now? Is it likely to assume that  
> semanage is being allowed to delete port labelings?
> 
> And if we take that approach, aren't we still seeing the issue that  
> someone has to decide which port-number is assigned to which  
> applications for starters? Because I can see a issue here when new  
> policy writers are creating policies and choosing "just to use  
> http_cache because my port-number is in that range" and opening up to  
> many ports.

Again, you could argue the same thing for the file labeling.  For the
default reference policy, the labeling is correct.  We can't possibly
write labeling that will work for everyone in all cases.  The best we
can do is provide some sane defaults that can be changed.

> Just to make the discussion a little bit bigger, if we speak of least  
> privileged, why are we making general lib_t, usr_t etc.? Aren't we  
> making a hole in our security model right then, because of giving to  
> much read privileges by saying that everyone has to be able to read in  
> lib_t? So actually giving app X read rights to the lib_t's of app Y?  
> Of course you have to give access to lib_t first, but after that every  
> lib_t labeled file is free to read. Or are we seeing things wrong.
> 
> If we are right, why aren't we just creating appX_lib_t and appY_lib_t  
> (the way we are doing in our jboss policy)?

The policy and the labeling are separate things.  The policy is built
around types, which are equivalence classes.  Least privilege is with
respect to types.  The policy is as least privilege as we can make it,
with some minor concessions to keep complexity in check (eg lock or
ioctl getting into some file perms).  If user_firefox_t can dlopen a
jboss library, why does it matter?  It still runs the code in
user_firefox_t and is still confined by that domain's rules.  In my
opinion, any gains by adding additional types for shared libraries is
outweighed by far by the complexity that it brings.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.