Labelling a new port

[Stefan Schulze Frielinghaus]

On 06.09.2007, at 23:18, Michael Thomas wrote:

> Stefan Schulze Frielinghaus wrote:
>> You can add ports via semange e.g. "semanage port -a -t  
>> memcached_port_t
>> -p tcp 11211"
>>
>> see semanage(8) for more details
>>
>> PS: you need to declare the type in your policy before executing the
>> command. look at modules/kernel/corenetwork.te for some examples
>>
>> On 06.09.2007, at 18:43, Konstantin Ryabitsev wrote:
>>
>>> Hello, all:
>>>
>>> I'm trying to write a policy for memcached, but I'm not sure how I'd
>>> declare a new memcached_port_t (11211/tcp). Any pointers?
>
> If you want to manage the port for a daemon that is started/stopped  
> via
> an init script, then the best place to put the 'semanage port -a ...'
> command is in the init script itself.  This will ensure that the port
> definition is set and removed when the daemon starts/stops.   
> Putting it
> in the spec file and running at package install time is not enough
> because I don't believe that the semanage'd ports persist after a  
> reboot.
>
> start() {
> ...
>     if selinuxenabled ; then
>         /usr/sbin/semanage port -a -t memcached_port_t -p tcp 12111
> &>/dev/null || :
>     fi
> ...
> }
>
> stop() {
> ...
>     if selinuxenabled ; then
>         /usr/sbin/semanage port -d -t memcached_port_t -p tcp 11211
> &>/dev/null || :
>     fi
> ...
> }

What additional security benefit should this bring if you add and  
remove the port type via an init script? On the contrary I think this  
harms rather than hardens the system. Because if you remove the port  
type by running the init script with the stop option every  
application with network access can now send data over this port  
(with no further allow statements). But if you would have led the  
port type no application with additional allow statements on port xyz  
could send data over this port. In the end you could trust sooner  
that data.