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