L.Badger,D.F.Sterne,D.L.Sherman,K.M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of policies controlling an extension s access to other extensions and its ability to extend, or override, the behavior of already existing services. In the SPIN operating system [3, 4] built at the University of Washington, we are experimenting with a version of domain and type enforcement (DTE) [1, 2] that has been extended to address the security concerns of extensible systems. We are critically concerned with the performance of DTE, as extensible systems enable the fine grained interaction between components with very low overhead; we intend to maintain that property while also applying ....

Lee Badger et al. Practical Domain and Type Enforcement for UNIX. In Proceedings of the 1995.

....programs that migrate to their host. There is no fixed set of resources that a host administers. Further, because the different components of resources and mobile programs may require different levels of protection [20] security models must support fine grained access control. Several techniques [3,11,13,15,17,19,20,29,35,36] 1389 1286 00 see front matter 2000 Published by Elsevier Science B.V. All rights reserved. PII: S1389 1286(00)00075 X have been proposed for defining and enforcing access control for mobile programs. The primary focus in most of these approaches has been on supporting flexibility, ....

....run when received by a host. The limitation with generic capability systems is that they cannot usually prevent a program from leaking a reference to an untrusted object. Our approach solves this problem by protecting the resource itself, and not just its references. Domain Type Enforcement (DTE) [3] is Trusted Information System s (TIS s) access control project, in which subjects are grouped into domains and objects are grouped into domains. There is also a language (DTEL) that specifies which domains can perform certain operations on which types and how threads can change domains by ....

L. Badger, D.F. Sterne, D.L. Sherman, K.M. Walker and S.A. Haghighat, Practical domain and type enforcement for UNIX, in: Proc. of the 1995.

.... has been wellunderstood for over thirty years, yet the access control mechanisms of existing mainstream operating systems are still inadequate to provide strong security [2, 39, 28, 17, 26, 6, 30] Although many enhanced access control models and frameworks have been proposed and implemented [9, 1, 4, 41, 23, 10, 29, 37], mainstream operating systems typically still lack support for these enhancements. In part, the absence of such enhancements is due to a lack of agreement within the security community on the right general solution. Like many other general purpose operating systems, the Linux kernel only ....

....processes to least privilege, to protect the integrity and confidentiality of processes and data, and to support application security needs. The generality and comprehensiveness of SELinux helped to drive the requirements for LSM. DTE Linux An implementation of Domain and Type Enforcement [4, 5] developed for Linux [23] Like SELinux, DTE Linux was originally implemented as a kernel patch and was then adapted to LSM. With this module loaded, types can be assigned to objects and domains to processes. The DTE policy restricts access between domains and from domains to types. The DTE Linux ....

[Article contains additional citation context not shown here]

L. Badger, D.F. Sterne, and et al. Practical Domain and Type Enforcement for UNIX. In Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, May 1995.

....the program that allows the attacker to acquire that privilege. Some examples include: Buffer Overflows: Many privileged programs contain buffer overflow vulnerabilities, a problem endemic to C programs that provide poor bounds checking on user supplied input. Buffer overflows are very common [6, 7] and very dangerous [21, 20] allowing attackers to take control of programs from an anonymous node on the internet. Race Conditions: Many privileged programs also contain race condition vulnerabilities. Here, the problem is that careless root privileged processes create files without adequate ....

....is a collection of related privileges [2] In 1986, Bobert and Kain introduced the notion of type enforcement: objects (files) are assigned to types, subjects (processes) are assigned to domains, and tables determine which domains have access to which types. Badger et al. expanded on this notion [7, 8]. In a similar vein, role based access control (RBAC) 22, 34] assigns users to roles, and then grants privileges to the roles. Similar to the setuid approach described in Section 2.1.1, roles can be pressed into service confining programs to a least privilege set of resources by assuming a ....

[Article contains additional citation context not shown here]

L.Badger, D.F. Sterne, and etal. Practical Domain and Type Enforcement for UNIX. In Proceedings of the IEEE Symposium on Security and Privacy, Oakland, CA, May 1995.

....permissions. The selection of the new principal s rights and the means to update all the effected ACLs is not specified. The OSKit is a component based operating system environment [5] The OSKit team is using the DTOS security architecture [15] with a Domain Type Enforcement access control model [2] although the details of its application are not yet available. 3 Architecture The goal of the Lava system architecture is to enable the dynamic composition of systems from components while enforcing the system s security policy. The security requirements of the components are expressed in the ....

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In IEEE Symposium on Security and Privacy, pages 66--77, 1995.

....case changing conditions (and levels of trust) compel the administrator to replace one of the active policies. In this section, we will describe a single SVE policy, local to the enclave in which it was created. The SVE policy language uses concepts familiar from Domain and Type Enforcement (DTE) [5], which defines policy in terms of the access rights of equivalence classes of subjects to equivalence classes of objects. An object is a resource accessed by software. A subject is a software component that accesses resources on behalf of a principal. Principals are persons or persistent programs ....

