Re: [saag] draft-moore-iot-bcp-00 (Best Current Practices for Securing Internet of Things (IoT) Devices)

[Ben Laurie <[e-mail]>]

On 8 November 2016 at 15:02, Watson Ladd <[e-mail]> wrote:
> On Mon, Nov 7, 2016 at 11:42 PM, Loganaden Velvindron <[e-mail]> wrote:
>>
>>
>> On 11/5/16 5:25 AM, Keith Moore wrote:
>>> Stephen Farrell suggested I bring this draft to your attention. This
>>> was a rush job as the authors just started talking about this last
>>> Friday, but it was written in response to recent DDoS attacks that
>>> utilized easily-compromised IoT devices.   I'm sure there are missing
>>> pieces (I've identified a few since -00) and sections that could be
>>> stated better (like the title of section 2.3.2), but hopefully this is
>>> a useful start.
>>>
>>> https://datatracker.ietf.org/doc/draft-moore-iot-security-bcp/
>> [Speaking for myself]
>>
>> That's a great start.
>>
>> Can you please consider adding section 2.6.3. Sandboxing techniques
>> Device firmware SHOULD be designed to restrict processes attack surface
>> by isolating them in sandboxing, in addition to privilege minization. In
>> case of compromise, the attack surface is significantly reduced,
>> particularly in the case of privilege minimization.
>>
>> [I'm thinking about OpenSSH and Linux seccomp-bpf sandbox, and also
>> techniques like OpenBSD's pledge]
>
> Does OS sandboxing actually work?
>
> Real attackers attack. That means they have carefully studied the
> system call interface of operating systems to find bugs, which they
> can use to escape from running arbitrary code to violating all
> security properties. They don't break the sandbox layer but exploit
> the kernel instead.

Nothing works perfectly, but sandboxing is not completely pointless:
it reduces the attack surface, including (at least for some sandboxes)
the kernel attack surface. Certainly seccomp-bpf claims this property,
as does Capsicum.

Also, even if we fixed every bug in the kernel, we'd still have
security vulnerabilities in applications, which could be mitigated by
sandboxing. Note that this is what the OP claims, not that it defends
the kernel - which I agree is also useful.