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.
