Home | History | Annotate | Line # | Download | only in roadmaps 
      1     $NetBSD: security,v 1.1 2017/01/13 10:14:58 dholland Exp $
      2     
      3     NetBSD Security Roadmap
      4     =======================
      5     
      6     This roadmap discusses security-related features.
      7     
      8     The following elements, projects, and goals are considered strategic
      9     priorities for the project:
     10     
     11      1. PaX aslr, mprotect, and segvguard are on by default now; this will
     12         be in 8.0.
     13      2. Transparent full-disk encryption (discussed in the storage roadmap)
     14      3. User-switching and secure attention key (see desktop roadmap)
     15     
     16     The following elements, projects, and goals are not strategic
     17     priorities but are still important undertakings worth doing:
     18     
     19      4. Security restriction framework for large/less trusted applications
     20      5. Interface for location, accelerometer, and similar sensitive services
     21     
     22     
     23     Explanations
     24     ============
     25     
     26     
     27     4. Security restriction framework for large/less trusted applications
     28     
     29     Traditionally in Unix permissions go with the user logged in, and all
     30     programs that are run execute with the credentials and permissions of
     31     that user. (Except for setugid programs, which execute with additional
     32     permissions.)
     33     
     34     This makes sense for programs like cat(1) or grep(1) that work with
     35     user data in the traditional shell environment. However, it is
     36     unsatisfactory for large semi-trusted applications such as web
     37     browsers, and entirely unsuitable for 3rd-party "apps" such as found
     38     on phones, which routinely contain spyware.
     39     
     40     We would like to have a permissions framework that works on a
     41     per-application basis and allows imposing restrictions on what apps
     42     may do, what data apps may read, and also supports policies like
     43     "cannot talk on the network after reading user data".
     44     
     45     Such a framework is entirely different from traditional Unix
     46     permissions and requires careful thought and design. Prior art is
     47     mostly not very good; e.g. Android's app permissions framework is both
     48     not expressive enough to pose serious barriers to spyware, and too
     49     complicated for typical users to cope with effectively. Meanwhile,
     50     system-call-based restrictions like seccomp/seccomp-bpf in Linux are
     51     messy and complicated and hard to use effectively. OpenBSD's "pledge"
     52     has been widely criticized for a range of reasons. Most of these
     53     models also do not provide for lying to apps that demand access you
     54     don't want to give them.
     55     
     56     dholland was working on this with some undergrads a while back and
     57     there's a design that may be of some value, although the prototype
     58     implementation was not a success.
     59     
     60      - As of January 2017 nobody is known to be working on this.
     61      - There is currently no clear timeframe or release target.
     62      - Contact dholland for further information.
     63     
     64     
     65     5. Interface for location, accelerometer, and similar sensitive services
     66     
     67     Currently in NetBSD we have no infrastructure for the "new" hardware
     68     interfaces typically found in phones, like GPS location information,
     69     accelerometer and orientation data, and so forth.
     70     
     71     There is probably no need to invent new APIs for retrieving this data,
     72     but we do need a sound underlying framework with security controls in
     73     place, as many of these data sources provide information that is
     74     either sensitive or can be used to derive sensitive information.
     75     
     76     (Note also that it's been shown that location data can be derived from
     77     monitoring battery level so that one's also sensitive.)
     78     
     79      - As of January 2017 nobody is known to be working on this.
     80      - There is currently no clear timeframe or release target.
     81      - Contact: ? (XXX)
     82     
     83