Bug 974163

(In reply to Dalibor Pospíšil from comment #0)
> +++ This bug was initially created as a clone of Bug #974158 +++
> 
> Description of problem:
> semanage allow to modify default port type while keeps the assignment to the
> old type. This leads to situation where one port has two types. Also
> semanage -o - generates wrong outut which cannot be applied. Moreover after
> modifying the the port and modyfying it back to the original type I can
> delete the type for the first time. The second time I get '... is defined in
> policy, cannot be deleted' message.
> 
> Version-Release number of selected component (if applicable):
> policycoreutils-python-2.1.14-46.2.el7
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> [root@rhel6 ~]# semanage port -m -t http_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -l | grep 8080
> http_cache_port_t              tcp      3128, 8080, 8118, 8123, 10001-10010
> http_port_t                    tcp      8080, 80, 443, 488, 8008, 8009, 8443
> [root@rhel6 ~]# semanage -o - | grep 8080
> port -a -t http_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -m -t http_cache_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -l | grep 8080
> http_cache_port_t              tcp      8080, 3128, 8080, 8118, 8123,
> 10001-10010
> [root@rhel6 ~]# semanage -o - | grep 8080
> port -a -t http_cache_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -d -t http_cache_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -d -t http_cache_port_t -p tcp 8080
> /usr/sbin/semanage: Port tcp/8080 is defined in policy, cannot be deleted
> 
> I would expect that semanage is able to remove default rule as local
> customization and then add new rule. So the 'semanage port -m' would be
> internally translated into 'semanage port -d' and 'semanage port -a'
> sequence.

We don't want to remove the default port declaration. The local modification is used if you define it.

So it looks it is a bug in "semanage-port -l".

I'd like to clarify what this bug is about.

Default port declarations are defined in modules therefore you can't remove them unless you remove a particular module.

However, you can change them using 'semanage port -m'. In this case, a new local modification is added and you can see it in 'semanage port -l -C' output. Definitions from local modifications have higher priority than policy definitions.

The problem is in 'semanage port -l' output which shows all definitions from a system policy, and also local modifications so that a particular port can be listed multiple times.

I'd consider this as a minor issue.

Ok, what about the local customizations? Is it expected that it is listed as local customization even if we returned it to the original state?
Are we even able to check what was the original state?

Also what about this:
[root@rhel6 ~]# semanage port -m -t http_port_t -p tcp 8080
[root@rhel6 ~]# semanage port -d -t http_port_t -p tcp 8080

Normally I would expect -d to be allowed only after -a, not after -m.

(In reply to Dalibor Pospíšil from comment #16)
> Ok, what about the local customizations? Is it expected that it is listed as
> local customization even if we returned it to the original state?
> Are we even able to check what was the original state?

semanage port -lC will show local customizations.
semanage port -D will delete local customizations.

(In reply to Dalibor Pospíšil from comment #17)
> Also what about this:
> [root@rhel6 ~]# semanage port -m -t http_port_t -p tcp 8080
> [root@rhel6 ~]# semanage port -d -t http_port_t -p tcp 8080
> 
> Normally I would expect -d to be allowed only after -a, not after -m.

add means "add or fail if it exists".
modify means "add or modify if it exists".
So modify does add a local customization that can then be deleted.

I didn't design this interface; I agree it isn't exactly intuitive, but I don't think this is new or recent.

(In reply to Stephen Smalley from comment #18)
> semanage port -lC will show local customizations.
> semanage port -D will delete local customizations.
I don't understand what you want to say by this. I don't get the answer to 'Is it expected that it is listed as local customization *even if we returned* it to the original state?'.


(In reply to Stephen Smalley from comment #19)
> add means "add or fail if it exists".
> modify means "add or modify if it exists".
> So modify does add a local customization that can then be deleted.
Actually, you're wrong:
[0 root@sopos-rhel7-brq ~]# semanage port -m -t http_port_t -p tcp 28080                                                                                                                                                                     
ValueError: Port @tcp/28080 is not defined
[0 root@sopos-rhel7-brq ~]# semanage port -a -t http_port_t -p tcp 28080                                                                                                                                                                     
[0 root@sopos-rhel7-brq ~]# semanage port -d -t http_port_t -p tcp 28080

There's also inconsistency between semanage port -m and import.

While you cannot do 
# semanage port -a -t http_port_t -p tcp 8080
ValueError: Port tcp/8080 already defined

you can
# semanage -i - <<EOF
port -a -t http_port_t -p tcp 8080
EOF
# semanage port -l | grep 8080
http_cache_port_t              tcp      8080, 8118, 8123, 10001-10010
http_port_t                    tcp      8080, 80, 81, 443, 488, 8008, 8009, 8443, 9000


Modify is consistent:
# semanage -i - <<EOF
port -m -t http_port_t -p tcp 28080
EOF
ValueError: Port @tcp/28080 is not defined
# semanage port -m -t http_port_t -p tcp 28080
ValueError: Port @tcp/28080 is not defined

(In reply to Stephen Smalley from comment #19)
> I didn't design this interface; I agree it isn't exactly intuitive, but I
> don't think this is new or recent.
It is definitely not new. I just want to make clear whether it is expected or a bug.

(In reply to Dalibor Pospíšil from comment #20)
> (In reply to Stephen Smalley from comment #18)
> > semanage port -lC will show local customizations.
> > semanage port -D will delete local customizations.
> I don't understand what you want to say by this. I don't get the answer to
> 'Is it expected that it is listed as local customization *even if we
> returned* it to the original state?'.

You didn't return to the original state (i.e. you didn't delete all local customizations ala semanage port -D, as you would see if you did semanage port -lC), you just changed the value of your local customization.  I guess you are asking if semanage ought to recognize that the local customization is the same as the base policy and drop it, but that would be an enhancement.

> (In reply to Stephen Smalley from comment #19)
> > add means "add or fail if it exists".
> > modify means "add or modify if it exists".
> > So modify does add a local customization that can then be deleted.
> Actually, you're wrong:
> [0 root@sopos-rhel7-brq ~]# semanage port -m -t http_port_t -p tcp 28080    
> 
> ValueError: Port @tcp/28080 is not defined
> [0 root@sopos-rhel7-brq ~]# semanage port -a -t http_port_t -p tcp 28080    
> 
> [0 root@sopos-rhel7-brq ~]# semanage port -d -t http_port_t -p tcp 28080

Ok, sorry - my mistake.  semanage and libsemanage was predominantly designed and written by Red Hat, so not my area of expertise.  I'll shut up.

Ad. "semanage port -l", It's possible to filter out the non-local port definitions that are overridden by some local definition, however I think it would be better to document current behaviour (so that users can see what is actually happening behind the scenes). Would this be ok Dalibor?

As for the inconsistency, it seems like a minor issue. Both behaviours seem sane ("semanage -i" just seems slightly smarter) and users will usually only use one of the interfaces.

Well, if it is displayed twice, how the user actually knows which one is the winner?

"semanage port -lC" (list local customisations)

Ok, it is not that obvious to the user but it is acceptable.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0913