83 lines
3.3 KiB
Plaintext
83 lines
3.3 KiB
Plaintext
$NetBSD: security,v 1.1 2017/01/13 10:14:58 dholland Exp $
|
|
|
|
NetBSD Security Roadmap
|
|
=======================
|
|
|
|
This roadmap discusses security-related features.
|
|
|
|
The following elements, projects, and goals are considered strategic
|
|
priorities for the project:
|
|
|
|
1. PaX aslr, mprotect, and segvguard are on by default now; this will
|
|
be in 8.0.
|
|
2. Transparent full-disk encryption (discussed in the storage roadmap)
|
|
3. User-switching and secure attention key (see desktop roadmap)
|
|
|
|
The following elements, projects, and goals are not strategic
|
|
priorities but are still important undertakings worth doing:
|
|
|
|
4. Security restriction framework for large/less trusted applications
|
|
5. Interface for location, accelerometer, and similar sensitive services
|
|
|
|
|
|
Explanations
|
|
============
|
|
|
|
|
|
4. Security restriction framework for large/less trusted applications
|
|
|
|
Traditionally in Unix permissions go with the user logged in, and all
|
|
programs that are run execute with the credentials and permissions of
|
|
that user. (Except for setugid programs, which execute with additional
|
|
permissions.)
|
|
|
|
This makes sense for programs like cat(1) or grep(1) that work with
|
|
user data in the traditional shell environment. However, it is
|
|
unsatisfactory for large semi-trusted applications such as web
|
|
browsers, and entirely unsuitable for 3rd-party "apps" such as found
|
|
on phones, which routinely contain spyware.
|
|
|
|
We would like to have a permissions framework that works on a
|
|
per-application basis and allows imposing restrictions on what apps
|
|
may do, what data apps may read, and also supports policies like
|
|
"cannot talk on the network after reading user data".
|
|
|
|
Such a framework is entirely different from traditional Unix
|
|
permissions and requires careful thought and design. Prior art is
|
|
mostly not very good; e.g. Android's app permissions framework is both
|
|
not expressive enough to pose serious barriers to spyware, and too
|
|
complicated for typical users to cope with effectively. Meanwhile,
|
|
system-call-based restrictions like seccomp/seccomp-bpf in Linux are
|
|
messy and complicated and hard to use effectively. OpenBSD's "pledge"
|
|
has been widely criticized for a range of reasons. Most of these
|
|
models also do not provide for lying to apps that demand access you
|
|
don't want to give them.
|
|
|
|
dholland was working on this with some undergrads a while back and
|
|
there's a design that may be of some value, although the prototype
|
|
implementation was not a success.
|
|
|
|
- As of January 2017 nobody is known to be working on this.
|
|
- There is currently no clear timeframe or release target.
|
|
- Contact dholland for further information.
|
|
|
|
|
|
5. Interface for location, accelerometer, and similar sensitive services
|
|
|
|
Currently in NetBSD we have no infrastructure for the "new" hardware
|
|
interfaces typically found in phones, like GPS location information,
|
|
accelerometer and orientation data, and so forth.
|
|
|
|
There is probably no need to invent new APIs for retrieving this data,
|
|
but we do need a sound underlying framework with security controls in
|
|
place, as many of these data sources provide information that is
|
|
either sensitive or can be used to derive sensitive information.
|
|
|
|
(Note also that it's been shown that location data can be derived from
|
|
monitoring battery level so that one's also sensitive.)
|
|
|
|
- As of January 2017 nobody is known to be working on this.
|
|
- There is currently no clear timeframe or release target.
|
|
- Contact: ? (XXX)
|
|
|