....security technologies into CORBA based distributed computing environments. The Sigma project built prototypes of both gateway and server resident (ORB plug in) interceptor enforcers for CORBA requests and developed the object oriented version (OODTE) 14] of the Domain and Type Enforcement (DTE) [5] policy specification language. Sigma results were focused on policy definition (via OODTE and other policy specification languages) and request interception. The SVE project extended these results by introducing an infrastructure to support shared policy elements for collaborating organizations. ....

L. Badger, D. Sterne, D. Sherman, K. Walker, and S. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, pages 66-77, Oakland, CA, May 1995.

....typically provided by firewalls, but firewalls do not control access rights on a per process basis. Recent research has yielded systems which provide support for defining limited access control domains, but it is not possible to generate a new domain at runtime. Role based access control (RBAC) [1, 9, 33, 35] models permit a user to execute processes using different principals, called roles, which are associated with different access control domains. Thus, two processes run by the same user can have different access rights. However, to create these access control domains, most of these models require ....

....this transform, the principal must have permission to run both x.load and swg.add, so restricting this operation such that only authorized principals can make access rights modifications is straightforward. This model is influenced most strongly by the access control models of Hydra [36] and DTE [1]. Like Hydra, access control on the operations of abstract data types are possible, but access rights in our model are associated with principals rather than the content itself (procedures in Hydra) Therefore, management of rights is simpler and consistent with our applications. Like DTE, access ....

[Article contains additional citation context not shown here]

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In IEEE Symposium on Security and Privacy, pages 66--77, 1995.

....that is stored with a le s meta data and maintained by the le system. At the same time, an increasing number of systems base access control on the name of a resource and not on its meta data. For example, Java security [17] distributed virtual machines [41] and domain and type enforcement [3] rely on central policy descriptions that are based on resource names. Similarly, SPKI [12] uses authorization certi cates that specify the name of a resource. It has already been shown that merging le system permission models is dicult [23] So, settling on any of these models or developing our ....

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, pages 66-77, Oakland, California, May 1995.

....C with A ; C and C ; B, but A 6; B. Now according to the original de nition of purge, rst executing three commands [co 1 ; co 2 ; co 3 ] with dom(co 1 ) A, dom(co 2 ) C and dom(co 3 ) 2 an intransitive interference relation is also possible in domain and type enforcement models [4] [1], but these models do not have a uniform, provable de nition of security, which rules out covert channels. A, and then looking at the output for a fourth command co executed by B should give the same result as looking at the output to co after only executing co 2 : purge will remove both co 1 and ....

....and delappl are invoked by the OS itself as an answer to external requests, while read, write, create, remove and setintsec are called by a currently running (application or channel) program. Our model can be viewed as a simple instance of a domain and type enforcement (DTE) model (see [4] [1]) with two domains OS and application , where the domain interaction table (DIT) is set such that only the OS domain may create or delete subjects and the domain de nition table (DDT) for the domain application is set according to the interference relation (the domain OS can not access ....

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In 1995 IEEE Symposium on Security and Privacy, pages 66-77, Oakland, CA, May 1995. URL: http://www.tis.com/docs/research/secure/secure dte proj2.html.

....included in the FISC security vector (see Subsection 3.5) While the FISC security vector contains a set of Boolean security policy statements, it does not specify a general purpose language for these statements. Related work on network security policy specification languages can be found in [2, 3], and works in progress [6, 23] A framework for quantifying the strength of a set of security mechanisms is described in [30] where high level static security properties can be decomposed hierarchically. However, in [30] the approach cannot accommodate the measurement of how well an executed ....

L. Badger, D. F. Stern, D. L. Sherman, K. M. Walker, and S. A. Haghighat, "Practical domain and type enforcement for Unix," 1995 IEEE Symp. Security and Privacy, May 1995, pp. 66-77.

....variant range specifier ; modifying clause . boolean expression : boolean statement [ or and) boolean statement] boolean statement : LHS boolean operator RHS Note that it is not the focus here to elaborate on a policy representation language. See other efforts and works in progress [2] [3] 5] 16] A given policy component has a value which is a boolean expression. This component may also have an instantiated value with respect to a specific job and format, which is either true or false. A component has a left hand side (LHS) which is the item that is being tested; of ....

Badger, L., Stern, D. F., Sherman, D. L., Walker, K. M., and Haghighat, S. A., "Practical Domain and Type Enforcement for Unix," Proceedings of 1995 IEEE Symposium on Security and Privacy, 1995, Oakland, Ca., pp. 66-77

....that is stored with a file s meta data and maintained by the file system. At the same time, an increasing number of systems base access control on the name of a resource and not on its meta data. For example, Java security [17] distributed virtual machines [41] and domain and type enforcement [3] rely on central policy descriptions that are based on resource names. Similarly, SPKI [12] uses authorization certificates that specify the name of a resource. It has already been shown that merging file system permission models is di#cult [23] So, settling on any of these models or developing ....

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, pages 66--77, Oakland, California, May 1995.

