Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
Softpanorama Search
|
As filesystems became larger and computers process a larger share of business transactions, the need for data security becomes essential. Even hand written checks are now probably processed by a computer. Twenty years ago, prior to computerization it was standard practice for confidential information to be locked away when not in use. Only authorized personnel were provided with permissions to read, write, amend and delete such information.
It is useful to make a distinction between the general problems involved in making certain that files are not read or modified by unauthorized personnel or by specific operating systems. Access control refers to the overall problem and can be categorized into:
Access control policy is the protection of "whose data is to be protected from whom" and a protection mechanism is the manner by which the operating system enforces the access control policy.
Old Unix systems have at least one user with privileges to every part of the system. The system administrator requires these privileges in order to control the system on behalf of others. This means that the system administrator must have the highest level of security clearance. The privileges conferred to others should then be less than this. In general the less privilege the less chance that accidents will lead to damage or security breaches.
A computer system contains many objects that need to be protected, for example hardware and software. An object has a unique name by which it is referenced and a set of operations that can be carried out on it. For example, read and write are pertinent to a file. Mechanisms are required to:
One way to achieve this goal of protection is by the use of a domain, which is a set consisting of tuples of (object, rights) pairs. Each pair specifies an object and some subset of the operations that can be performed on that object. The objects in each domain can have one of three access rights: read, write and execute. An object that is a member of multiple domains can have different rights in each domain to which it is a member of.
In classic UNIX a protection domain is defined by its UID and GID. Provided with any (UID, GID) combination it is possible to build a complete list of all objects that can be accessed and each objects rights. Two processes with the same (uid, gid) combination, have exactly the same set of objects. Processes with different (uid, gid) combinations, have access to a different set of files.
Additionally, in UNIX each process has two halves: the user part and the kernel part. When a process does a system call it switches from the user part to the kernel part. The kernel part has access to a different set of objects from the user part. A system call therefore invokes a domain switch, from user to kernel.
At every instant in time each process runs in a protection domain. Therefore, there is some collection of objects that the process can access. In addition, each object has a set of access rights. Processes can switch from domain to domain during program execution. Domain switching is highly system dependent. The UNIX process division into user and kernel parts is a legacy of a more powerful domain switching mechanism that was used in MULTICS.
In the MULTICS system the hardware supported up to 64 domains for each process, not the two (kernel and user) like in UNIX or MVS.
A MULTICS process could be considered as a collection of procedures, each running in a domain, called a ring. The innermost ring was the most powerful, the operating system kernel. Radially, moving outwards from the operating system kernel the rings became successively less powerful. When a procedure in one ring called a procedure in a different ring a trap occurred. Once a trap occurred the system had the option to change the protection domain for that process.
|
|||||||
Note: For the history of SOX enforcement in wrong places and auditors feeding frenzy on Section 404 see SOX Related Links
Looks like Red Hat speficic but propbably can be adapted to other distributions.
Feb 26, 2008 | developerworksIf you're concerned about protecting world-writeable shared directories such as /tmp or /var/tmp from abuse, a Linux® Pluggable Authentication Module (PAM) can help you. The pam_namespace module creates a separate namespace for users on your system when they login. This separation is enforced by the Linux operating system so that users are protected from several types of security attacks. This article for Linux system administrators lays out the steps to enable namespaces with PAM.
To improve security, it's often wise to use more than one method of protection (also called "defense in depth"). That way, if one method is breached, another method remains operational and prevents further intrusion. This article describes a way to add another layer of depth to your security strategy: using PAM to polyinstantiate world-writeable shared directories. This means that a new instance of a directory, such as /tmp, is created for each user.
Polyinstantiation of world-writeable directories prevents the following types of attacks, as Russell Coker illustrates in "Polyinstantiation of directories in an SELinux system" (see Resources):
- Race-condition attacks with symbolic links
- Exposing a file name considered secret information or useful to an attacker
- Attacks by one user on another user
- Attacks by a user on a daemon
- Attacks by a non-root daemon on a user
However, polyinstantiation does NOT prevent these types of attacks:
- Attacks by a root daemon on a user
- Attacks by root (account or escalated privilege) on any user
How PAM and polyinstantiation work
PAM creates a polyinstantiated private /tmp directory at login time within a system instance directory; this redirection is transparent to the user logging in. The user sees a standard /tmp directory and can read and write to it normally. That user cannot see any other user's (including root's) /tmp space or the actual /tmp file system.
Polyinstantiated user directories are neither hidden nor protected from the root user. If you are interested in that level of protection, SELinux can help. The configuration examples provided here should work whether or not you have enabled SELinux. See Resources for links to more information about using SELinux.
Enabling polyinstantiationThis section shows you how to enable polyinstantiation of /tmp and /var/tmp directories for users on your system. It also describes the optional configuration steps necessary to accommodate X Windows or a graphical display manager. I used Red Hat Enterprise Linux 5.1 (RHEL 5.1) to write this article, but you can try the procedures described here on any Linux distribution that includes the pam_namespace module.
First we'll edit namespace.conf.
The first file you'll edit is /etc/security/namespace.conf, which controls the pam_namespace module. In this file, list the directories that you want PAM to polyinstantiate on login. Some example directories are listed in the file included with PAM and are commented out. Type
man namespace.confto view a comprehensive manual page. The syntax for each line in this file ispolydir instance_prefix method list_of_uids.
milkeninstitute.org Page 1. GOVERNMENT FAILURE VERSUS MARKET FAILURE Clifford Winston Brookings Institution November 2005 Preliminary draft -- not for quotation
EDITOR'S NOTE: This piece appears in the April 11, 2005, issue of National Review.
Early this year, an unusual full-page ad appeared in the Wall Street Journal and other financial newspapers. The ad attempted to refute claims from businessmen about the costs imposed by the mandates of the Sarbanes-Oxley Act, the "corporate reform" law Congress passed in 2002 after accounting scandals hit Enron, Worldcom, and other companies. Yes, procedures stemming from that law "are neither simple nor inexpensive," the ad said, but the costs are well worth it if the result is restored investor confidence. "The [law's] greater goal and promise," the ad proclaimed, "is that the rigorous demands of compliance can lay the groundwork for improved and more reliable financial reporting, leading to a higher level of public trust."
The ad's message itself was not unusual; it mirrored the standard response the law's defenders give to complaints about cost. A Washington Post editorial intoned, "The nation's corporate chieftains . . . complain about the cost of this new regulation, not pausing to mention the cost of Enron-type scandals." But what this newspaper ad shows is that not all corporate chieftains oppose this law. The expensive ad was not paid for by a pension fund or another group representing the investors the law was intended to serve: Its sponsor was, rather, PricewaterhouseCoopers, the multi-billion-dollar accounting firm making a bundle in fees for doing all the audits the law has ended up requiring of business. By creating so many hurdles for public companies, the law has birthed a golden goose for those who audit them. And ironically, despite the media and legislative clamor to "get" the big accounting firms after Enron imploded, it's the Big Four accounting firms that have turned out to be the big winners from Sarbanes-Oxley.
THE BIG FOUR VS. AMERICA
"Auditors who lost their jobs when Arthur Andersen folded in the wake of the Enron scandal now find themselves up to their ears in work . . . auditing local businesses that are racing to meet Sarbanes-Oxley regulations," the San Jose Mercury News reported in December. According to BusinessWeek, PricewaterhouseCoopers has hired more than 1,600 new auditors and 400 temps from English-speaking lands to perform the extensive audits of businesses. The Big Four are hiring big-time, and have stepped up their recruiting efforts on college campuses: BusinessWeek says KPMG has upped its college recruitment by 40 percent in the last two years. Accounting is now a hot major. A headline in the magazine Practical Accountant summed up the accounting frenzy: "Cash in on Sarbanes-Oxley; reform unleashed a plethora of new and varied engagement opportunities."But what's good for the Big Four isn't necessarily good for America. Other businesses, and ultimately the economy as a whole, are footing the bill for this regulation-driven auditing boom. Mounting evidence shows that the accounting-industry growth generated by Sarbanes-Oxley is coming at the expense of productivity, new jobs, and innovation in the general business world. A survey by Korn/Ferry International found that the law cost Fortune 1000 companies an average of $5.1 million in compliance expenses last year. For middle-market public companies, the law firm Foley & Lardner found that the act has increased the "cost of being public" — everything from audit fees to director insurance — by 130 percent. Substantial man-hours have also been diverted to Sarbanes-Oxley from other, more productive tasks. The industry group Financial Executives International found that the average firm was spending at least 30,700 man-hours a year on compliance with this law. As a result, a number of small U.S. and big foreign firms are rushing to deregister from U.S. stock exchanges — a blow to the U.S. capital markets, and, in turn, to the smaller U.S. companies that depend on these capital markets for financing.
Still, despite business complaints, the administration and the congressional majority — who have other critics, ones accusing them of wanting to repeal the New Deal — show no signs of willingness to scale back what has been called the greatest expansion of federal corporate law since FDR. Congress passed Sarbanes-Oxley less than a month after Worldcom announced it was in serious trouble; it was also six months after Enron's bankruptcy, and three months before the 2002 midterm elections. The Senate, then under Democratic control, had crafted a sweeping corporate overhaul bill by Sen. Paul Sarbanes, Democrat of Maryland. The House had passed a more modest bill by House Financial Services Committee chairman Mike Oxley, Republican of Ohio. When Worldcom announced the earnings restatement that would lead to its bankruptcy, the Bush administration and congressional Republicans went into crisis mode and approved Sarbanes's bill with very minor changes; about the only thing the House Republicans added to the final bill was a provision increasing the jail terms for those convicted of corporate wrongdoing. The bill passed the Senate 99-0, and the House approved it with only three members voting no.
The final product, the Sarbanes-Oxley Act, goes against a 30-year trend of general economic deregulation under Republican and Democratic presidents. It undermines federalism, by going where the federal government has never gone before in areas of corporation law that had long been provinces of the states; UCLA law professor Stephen Bainbridge wrote in Regulation magazine that the act has ushered in "the creeping federalization of corporate law." It regulates the structure and functions of boards of directors, and prescribes the duties of specific employees and board members. Intentionally or unintentionally, the law takes a significant step toward the longtime goal of Ralph Nader and other leftists: federal chartering of corporations. Environmental and labor activists are looking at ways to use the law to launch "shareholder complaints" to force companies to bend to their agenda. As William Greider noted approvingly in a recent cover article in The Nation, this new leftist "reform impulse is different because it seeks to change the system from within, using workers' capital as the driving wedge."
Oxley and the administration are standing firmly behind the law and seem opposed to significant changes in it. When I recently asked Oxley's office for his current views on the law, I was referred to remarks he made early last year at an event with Sarbanes at Washington's National Press Club, in which he said that "the objective ways that you measure this seems to me on the positive side," and that the market had gotten better since the law was passed. As for compliance costs, he said, they "pale in comparison to the costs of corporate fraud that could have occurred without this legislation." Treasury secretary John Snow in a recent BusinessWeek interview praised Sarbanes-Oxley as "critically important legislation" and said Congress didn't need to modify the law.
Meanwhile, the law is fulfilling its promise to create, in President Bush's words at the signing ceremony, "the most far-reaching reforms of American business practices since the time of Franklin Delano Roosevelt." Indeed, one section of the law threatens to become the most extensive day-to-day regulation of American business since FDR's National Industrial Recovery Act, the price-and-output regulatory scheme struck down by a unanimous Supreme Court in 1935. Just as the NIRA created industry boards that had to approve prices and output, Sarbanes-Oxley's Section 404 and its regulatory extensions mandate that the most minute bookkeeping practices have to be okayed by auditors.
PEEKABOO, WE SEE YOU
Section 404 requires that a business's executives sign off on the "internal controls" over financial statements and that the company's outside auditors "attest to" the soundness of these controls. The law also created the quasi-private Public Company Accounting Oversight Board to regulate accountants and set auditing standards. Although the Big Four initially opposed the tougher regulation this body would entail as well as the law's bans on consulting services that can be sold to an audit client, they quickly decided that having the board define "internal controls" as broadly as possible would likely more than make up for their losses. "We love the PCAOB and we love Section 404, especially given the other regulations in the law that affect us," says a staffer in the Washington, D.C., office of a Big Four firm.The PCAOB, non-affectionately referred to as "Peekaboo" by many in the companies that are under its thumb, gave the accountants what they wanted: Last March, it defined internal controls as "controls over all relevant financial statement assertions related to all significant accounts and disclosures in the financial statements." It also defined the law's phrase "attestation" as a full-blown audit of each of these controls, just as the company's numbers have traditionally been audited. In practice, this means that such things as the technology used to derive accounting numbers must be audited every year by the accountants. The board states that "the nature and characteristics of a company's use of information technology in its information system affect the company's internal control over financial reporting." This passage alarms public-company tech employees, because no technology is perfect, and even knowledgeable techies disagree about which is the best software. One public company's chief financial officer says this could mean that an auditor could label a computer with Windows 97, rather than an updated version, a bad internal control.
Daniel Goelzer, a member of the PCAOB, says this isn't likely: "I can't offhand think of a way that using an old version of Windows would make it more likely that your financial statements would be inaccurate." But he adds, "Maybe if there's something about the way that your Windows 95 interacted with the rest of the accounting software at a particular company, maybe it's conceivable." It's really up to the judgment of the individual auditor to decide whether a control passes muster, he says. "We have definitions, but I would certainly say to you that applying those definitions to a particular company requires judgment. That's why auditing's a profession, not a trade."
Yet it's a profession that the law is turning into a mini-regulator. And it's troubling when auditors have the power to second-guess management's best judgment on matters like technology, particularly when this power is combined with other parts of the law requiring "material weaknesses" discovered by auditors to be disclosed to shareholders and establishing criminal penalties for "willfully" disregarding proper accounting procedures. If management, which presumably knows the company better than anyone, has to go against its judgment of what's best to please an auditor, shareholders could lose out as well. And with every new business venture, there's a whole new set of internal controls. This could lead to a slowdown in business investment.
As if all this weren't enough for businesses to cope with, a whole bunch of interest groups now have their own definitions of "internal controls" they want to have imposed. The Oakland-based Rose Foundation for Communities and the Environment has called on the PCAOB to mandate that "independent auditors include reviewing the financial impacts of environmental conditions and environmental liabilities as part of their scope."
Many companies are hurrying to escape Sarbanes-Oxley by leaving the stock exchanges: According to a Wharton study, 198 American companies deregistered from exchanges in 2003, the year after the law was passed — nearly triple the number that deregistered in 2002. Prominent European firms, such as Siemens, are also considering pulling their U.S. listing because of the law. In 2004, the New York Stock Exchange had only ten new foreign listings.
This is clearly a threat to overall economic vitality. Alfred C. Eckert III, CEO of the GSC Partners investment firm, also worries that both Section 404 and the law's mandates for boards of directors will lead to the "bureaucratization" of large American firms: "We're going to have people who are much more bureaucratic . . . and who are frightened and will react in always the most conservative course and will rely on process dictated by lawyers rather than good business judgment." Eckert warns that if Bush and Congress ignore these effects of Sarbanes-Oxley, Bush's planned tax and Social Security reforms will not come to full fruition. "[Sarbanes-Oxley] will make capital more expensive and lower the rate of growth of America. It's very simple."
— John Berlau is the Warren T. Brookes Journalism Fellow at the Competitive Enterprise Institute.
Recommended Links
In case of broken links please try to use Google search. If you find the page please notify us about new location
Rule Set Based Access Control (RSBAC) - Overview
Apache Authentication, Authorization, and Access Control
Apache has three distinct ways of dealing with the question of whether a particular request for a resource will result in that resource actually be returned. These criteria are called Authorization, Authentication, and Access control.
Authentication is any process by which you verify that someone is who they claim they are. This usually involves a username and a password, but can include any other method of demonstrating identity, such as a smart card, retina scan, voice recognition, or fingerprints. Authentication is equivalent to showing your drivers license at the ticket counter at the airport.
Authorization is finding out if the person, once identified, is permitted to have the resource. This is usually determined by finding out if that person is a part of a particular group, if that person has paid admission, or has a particular level of security clearance. Authorization is equivalent to checking the guest list at an exclusive party, or checking for your ticket when you go to the opera.
Finally, access control is a much more general way of talking about controlling access to a web resource. Access can be granted or denied based on a wide variety of criteria, such as the network address of the client, the time of day, the phase of the moon, or the browser which the visitor is using. Access control is analogous to locking the gate at closing time, or only letting people onto the ride who are more than 48 inches tall - it's controlling entrance by some arbitrary condition which may or may not have anything to do with the attributes of the particular visitor.
Because these three techniques are so closely related in most real applications, it is difficult to talk about them separate from one another. In particular, authentication and authorization are, in most actual implementations, inextricable.
If you have information on your web site that is sensitive, or intended for only a small group of people, the techniques in this tutorial will help you make sure that the people that see those pages are the people that you wanted to see them.
(Orange Book) DoD Trusted Computer System Evaluation Criteria, 26 December 1985, dtd 15 Aug 83).
(Green Book) DoD Password Management Guideline, 12 April 1985.
(Tan Book) A Guide to Understanding Audit in Trusted Systems 1 June 1988, Version 2.
(Bright Blue Book) Trusted Product Evaluations - A Guide for Vendors, 22 June 1990.
(Red Book) Trusted Network Interpretation of the TCSEC (TNI), 31 July 1987.
(Amber Book) A Guide to Understanding Configuration Management in Trusted Systems, 28 March 1988.
(Burgundy Book)A Guide to Understanding Design Documentation in Trusted Systems, 6 October 1988.
(Venice Blue Book) Computer Security Subsystem Interpretation of the TCSEC 16 September 1988.
(Aqua Book) A Guide to Understanding Security Modeling in Trusted Systems, October 1992.
(Purple Book) Guidelines for Formal Verification Systems, 1 April 1989.
(Brown Book) A Guide to Understanding Trusted Facility Management, 18 October 1989
(Yellow-Green Book) Guidelines for Writing Trusted Facility Manuals, October 1992.
(Light Blue Book) A Guide to Understanding Object Reuse in Trusted Systems, July 1992.
(Blue Book) Trusted Product Evaluation Questionaire, 2 May 1992, Version 2.
(Purple Book) Trusted Database Management System Interpretation of the TCSEC (TDI), April 1991.
(Yellow Book)A Guide to Understanding Trusted Recovery in Trusted Systems, 30 December 1991.
(Violet Book) Assessing Controlled Access Protection, 25 May 1992.
(Blue Book) Introduction to Certification and Accreditation Concepts, January 1994.
NCSC Technical Report 002: Use of the TCSEC for Complex, Evolving, Mulitpolicy Systems
NCSC Technical Report 003: Turning Multiple Evaluated Products Into Trusted Systems
NCSC Technical Report 005 Volume 4/5: Auditing Issues In Secure Database Management Systems
Capabilities are another way of looking at a protection matrix but by rows. When viewed as a row each process is a list of objects that may be accessed, along with an indication of which operations are permitted on each object, i.e. its domain. This is termed a capability list (C-lists) and individual items within a list are capabilities. Each capability is a tuple composed of (type field, rights field, object field). The type field defines the kind of object, the rights field defines the legal operations on the type of object and the object field is a pointer to the object itself. The capability list shown by Figure 4 is the capability list for domain 2 shown by Figure 2. Capability lists are objects and can be pointed to from other capability lists. Therefore there may be sharing of sub-domains. Capabilities are often referred to by their position in the capability list. For example, a process might say ‘Read 1 K from the file pointed to by capability 2’; this is similar to UNIX file descriptors.
| Type | Rights | Object | |
| 0 | File | r w x | Pointer to File 4 |
| 1 | File | r w | Pointer to File 5 |
| 2 | Printer | - w - | Pointer to Printer 1 |
Figure 4: A capability list
Protection against tampering must be provided. One way of protecting a C-list is by use of a tagged architecture. This is a hardware design in which each memory word has an additional tag bit that denotes whether the word contains a capability or not. Programs executing in kernel part can only modify this tag bit that is by the operating system not the user part. A second way of protecting a C-list is to keep it inside the operating system. Processes must therefore refer to capabilities by there slot number. An example of this is the Hydra. A third way of protecting the C-list is to keep the list in user space but to encrypt each capability with a secret key that is unknown to the user. This is useful for distributed systems such as Amoeba.
In addition to object-dependent rights (r w x), capabilities usually have generic rights which are applicable to all objects, for example:
· Copy capability: creates a new capability for the same object.
· Copy object: creates a duplicate object with a new capability.
· Remove capability: deletes an entry from the C-list and the object remains unaffected.
· Destroy object: permanently removes an object from and a capability.
Many capability systems are organised as a collection of modules, with type manager modules for each type of object. Requests to perform operations on a type (file etc) are sent to the file manager, whereas other requests are sent to other managers, for example a mailbox request would be sent to a mailbox manager. Each request is therefore accompanied by the relevant capability. This leads to a problem: since the type manager module is a program. The owner of a file capability can therefore perform only some of the operations on the file but cannot get at its internal representation. Type module managers must therefore be able to do more with a capability than an ordinary file. This was overcome in Hydra by a technique called rights amplification. Type module managers are given a rights template that provide them with more rights than the capability itself is allowed.
Revoking access to an object is difficult because it is hard for a system to find all the outstanding capabilities, since they may be stored scattered all over a disc. One way to revoke access to an object is to have each capability point to an indirect object, rather than the object itself. This way the operating system can break the link itself and thus invalidate the capabilities. The indirect object was the link is severed points to a null object. Amoeba achieves revoking access to an object by providing a long random number to each object. This random number is also copied to the capability. When a capability is presented for use the two are compared, if the two match the operation is permitted. To revoke access to an object a user simply requests the random number in the object is changed.
The basic model for restricting privilege is to think of the resources which we are trying to protect as objects which can have certain attributes. The subject (the user) then tries to access the objects with a set of credentials based on their identity. A reference monitor stands between users and the objects. It checks the access rights, granting or denying access accordingly.
Subject ---> Access -----> Reference ------> Object request monitorThe monitor checks the attributes. These may tell us two things:
What can be done with an object (by anyone)
What a given user can do with an object
This was one of our design principles. Usually the first of these is just a special case of the latter, e.g. giving permissions to no one prevents anyone from using an object in a certain way. For instance, the Unix execute file flag restricts what one can do with a file, independently of any restrictions on who has, say, read access to it.
There are two basic modes of accessing objects: passive and active, i.e. read-only and read-write. These are referred to by Gollmann as Observe and Alter. The semantics of file access specify what multiple users can do with files with respect to file operations. This has to do with locking (read-only lock, or read-write locks). Look back at the operating systems course notes about locking. The integrity of files, observed by different users can be affected by these semantics. For instance, in Unix, a file can be altered by one process while another process is reading it. This can cause problems. Unix provides a solution based on Discretionary Access Control (DAC) only (the flock() function), other filesystems prevent write access to files while others are reading them forcibly, i.e. Mandatory Access Control (MAC).
In one security model, called the Bell-LaPadula model, the access permissions on files can be set differently in these two cases. We end up with a table or matrix:
| execute | append | read | write
-------------------------------------------------
observe | X | | X |
-------------------------------------------------
alter | | X | | X
-------------------------------------------------
Most models are not this refined. The precursor to most models in use today is the historically important Multics system.
Unix introduced a simple model of file permissions in the 70's which has proven to be quite effective and easy to understand. In recent times, Unix has added a modern approach to file permissions using ACLs, but very few sites have adopted this because of the complexity.
In the original Unix model, each file has three categories of user: User (u), Group (g) and Other (o). Any user can be a member of any number of groups.
Each file has an owner and group attribute, and a set of flags
Read
Write
Execute
for each of the categories. Note that a limitation of this model is that a file can only be a member of one group at a time.
The main limitation of the Unix model is that ordinary users do not have the right to make their own groups. In this way, the model shoots itself in the foot. There are ways around this, but Unix has not introduced a standard solution to the problem. We can think of the Unix model as being a coarse approximation to the model of ACLs.
Many other filesystems have been created at different times. The ACL model is increasingly used, but each filesystem designer seems to introduce their own flags, each with special properties. This makes them very hard to understand for inexperienced users. Other filesystems include AFS, DFS. These filesystems can be added to Unix and other systems and have security properties which are based on the idea of a world-wide filesystem. Unfortunately they are rather complex:
DFS permissions. New files inherit the initial object ACL of their parent directory. These flags can be applied to named lists of users, or groups or others, in the Unix sense. r Ability of open and read a file or directory contents. w Ability to open and write to a file or to add files to a directory. x Ability to execute files as programs or enter directories. d Ability to erase (delete) a file or directory. c Ability to modify file attributes including rename. i Ability to add files to a directory AFS permissions. These flags can be applied to named lists of users, or groups but not `others'. Four shorthand forms also exist write=rlidwk, read=rl, all=rlidwka, and none removes an entry. r Ability of open and read a file or directory contents. l Lookup within a directory. w Ability to open and write to a file. i Ability to insert files in directories. d Ability to erase (delete) a file or directory. a Ability to modify file attributes including rename. k Lock files.
BSD: New files are owned by the creator of the file, default group set from password file. Permissions are determined from the value of umask.
SysV: New files are owned by the creator of the file, default group set from the group of the parent directory (if setgid bit set on parent). Permissions are determined from the value of umask.
POSIX ACLs: This model is almost impossible to understand. It tries to bridge the above Unix properties with an ACL mechanism. Files in directories work as in system 5 Unix but files with ACLs inherit the ACLs of their parent. The default permissions set on files are set from umask, but the effective permissions are some "logical" combination of the Unix permissions and the ACL permissions and an internal ACL mask. This is very confusing. Only the owner of a file can modify the ACL. Not even root can modify another user's ACL.
NT: New files are owned by their creator. They have no special group owner. ACLs are inherited from parent objects unless overidden. New files with no ACL are open to everyone. The exact inheritance mechanism is not well-documented.
Access rights apply not only to secondary storage but to any resource. In particular, the right to communicate with, control or request services from a process. The same basic ideas apply, but access controls usually have different attributes. Process permissions are usually set by access control lists, or on the basis of understood protocols, such as passwords, keys, or cookies (the message in a fortune cookie).
Unix processes have an owner and a group membership. These are normally inherited from the the user who starts the process and from the group attribute of the program file respectively (though see below about setuid/setgid programs). Each process has the privileges afforded to it by these labels.
The basic security of multiuser operating systems lies in the ability to restrict privilege. One of our design criteria was to try to prevent malicious users from circumventing security mechanisms. In some operating systems this has been possible by accidental or deliberate memory corruption. Since software is often buggy, we should not rely on software to behave properly. Stronger measures are needed to protect the system. This was the idea behind two-mode operation (see the operating system course notes). By having system protection hard-coded in hardware, the system is more secure. The Multics operating system generalized this idea to more than two-modes. A series of protection levels or rings was used, each of which encapsulated the inner rings. A typical use of protection rings would be the following:
Operating system kernel
Operating system
Utilities
User processes
In Unix's two-mode operation, only rings 0 and 3 are used. This has made it easy to port Unix to a variety of architectures which support 2-mode operation (e.g PC's including and later than i386).
In a dynamical, interactive situation we could generalize the notion of access to allow users different permissions depending on what they are doing. This can be done in different ways
Define roles for users, (e.g. by membership in privileged groups with access to special systems, like man in Unix.)
By asking a service to carry out an operation, whose abilities have the appropriate privileges for the task (e.g. WWW, telnet, java).
By setting some attribute which determines the allowed permissions for a given task. (e.g Unix setuid programs)
Use of abstract ownership (e.g. polymorphic methods in object oriented languages)
Unix setuid programs are an example where the activities of a program can be changed (by the superuser) so as to grant a specific program the right to operate with a different user-identity and thus privileges (without authentication). The setgid is a corresponding mechanism for setting the group ownership of a process. Note that setuid programs often give more privilege than is necessary and such programs have been the major cause of security problems on Unix platforms.
Finally, let us generalize the idea of access controls by abstracting the procedure of passing through multiple checkpoints or reference monitors.
Suppose we want to ensure that users go through a particular sequence of authentications and access controls. e.g. Think of an airport. First we go through checkin, then passport control and baggage check, then finally the boarding card is checked. It is not possible to carry out these operations in a different order, because the later parts depend on the results of the earlier parts. In some cases, it is possible to go back however, keeping credentials for going forward again.
Non-commutative access is about forcing users to go through access controls in a special order. There might not be a unique combination, but we do require a partial ordering of access controls. If we require N separate controls, then the number of ways from no-access to full-access can be drawn as an N-dimensional cube, called a lattice. N dimensions are hard to visualize, so let us suppose we have only three, labelled (x,y,z).
--------- (x,y,z) / | /| / | / | ---------- | | | | | | / ----- | / | / | / |/ |/ ---------- (0,0,0)The edges of the lattice show the routes from no access to full-access. Different routes through the access control system can be traced by trying to get from one corner of the cube at (0,0,0) (check-in) to the other corner at (x,y,z), which is where we wish to get to (our seat on the aircraft, for instance). We can only move along an edge of the lattice in a given direction if we have access.
Ordered access control means that we can only travel along certain edges of the lattice. Not all of them are open, it is like trying to find a route through a labyrinth to reach the destination.
This is only an abstract representation of the issue of ordered access controls, but it provides a nice way of visualizing what is involved. There is a fundamental connection between ordered lattices and matrix algebras. Try, if you can, to imagine how the lattice would work with more than three dimensions.
| Thought of the week In procedural programming there are local and global variables. In object orientation, there are called public and private objects. How does this relate to access control? How is access granted? Is there any authentication? |
Trusted Computer System Evaluation Criteria: a document published by the NCSC (5200.28-STD) in 1985, containing the evaluation criteria for assessing degrees of assurance in the security features of hardware and software systems. The document is frequently referred to as 'The Orange Book'.
It defines security in classes ranging from D (minimum) to A1 (highly-secure). These classes define the security functions required to meet a specified level of trust, and while most mainframe security systems will meet the class B criteria it is more common to see commercial products being submitted at class C2 functionality. An example of a product classified to C2 level is Windows NT.
Derived Verification Requirements for TCSEC Class C2
"Orange Book" TCSEC
- Trusted Computer Evaluation Criteria
American Department of Defence (DoD).
Local copy
ITSEC Information Technology Security Evaluation Criteria
Local copy
NIAP - NATIONAL INFORMATION ASSURANCE PARTNERSHIP ®
IBM AIX- AIX 4.3.1 TCSEC Evaluated C2 Security (PRPQ)
Access controls are security features that control how users and systems communicate and interact with other systems and resources.
There are two basic types of access control: those that verify who you say you are, and those that verify who you really are. The three basic verification methods are to check
or even some combination of these. In common noncomputer usage, an example of the "what you have" method would be having the key to a padlock; you can get in if you do. "What you know" is the method used to keep other people out of your account; if they don't know your password, tough luck for them. And "what you are" is coming into prominent play in criminal investigations, as DNA patterns are admitted as evidence.
The best security systems use a combination. Your bank's teller machines, for instance, use a combination of the first two methods: you need to have the ATM card, and know the PIN associated with the card (or the account).
But what's all this noise about discretionary and mandatory, you ask? Put simply, discretionary control (DAC) mechanisms check the validity of the credentials given them at the discretion of the user, and mandatory access controls (MAC) validate aspects that the user cannot control. For instance, anyone can give you a username and password and you can then log in with them; which username and password you supply is at your discretion, and the system can't tell you apart from the real owner. Your DNA is something you can't change, though, and a control system that only allowed access to your pattern would never work for anyone else--and you couldn't pretend to be someone else, either. This makes such a system a mandatory (also called non-discretionary) access control system.
In Web terms, and Apache terms in particular, discretionary controls are based on usernames and passwords, and mandatory controls are based on things like the IP address of the requesting client.
Another way to keep discretionary versus non-discretionary controls straight is to think about the way failures are handled: if you fail a discretionary check (such as if you misspell your password), you get another chance--but if a mandatory check fails, you get a "forbidden" error rather than "not authorized," and there's no way to say "give me another chance" without starting from scratch and requesting the page again as though for the first time. And unless something's changed on the server, even retrying isn't going to make a difference; you'll still be locked out.
Authentication versus Authorization
Authentication is the process of verifying that credentials are correct--that is,
that the username is in the database and the password is correct for the username.
Authorization is the process of checking to see if a validated client is permitted
to access a particular resource. For instance, Bob may have correctly supplied his
username and password, but still not be able to access Jane's file because she hasn't
included him in the authorization list for it.
In Apache, almost all of the security-related modules actually do both. The main feature that distinguishes them from each other is their authentication aspect; mostly, they let you store the valid credential information in one or another format. The mod_auth module, for instance, looks in normal text files for the username and password info, and mod_auth_dbm looks in a DBM database for it. They handle the authorization side of their task in essentially identical ways, however.
The security modules are passed the information about what authentication databases to use via directives, such as AuthUserFile or AuthDBMGroupFile. The resource being protected is determined from the placement of the directives in the configuration files; in this example:
<Directory /home/johnson/public_html>
<Files foo.bar>
AuthName "Foo for Thought"
AuthType Basic
AuthUserFile /home/johnson/foo.htpasswd
Require valid-user
</Files>
</Directory>
the resource being protected is "any file named foo.bar" in the /home/johnson/public_html directory or anywhere underneath it. Likewise, the identification of which credentials are authorized to access foo.bar is stated by the directives--in this case, any user with valid credentials in the /home/johnson/foo.htpasswd file can access it.
Mandatory Access Control (MAC) ensures that the enforcement of organizational security policy does not rely on voluntary user compliance. MAC secures information by assigning sensitivity labels on information and comparing this to the level of sensitivity a user is operating at. In general, MAC access control mechanisms are more secure than DAC yet have trade offs in performance and convenience to users. MAC mechanisms assign a security level to all information, assign a security clearance to each user, and ensure that all users only have access to that data for which they have a clearance. MAC is usually appropriate for extremely secure systems including multilevel secure military applications or mission critical data applications. A MAC access control model often exhibits one or more of the following attributes.
Mandatory Access Control (MAC)
Sponsored by DARPA and Network Associates Laboratories. Contributed by Robert Watson.FreeBSD 5.0 includes a new kernel security framework, the TrustedBSD MAC Framework. The MAC Framework permits compile-time, boot-time, and run-time extension of the kernel access control policy, and can be used to load support for Mandatory Access Control (MAC), and custom security modules such as hardening modules. The MAC Framework is currently considered to be an experimental feature, and should not yet be used in production environments without careful consideration. It is anticipated that the MAC Framework will be appropriate for more widespread production use by FreeBSD 5.2.
When configured into a kernel, the MAC Framework permits security modules to augment the existing kernel access control model, restricting access to system services and objects. For example, the mac_bsdextended(4) module augments file system access control, permitting administrators to provide a firewall-like ruleset constraining access to file system objects based on user ids and group membership. Some modules require little or no configuration, such as mac_seeotheruids(4), whereas others perform ubiquitous object labeling, such as mac_biba(4) and mac_mls(4), and require extensive configuration.
To enable the MAC Framework in your system kernel, you must add the following entry to your kernel configuration:
options MACSecurity policy modules shipped with the base system may be loaded using kldload(8) or in the boot loader(8) They may also be compiled directly into the kernel using the following options, if the use of modules is not desired.
Different MAC policies may be configured in different ways; frequently, MAC policy modules export configuration parameters using the sysctl(8) MIB using the security.mac namespace. Policies relying on file system or other labels may require a configuration step that involes assigning initial labels to system objects or creating a policy configuration file. For information on how to configure and use each policy module, see its man page.
A variety of tools are available to configure the MAC Framework and labels maintained by various policies. Extensions have been made to the login and credential management mechanisms ( setusercontext(3)) to support initial user labeling using login.conf(5). In addition, modifications have been made to su(1), ps(1), ls(1), and ifconfig(8) to inspect and set labels on processes, files, and interfaces. In addition, several new tools have been added to manage labels on objects, including getfmac(8), setfmac(8), and setfsmac(8) to manage labels on files, and getpmac(8) and setpmac(8).
The Open Web Application Security Project
1. Introduction
2. Capabilities
3. Capability sets
4. Access Control Lists (ACL)
5. Mandatory Access Control (MAC)
6. Information Labels (IL)
7. Sensitivity Labels (SL)
8. Integrity checking; system recovery
9. Auditing
10. Process/task credentials
11. Acknowledgements
12. Copyright/license for this document
Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Disclaimer:
Last modified: August 10, 2009