Bug 2074414

Hi,

Do you happen to know which command triggers this denial?
Did it start to happen with some package (kernel, teamd) update?

(In reply to Zdenek Pytela from comment #1)
> Hi,
> 
> Do you happen to know which command triggers this denial?

It was triggered by a kselftest. I have optimize the reproducer like
```
#!/bin/bash

for i in `seq 10`;do
        > /var/log/audit/audit.log
        systemctl restart NetworkManager
        ip link add type veth
        ip link set veth1 up

        teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
        ip link set veth0 master team0
        ip link set team0 up
        sleep 2
        teamd -t team0 -k
        modprobe -r veth
        aureport -a | grep teamd && break
done

```

> Did it start to happen with some package (kernel, teamd) update?

Not sure, I didn't enable AVC checking before. Need to try this reproducer on old releases first.

Thank you, I still don't understand this part though:

(In reply to Hangbin Liu from comment #2)
> (In reply to Zdenek Pytela from comment #1)
> > Hi,
> > 
> > Do you happen to know which command triggers this denial?
> 
> It was triggered by a kselftest. I have optimize the reproducer like
> ```
> #!/bin/bash
> 
> for i in `seq 10`;do
>         > /var/log/audit/audit.log
>         systemctl restart NetworkManager
>         ip link add type veth
>         ip link set veth1 up
> 
>         teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
teamd instance is started, it runs in the caller domain, unconfined_t in this case:

# ps -eo pid,ppid,command,context | grep -e CONTEXT -e teamd
    PID    PPID COMMAND                     CONTEXT
  94401       1 teamd -t team0 -d -c {"runn unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

>         ip link set veth0 master team0
>         ip link set team0 up
>         sleep 2
>         teamd -t team0 -k
teamd is executed to kill the running instance; the kill() syscall is sent from a process in NetworkManager_t domain though - so which process actually sends the signal? The signal seems to be SIGTERM.


>         modprobe -r veth
>         aureport -a | grep teamd && break
> done
> 
> ```

Unfortunately, I was unable to reproduce the problem with this scenario, even when the loop was run 100 times. We would need a reliable one for the purpose of testing.

(In reply to Zdenek Pytela from comment #3)
> 
> Unfortunately, I was unable to reproduce the problem with this scenario,
> even when the loop was run 100 times. We would need a reliable one for the
> purpose of testing.

Maybe it's easy to reproduce on VM? I use `1minutetip rhel8`[1] to get an instance on PSI and
could reproduce this issue easily.



[1] Homepage: http://wiki.test.redhat.com/BaseOs/Projects/1minuteTIP

(In reply to Hangbin Liu from comment #4)
> (In reply to Zdenek Pytela from comment #3)
> > 
> > Unfortunately, I was unable to reproduce the problem with this scenario,
> > even when the loop was run 100 times. We would need a reliable one for the
> > purpose of testing.
> 
> Maybe it's easy to reproduce on VM? I use `1minutetip rhel8`[1] to get an
> instance on PSI and
> could reproduce this issue easily.

I used a rhel9 1mt vm with this script. Now executed about 300 times, no AVC.
On a rhel8 system it reproduced immediately.
Is there any substantial difference, or why it did not trigger an AVC?

Still, I'd like to understand the interprocess communication.

(In reply to Zdenek Pytela from comment #5)
> 
> I used a rhel9 1mt vm with this script. Now executed about 300 times, no AVC.
> On a rhel8 system it reproduced immediately.
> Is there any substantial difference, or why it did not trigger an AVC?

I also could not reproduce it on RHEL9 by running the reproducer manually.
But my test jobs could trigger this issue every time.

https://beaker.engineering.redhat.com/recipes/11757144#task142445370
https://beaker.engineering.redhat.com/recipes/11718213#task142085471

> 
> Still, I'd like to understand the interprocess communication.

I don't know either. teamd only calls libdaemon to kill the process.

```teamd/teamd.c:main()
        case DAEMON_CMD_KILL:
                if (daemon_pid_file_is_running() > 0) {
                        err = daemon_pid_file_kill_wait(SIGTERM, 30);
                        if (err)
                                teamd_log_warn("Failed to kill daemon: %s",
                                               strerror(errno));
                        else
                                ret = TEAMD_EXIT_SUCCESS;
                } else {
                        teamd_log_warn("Daemon not running");
                }
                break;

```

Hi Beniamino, do you have any idea why NM will kill the process teamd trying to kill?

Using your script I got:

  [1649842400.6525] device[5509e18e5a0c14b1] (team0): sys-iface-state: external -> removed
  [1649842400.6526] device[5509e18e5a0c14b1] (team0): unrealize (ifindex 493)
  [1649842400.6526] device[5509e18e5a0c14b1] (team0): ifindex: set ifindex 0 (old-l3cfg: 3a09b5bf450d7785)
  [1649842400.6529] device (team0): state change: activated -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
  [1649842400.6530] device[5509e18e5a0c14b1] (team0): deactivating device (reason 'unmanaged') [3]
  [1649842400.6530] device[5509e18e5a0c14b1] (team0): running: /usr/bin/teamd -k -t team0

NM is tracking the interface as "external", which means that NM tries
to never touch it. In nm-device-team.c it does:

  static void
  deactivate(NMDevice *device)
  {
      NMDeviceTeam        *self = NM_DEVICE_TEAM(device);
      NMDeviceTeamPrivate *priv = NM_DEVICE_TEAM_GET_PRIVATE(self);

      if (nm_device_sys_iface_state_is_external(device))
          return;

     [...]

     teamd_kill(self, NULL, NULL);   // <---- this calls "teamd -k"
  }

However, in the log we see that the sys-iface-state already
transitioned from "external" to "removed" and so the check on
*_is_external() doesn't work as expected. This (the fact that
NM tries to kill a teamd started externally, even if there is
no NM connection for it) seems a bug in NM.

--

But note that in general, if NM wants to activate a connection on team0
and already finds a teamd instance started externally for team0, it
will try to kill it via "teamd -k". I think this is expected, and probably
it will give a similar AVC denial. Something like:

  teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
  nmcli connection add type team ifname team0 ip4 172.25.1.1/24 con-name team0+
  nmcli connection up team0+

(In reply to Beniamino Galvani from comment #7)
>   teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}'
>   nmcli connection add type team ifname team0 ip4 172.25.1.1/24 con-name
> team0+
>   nmcli connection up team0+
This one reproduced on RHEL 9, too. There are 5 attempts audited:

----
type=PROCTITLE msg=audit(04/13/22 12:25:33.714:364) : proctitle=/usr/bin/teamd -k -t team0
type=SYSCALL msg=audit(04/13/22 12:25:33.714:364) : arch=x86_64 syscall=kill success=no exit=EACCES(Permission denied) a0=0x17bd8 a1=SIGTERM a2=0x7ffee23dc640 a3=0x7fb433e44480 items=0 ppid=85272 pid=97273 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=teamd exe=/usr/bin/teamd subj=system_u:system_r:NetworkManager_t:s0 key=(null)
type=AVC msg=audit(04/13/22 12:25:33.714:364) : avc:  denied  { signal } for  pid=97273 comm=teamd scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0

Thank you for the explanation.

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 (selinux-policy bug fix and enhancement update), 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/RHBA-2022:8283