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