On Tue, Aug 1, 2023 at 3:49 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Tue, Aug 1, 2023 at 3:38 PM Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > > > On 7/31/23 07:13, Stephen Smalley wrote: > > > On Sun, Jul 30, 2023 at 5:03 PM Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > >> # semanage port -a -t fdf_port_t -p udp 1900 > > >> ValueError: Port udp/1900 already defined > > >> > > >> # semanage port -m -t fdf_port_t -p udp 1900 > > >> > > >> # semanage port -l | grep 1900 > > >> fdf_port_t udp 1900, 3483 > > >> ssdp_port_t tcp 1900 > > >> ssdp_port_t udp 1900 > > >> > > >> And, sure enough, my FDF service is now able to bind to udp/1900. > > >> > > >> I was not previously aware of this feature, and my internet searches > > >> aren't turning up anything about it. I'd just like to confirm that this > > >> is expected behavior (as it just seems really weird). Are there any > > >> caveats to doing this? > > > > > > As far as the kernel is concerned, there can only be one type assigned > > > to a network port, so your new definition is overriding the earlier > > > one. Is the earlier one in a policy module rather than being created > > > via semanage? A potential concern with what you are doing is that any > > > rules written on the earlier type obviously won't be automatically > > > applied to your new type, so anything relying on that behavior will > > > break. > > > > Yes. The earlier context rule (ssdp_port_t) is in the default Fedora > > policy. > > > > Just to make sure that I'm understanding you correctly, it sounds like > > modifying the context of a port with 'semanage port -m' effectively > > changes it to the new type. > > > > So is it fair to say that the 'semanage port -l' output in this > > situation is deceiving? > > I would say so, although technically it is an accurate depiction - > there is a rule in a policy module that defines it one way, and then > there is a local customization that defines it another, with the > latter taking precedence as far as the kernel is concerned. Confusing > at least. Generally redefining a port type like this isn't recommended because as I mentioned, it will cause any allow rules in the base policy written against the other port type to not get applied to this port and hence may cause breakage. Usually you would just add allow rules permitting access to the already defined port type, and only create your own portcons for ports not covered by the base policy.
