jmjonesat_private wrote: > On Fri, 20 Jul 2001, Crispin Cowan wrote: > > To correct an (apparently common todya) misconception, SubDomain does not > > deny access to specified names. SubDomain grants access to specified > > names, and denies access to everything else. This is a subtle but > > important consideration with respect to the validity of denying access to a > > file based on its name, when in fact the file could be aliased under a > > different name with a hard link. > > This would seem to me to be an excellent description of a "permissive" > policy. Protection of the core file (restrictive) would be applied at > the deepest (inode) level, but confined applications would be > permitted *specific* accesses based on filename. Not quite. Going back to the classic Saltzer & Schroeder '74 paper http://web.mit.edu/Saltzer/www/publications/protection/index.html the duality notions of "permissive" and "restrictive" are defined as "default allow" and "default deny" respectively. The duality in SubDomain vs. protecting a file is between "capability" based systems, and "access control" systems. The default allow/deny duality: * default allow: everything not specifically denied is permitted. This provides lots of flexibility, but is vulnerable if the bad guys come up with a creative new way to ask for something unanticipated. * default deny: everything not specifically permitted is denied. This provides greater security, because creative new requests are rejected. This compromises flexibility, because new applications tend not to work. E.g. in a firewall, if you use a default deny policy, when a spiffy new application comes along (such as NetMeeting) it will get blocked, and the firewall admin has to do something to enable new business. Saltzer & Schroeder recommend this, and refer to it as "fail-safe defaults" http://web.mit.edu/Saltzer/www/publications/protection/Basic.html The capability/access control duality refers to where access control information is stored: * Capabilities: the "capability" for a subject (person or process) to access an object (file or some such) is stored with the subject. Think of a capability as an unforgable "ticket" that the subject presents to the doorman to gain admittance. * Access control lists: the objects store lists of which subjects may access the objects. Think of it as an invitation list; subjects present their identification to the doorman, who checks the list to see if they are invited, and only lets them in if they're on the list. The capability/access control list is a continuum, with may possible points in between, having to do with what constitutes a "ticket" and what constitutes "identification". In one degenerate extreme, an access control list with only one subject on it makes the subject's identification a capability, and in the other extreme a single capability that grants access to all needed objects is an identity. Capabilities and access control lists offer trade-offs in administrative expense. Pure access control lists are tedious to maintain, as the lists get long. A simple abstraction is to create groups, and place groups on the access control lists instead of enumerating all of the group members. Go further into this abstraction, and you end up with Type Enforcement, currently being implemented for LSM as DTE by Serge. Capabilities have a different cost problem: revocation. If a capability needs to be revoked, you either need to find all copies of the capability and destroy it or go around and tell every object that the relevant capability is no longer to be believed. Neither is cheap, but the latter is at least practical. SubDomain and EROS are a couple of interesting capability-based systems. EROS is a "pure" capability system, in which all access is managed through capabilities. SubDomain is an impure :-) capability system, in which capabilities are very definitely NOT first class. A capability to access a file is granted to a program by the system admin, but this capability cannot be passed around to other arbitrary subjects. The admin can revoke this capability by editing the program's profile and forcing the kernel to reload the profiles. There is a GREAT deal of research into the semantics of various access control models. Capabilities were introduced in 1967, on the PDP-1. We are unlikely to invent new models here. But it is helpful to keep these principles in mind while designing LSM, and in designing LSM modules. > Perhaps this is only "permissive relative to LSM-sea-level", but is it not > permissive? The difference is subtle, but add the fact that other > security modules MIGHT care about "unconfined" processes/programs, > rather then just lumping them into "trusted", it would seem a fine-but-- > useful distinction. As I have written here before, there are two perspectives for considering the permissive/restrictive nature of LSM: * The kernel looking at the module: The "restrictive hooks only" design makes LSM modules default fail-safe for the kernel. No matter how screwed up the module is, it can't grant access to something the kernel would deny, and therefore is fail-safe. * The application looking at the kernel: "default fail-safe" can be had any number of ways, so long as it denies access by default, and only grants specific accesses. You can do this with classic UNIX DAC mode bits, by just setting all the files in the system to 000, and then carefully structuring your users and groups such that only appropriate accesses are granted. You can do it by using POSIX.1e "capabilities" (which are only marginally "capabilities" in the classical sense above) to that your privileged stuff is not running as root, and instead uses the POSIX stuff to grant needed accesses. And you can achieve it with SubDomain by running your dangerous stuff as root, but doing so inside a SubDomain profile that only grants needed access. But it is more closely related to how you configure your system than to whether LSM has permissive hooks. I.e. both SubDomain and POSIX can achieve default fail-safe, but only POSIX actually requires permissive hooks. Caveat: I'm sure that SELinux and other LSM modules can achieve default fail-safe too, but I'll avoid embarrassing myself by not attempting to describe how :-) > Since there are "standard" security functions already in place in the > kernel, which COULD provide restrictive control that is widely understood, > and a little "permissive tweaking" COULD allow "confined processes" to get > access they otherwise wouldn't have a prayer of getting, I see a need for > authoritative, if not permissive, tweaks to LSM as being inherent in this > strategy. As outlined above, you don't need permissive hooks to achieve default fail-safe. Therefore, all discussion is about the most pragmatic way to achieve default fail-safe, where "pragmatic" means (among other things) least impact to the kernel source, least mechanism in the LSM modules, and least chance of screwing up in configuring your system. The first two are design considerations for the LSM implementation, and the third is a design consideration in designing modules to go into the LSM. I remain unconvinced that permissive hooks (beyond the capable() hooks to support POSIX.1e) are called for in LSM. Crispin -- Crispin Cowan, Ph.D. Chief Scientist, WireX Communications, Inc. http://wirex.com Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Jul 22 2001 - 17:29:53 PDT