lists.openwall.net   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, 7 Jun 2017 15:40:36 -0300
From:   Flavio Leitner <fbl@...close.org>
To:     Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net] netlink: don't send unknown nsid

On Mon, Jun 05, 2017 at 10:40:24AM +0200, Nicolas Dichtel wrote:
> > Let me ask this instead: How do you think userspace should behave when
> > netnsid allocation fails?
> > 
> There is two ways to assign a nsid:
>  - manually with netlink ('ip netns set'). In this case, the error is reported
>    to userspace via netlink.

OK.

>  - automatically when a x-netns interface is created. The link-nsid is also
>    reported to userspace. If the allocation failed, NETNSA_NSID_NOT_ASSIGNED is
>    reported. And if you were able to create this x-netns interface, it means
>    that you have access to this peer netns, thus you can try to assign the nsid
>    manually.

Does that prevent the interface to be created?

> So, in both cases, userland knows that something went wrong.
> Do you have another scenario in mind?

Let's say the app is restarted, or another monitoring app is executed
with enough perms.  How will it identify the error condition?

-- 
Flavio

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