security revision 1.1
1$NetBSD: security,v 1.1 2017/01/13 10:14:58 dholland Exp $ 2 3NetBSD Security Roadmap 4======================= 5 6This roadmap discusses security-related features. 7 8The following elements, projects, and goals are considered strategic 9priorities 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 16The following elements, projects, and goals are not strategic 17priorities 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 23Explanations 24============ 25 26 274. Security restriction framework for large/less trusted applications 28 29Traditionally in Unix permissions go with the user logged in, and all 30programs that are run execute with the credentials and permissions of 31that user. (Except for setugid programs, which execute with additional 32permissions.) 33 34This makes sense for programs like cat(1) or grep(1) that work with 35user data in the traditional shell environment. However, it is 36unsatisfactory for large semi-trusted applications such as web 37browsers, and entirely unsuitable for 3rd-party "apps" such as found 38on phones, which routinely contain spyware. 39 40We would like to have a permissions framework that works on a 41per-application basis and allows imposing restrictions on what apps 42may do, what data apps may read, and also supports policies like 43"cannot talk on the network after reading user data". 44 45Such a framework is entirely different from traditional Unix 46permissions and requires careful thought and design. Prior art is 47mostly not very good; e.g. Android's app permissions framework is both 48not expressive enough to pose serious barriers to spyware, and too 49complicated for typical users to cope with effectively. Meanwhile, 50system-call-based restrictions like seccomp/seccomp-bpf in Linux are 51messy and complicated and hard to use effectively. OpenBSD's "pledge" 52has been widely criticized for a range of reasons. Most of these 53models also do not provide for lying to apps that demand access you 54don't want to give them. 55 56dholland was working on this with some undergrads a while back and 57there's a design that may be of some value, although the prototype 58implementation 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 655. Interface for location, accelerometer, and similar sensitive services 66 67Currently in NetBSD we have no infrastructure for the "new" hardware 68interfaces typically found in phones, like GPS location information, 69accelerometer and orientation data, and so forth. 70 71There is probably no need to invent new APIs for retrieving this data, 72but we do need a sound underlying framework with security controls in 73place, as many of these data sources provide information that is 74either 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 77monitoring 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