....to extend the OS protection mechanisms to let system administrators specify ne grained mandatory access controls over the interaction between security relevant subjects and objects. A research group at TIS has amassed considerable experience with DTE and its practical application to Unix systems [7, 8, 63, 65]. DTE is an attractive and broadly applicable approach to mandatory access control, but its main disadvantage is that it requires kernel modi cations; we aimed instead for user level protection. More recently, Schneieder has given an automata theoretic treatment of interposition as a ....

Lee Badger, Daniel F. Sterne, David L. Sherman, Kenneth M. Walker, and Sheila A. Haghighat. Practical domain and type enforcement for UNIX. In Proc. 1995 IEEE Symposium on Security and Privacy, 1995.

....anything it wants without any restrictions, just like any ordinary applications. Since most applications (Java applications or ordinary applications) are complicated and big, it is not cost effective (or simply impossible) to prove that the applications are bug free and contain no malicious codes [21, 8, 2, 22]. Moreover, applications may also be affected by computer viruses or by bad input data to cause damages to the end user. Therefore, it is desirable to provide a secure environment for the execution of these (untrusted) applications. In order to limit the damages caused by a misbehavored ....

....applications. Their approach can protect pre existing applications. However, their approach requires the support of Solaris process tracing facility from the underlying OS, which makes their approach OS dependent and cannot be applied to other platforms. Domain and Type Enforcement (DTE) to UNIX [22, 2] is an approach to provide mandatory access control to security related programs and data. Their approach requires kernel modification which is considered be a bad idea in [8] due to the inconveniency and the risk of introducing bugs to security critical kernel. One work related to access control ....

Lee Badger, Daniel F. Sterne, David L. Sherman, Kenneth M. Walker, and Sheila A. Haghighat. Practical domain and type enforcement for unix. IEEE Symposium on Security and Privacy, 1995. http://shadowplay.hq.tis.com/docs/research/operating/dteproj.html.

....and additional user training. This raises a central question for practical UNIX security: can significant enhancements be added in a way that is understandable, effective, and unobtrusive This paper presents our experiences with a new form of access control, Domain and Type Enforcement (DTE) [1] and a prototype DTE UNIX system. In recognition of the fact that access control techniques have not been easily accepted by operating system vendors (or users) DTE has been formulated specifically to address requirements of greatest concern for both vendors and users, namely: flexibility, ....

....a high level language suitable for expressing reusable access control configurations that are compatible with current applications and system configurations. 2. During system execution, DTE file security attributes are not stored one to one with files on 1 DTE is described in more detail in [1]. disk, but are instead maintained implicitly in a form that capitalizes on the directory hierarchy to compactly represent portions of a file hierarchy that have identical attributes. Using implicit typing, DTE can therefore be applied to existing files with no change to file system formats. DTE ....

[Article contains additional citation context not shown here]

L. Badger, D. F. Sterne, D. L. Sherman, K. M. Walker, S. A. Haghighat, "Practical Domain and Type Enforcement for UNIX," 1995 IEEE Symposium on Security and Privacy, Oakland CA, May 1995.

No context found.

L.Badger,D.F.Sterne,D.L.Sherman,K.M. Walker, and S. A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995.

No context found.

Badger, L. Sterne, D.F. et al. (1995). Practical domain and type enforcement for Unix. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, page 66, IEEE Computer Society.

No context found.

L. Badger, D. Sterne, D. Sherman, K. Walker, and S. Haghinghat. Practical Domain and Type Enforcement for UNIX. In Proceedings IEEE Symposium on Security and Privacy (S&P'95), 1995.

No context found.

Badger, L. Sterne, D.F. et al. (1995). Practical domain and type enforcement for Unix. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, page 66, IEEE Computer Society.

No context found.

Lee Badger, Daniel F. Sterne, David L. Sherman, Kenneth M. Walker, and Sheila A. Haghighat. Practical domain and type enforcement for UNIX. In Proceedings of the 1995 IEEE Symposium on Security and Privacy, pages 66--77, Oakland, California, 1995.

No context found.

L. Badger, D.F. Sterne, D.L. Sherman, K.M. Walker and S.A. Haghighat, Practical domain and type enforcement for UNIX, in: Proc. of the 1995.

No context found.

L. Badger and D. F. Sterne and D. L. Sherman and K. M. Walker. Practical Domain and Type Enforcement for UNIX. In IEEE Symposium on Security and Privacy, Oakland, California, May 1995, 66-77.

No context found.

L. Badger, D. F. Stern, D. L. Sherman, K. M. Walker, and S. A. Haghighat, " Practical domain and type enforcement for Unix," 1995.

No context found.

L. Badger, D. F. Stern, D. L. Sherman, K. M. Walker, and S. A. Haghighat, "Practical domain and type enforcement for Unix," 1995.

No context found.

L. Badger et al., "Practical Domain and Type Enforcement for Unix," Proc. IEEE Symp. Security and Privacy, IEEE Press, 1995.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC