lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 17 Apr 2019 16:05:09 +0800
From:   Hangbin Liu <>
Cc:     David Miller <>,
        Richard Cochran <>,
        Miroslav Lichvar <>,
        Patrick McHardy <>,
        Jiri Benc <>,
Subject: Re: [PATCH net-next] macvlan: pass get_ts_info and SIOC[SG]HWTSTAMP
 ioctl to real device

On Wed, Mar 20, 2019 at 10:23:33AM +0800, Hangbin Liu wrote:
> Similiar to commit a6111d3c93d0 ("vlan: Pass SIOC[SG]HWTSTAMP ioctls to
> real device") and commit 37dd9255b2f6 ("vlan: Pass ethtool get_ts_info
> queries to real device."), add MACVlan HW ptp support.
> Signed-off-by: Hangbin Liu <>

Hi all,

For this patch. Jiri mentioned that running two ptp4l/phc2sys instances on two
containers will not work. But I think the admin should avoid this scenario as
we should not run two phc2sys instances on the same real device. In NET_ADMIN
enabled containers, if a normal user which has mapped to root wants to run
ptp4l, the admin need either add the device specifically (--device=/dev/ptp1)
or give the container privileged permission (--privileged). So I think this
should not be a security problem.

On the other hand, Miroslav pointed that with NET_ADMIN enabled in container,
a normal user could be mapped to root and is able to change the real devices's
rx filter via ioctl on macvlan, which may affect the other ptp process on
host. ptp over vlan also has this issue, but macvlan is more frequently used
in container. To prevent this issue, here are some options:

1. limit ioctl SIOCSHWTSTAMP to only enabling timestamping and switching to
   more general filters. The limitation could be only in container and leave
   init_net free.
2. reject SIOCSHWTSTAMP in container.
3. revert the patch. The vlan part is too late to revert.

So what do you think? which one do you prefer?


Powered by blists - more mailing lists