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