On Fri, Aug 23, 2019 at 1:19 AM David Miller wrote:
>
> From: Jeff Vander Stoep
> Date: Wed, 21 Aug 2019 15:45:47 +0200
>
> > MAC addresses are often considered sensitive because they are
> > usually unique and can be used to identify/track a device or
> > user [1].
> >
> > The MAC address is acc
On Wed, Aug 21, 2019 at 4:34 PM Casey Schaufler wrote:
>
> On 8/21/2019 6:45 AM, Jeff Vander Stoep wrote:
> > MAC addresses are often considered sensitive because they are
> > usually unique and can be used to identify/track a device or
> > user [1].
> >
> > The MAC address is accessible via the R
On Wed, Aug 21, 2019 at 3:45 PM Jeff Vander Stoep wrote:
>
> MAC addresses are often considered sensitive because they are
> usually unique and can be used to identify/track a device or
> user [1].
>
> The MAC address is accessible via the RTM_NEWLINK message type of a
> netlink route socket[2]. I
On Thu, Aug 31, 2017 at 7:05 PM, Alexei Starovoitov
wrote:
> On Thu, Aug 31, 2017 at 01:56:34PM -0700, Chenbo Feng wrote:
>> From: Chenbo Feng
>>
>> Introduce a pointer into struct bpf_map to hold the security information
>> about the map. The actual security struct varies based on the security
>
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley wrote:
> On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
> wrote:
>> I’d like to get your thoughts on adding LSM permission checks on BPF
>> objects.
>>
>> By default, the ability to create and u
I’d like to get your thoughts on adding LSM permission checks on BPF objects.
By default, the ability to create and use eBPF maps/programs requires
CAP_SYS_ADMIN [1]. Alternatively, all processes can be granted access
to bpf() functions. This seems like poor granularity. [2]
Like files and socket
