|
Softpanorama |
||||||
| Contents | Bulletin | Latest | Last year | Top visited | Scriptorama | |
The access control is just another name for compartmentalization of resources.
It is useful to group general problems involved in making certain that files are not read or modified by unauthorized personnel or by specific operating systems under common umbrella -- access control. There are two aspect of access control:
Among them the following are the most important
Classic Unix systems have at least one user with right to access (privilege) any file of the system -- root user. 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 access to 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 role to the kernel role. The kernel role has access rights 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.
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. Radically, 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.
Unix introduced a simple model of file permissions in the 70's which has proven to be quite effective and easy to understand. In this model each file has three attributes for each of three access categories (owner, group and world):
There is also one implicit attribute: the ability to delete file/directory. It is property not a file/directory in question, but the directory in which it contained. It the user has write access to the directory he/she can delete any file in it.
Moreover the execution bit on the directory can work as partial access blocker to files in this directory. It in is not set there is no way to obtain a listing of the directory althouth if you know file name you can access file that is contains in the directory.
Due to popularity of Samba, recently there was a half-baked attempt to extend Unix "xwr" model using ACLs, that are used in Windows.
The result is a mess and very few organization have adopted this approach on Unix servers due to the complexity and bad integration with classic Unix model. Not only existence of the second, by-and-large, indeoendent model confuse administrators, it actually represents a serious security risk.
In the original Unix model, each file has three "rwx" access categories: User (u), Group (g) and Other (o). Group is essentially a role and primary group is a primary role. Any user can be a member of any number of groups, but in Unix groups are atomic -- they cannot contain other groups. This is a serious shortcoming of the classical Unix model.
There is also auxiliary concept of system groups which is similar to the concept of privileged ports. For example, all groups with GID below 100 are usually considered to be system groups. Some system groups are designed mainly for not to providing access to files for a group of users, but for partitioning of permission space. Among them are adm, sys, daemon, lp, mail, uucp, games, ftp. nobody, etc. Typically users which have such "pseudo-group" as primary group have no legitimate shell. Instead /bin/noshell or /bin/false is used; the former logs the access attempts), so nobody can login as such a user. They can be called pseudo-users.
Another severe limitation of this model is that a file can only be a member of one group. That can be partially rectified by usage of "metagroups" -- groups that are just aggregations of existing groups, but that solution requires additional efforts and discipline (in this case /etc/group needs to be automatically generated from some template using macroprocessor). If we assume that the number of group allowed is large (approximately the same as the number of files/directories) metagroup approach is as powerful as ACL model and is much simpler. It requires relatively simple modification of the /etc/group file.
One interesting step toward this model is the concept of User Private Groups (UPG) introduced in Red Hat. UPG scheme makes UNIX groups easier to use. It does not add or change anything in the standard UNIX way of handling groups. This is simply a new convention for handling classic Unix groups groups: whenever you create a new user, by default, he or she has a unique group with GID identical to UID.
One of limitations 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.
For more information see User Private Groups
In the list below, you should note that there are almost no pure BSD or SysV systems left. Most systems are hybrid and support BSD behavior via setgid bit in directories.
BSD: New files are owned by the creator of the file, default group set as primary group for the owner of of the file (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 either from a password file or inherited from the group of the parent directory (if setgid bit set on parent directory). Permissions are determined from the value of umask. So it contains one easily understood extension of BSD model.
POSIX ACLs: This model is almost impossible to understand. It is badly integrated with classic Unix permissions as as such is more or the source of additional security vulnerabilities then additional security. Directories work as in classic Unix, but files with ACLs inherit the ACLs of their parent directory. The default permissions set on files are set from umask, but the effective permissions are calculated from combination of the Unix permissions, the ACL permissions and an internal ACL mask. That's very confusing. Only the owner of a file can modify the ACL. Not even root can modify another user's ACL.
NTFS ACLs: 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. The NTFS filesystem the whole access model is based on ACLs. Each file is owned by a specific user. Each user may belong to any number of groups. Each file has an ACL in which access can be granted or denied to any named list of users and/or groups (i.e. we can either code a rule or an exception to a rule). The access rights of each group or user are taken from the set:
Windows ACLs are closer to the original Multix implementation. Windows 2000 and later provides 14 ACL attributes (In the table below, the # character means this flag is selected only when the Full Control flag is set.):
| ACL | Attribute |
| Full Control | # |
| Traverse Folder/Execute File | x |
| List Folder/Read Data | r |
| Read Attributes | r |
| Read Extended Attributes | r |
| Create Files/Write Data | w |
| Create Folders/Append Data | w |
| Write Attributes | w |
| Write Extended Attributes | w |
| Delete Subfolders and Files | w |
| Delete | # |
| Read Permissions | all |
| Change Permissions | # |
| Take Ownership | # |
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:
By introducing umask or permissions for key files and or directories on per process basis. In the latter form this is the idea behind rather elegant model used in Suse and called AppArmor. The latter used regular expression for determining "effective" permissions for the process. Along with Suse this scheme is used in Ubuntu since April of 2007. If you think about it global static permission used in Unix are anachronism. There should be a mechanism that prevent process from accessing files in, say, /etc directory even if part of the process is running under the root privileges. One approach to this problem was invented by FreeBSD concept of immutable files, the other Solaris RBAC and the this is AppArmor.
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 increases the allowed permissions for a given task. (e.g Unix setuid programs)
By using mounting command restrictions (for example you can prohibit setting setuid/setgid attributed on any mounted filesystem).
Use of OO language-style inheritance models (e.g. polymorphic methods in object oriented languages)
Unix setuid programs are an example where the privileges of a program can be changed (typically increased) by the superuser. They 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 a different group ownership of a process. Note that typically setuid programs acquire more privileges than is necessary (acquiring root privileges is the most common usage of setuid/setgid attributes) and because of that have been the major cause of security problems on Unix platforms. See SUID/SGID attributes for more information.
|
|
|
|||
|
|
||||
| Bulletin | Latest | Past week | Past month | |
Note: For the history of SOX enforcement in wrong places and auditors feeding frenzy on Section 404 see SOX Related Links
Recently there has been much interest in the security aspects of operating systems and software. At issue is the ability to prevent undesired disclosure of information, destruction of information, and harm to the functioning of the system. This paper discusses the degree of security which can be provided under the UNIX# system and offers a number of hints on how to improve security.
The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes. (Actually the same statement can be made with respect to most systems.) The area of security in which UNIX is theoretically weakest is in protecting against crashing or at least crippling the operation of the system. The problem here is not mainly in uncritical acceptance of bad parameters to system calls -- there may be bugs in this area, but none are known -- but rather in lack of checks for excessive consumption of resources. Most notably, there is no limit on the amount of disk storage used, either in total space allocated or in the number of files or directories. Here is a particularly ghastly shell sequence guaranteed to stop the system:
while : ; do mkdir x cd x doneEither a panic will occur because all the i-nodes on the device are used up, or all the disk blocks will be consumed, thus preventing anyone from writing files on the device.
In this version of the system, users are prevented from creating more than a set number of processes simultaneously, so unless users are in collusion it is unlikely that any one can stop the system altogether. However, creation of 20 or so CPU or disk-bound jobs leaves few resources available for others. Also, if many large jobs are run simultaneously, swap space may run out, causing a panic.
It should be evident that excessive consumption of disk space, files, swap space, and processes can easily occur accidentally in malfunctioning programs as well as at command level. In fact
UNIX is essentially defenseless against this kind of abuse, nor is there any easy fix. The best that can be said is that it is generally fairly easy to detect what has happened when disaster strikes, to identify the user responsible, and take appropriate action. In practice, we have found that difficulties in this area are rather rare, but we have not been faced with malicious users, and enjoy a fairly generous supply of resources which have served to cushion us against accidental overconsumption.
The picture is considerably brighter in the area of protection of information from unauthorized perusal and destruction. Here the degree of security seems (almost) adequate theoretically, and the problems lie more in the necessity for care in the actual use of the system.
Each UNIX file has associated with it eleven bits of protection information together with a user identification number and a user-group identification number (UID and GID). Nine of the protection bits are used to specify independently permission to read, to write, and to execute the file to the user himself, to members of the user's group, and to all other users. Each process generated by or for a user has associated with it an effective UID and a real UID, and an effective and real GID. When an attempt is made to access the file for reading, writing, or execution, the user process's effective UID is compared against the file's UID; if a match is obtained, access is granted provided the read, write, or execute bit respectively for the user himself is present.
If the UID for the file and for the process fail to match, but the GID's do match, the group bits are used; if the GID's do not match, the bits for other users are tested.
The last two bits of each file's protection information, called the set-UID and set-GID bits, are used only when the file is executed as a program. If, in this case, the set-UID bit is on for the file, the effective UID for the process is changed to the UID associated with the file; the change persists until the process terminates or until the UID changed again by another execution of a set-UID file. Similarly the effective group ID of a process is changed to the GID associated with a file when that file is executed and has the set-GID bit set. The real UID and GID of a process do not change when any file is executed, but only as the result of a privileged system call.
The basic notion of the set-UID and set-GID bits is that one may write a program which is executable by others and which maintains files accessible to others only by that program. The classical example is the game-playing program which maintains records of the scores of its players. The program itself has to read and write the score file, but no one but the game's sponsor can be allowed unrestricted access to the file lest they manipulate the game to their own advantage. The solution is to turn on the set-UID bit of the game program. When, and only when, it is invoked by players of the game, it may update the score file but ordinary programs executed by others cannot access the score.
There are a number of special cases involved in determining access permissions. Since executing a directory as a program is a meaningless operation, the execute-permission bit, for directories, is taken
instead to mean permission to search the directory for a given file during the scanning of a path name; thus if a directory has execute permission but no read permission for a given user, he may access files with known names in the directory, but may not read (list) the entire contents of the directory. Write permission on a directory is interpreted to mean that the user may create and delete files in that directory; it is impossible for any user to write directly into any directory.
Another, and from the point of view of security, much more serious special case is that there is a ``super user'' who is able to read any file and write any non-directory. T he super-user is also able to change the protection mode and the owner UID and GID of any file and to invoke privileged system calls. It must be recognized that the mere notion of a super-user is a theoretical, and usually practical, blemish on any protection scheme.
The first necessity for a secure system is of course arranging that all files and directories have the proper protection modes. Traditionally,
UNIX software has been exceedingly permissive in this regard; essentially all commands create files readable and writable by everyone. In the current version, this policy may be easily adjusted to suit the needs of the installation or the individual user. Associated with each process and its descendants is a mask, which is in effect and-ed with the mode of every file and directory created by that process. In this way, users can arrange that, by default, all their files are no more accessible than they wish. The standard mask, set by login, allows all permissions to the user himself and to his group, but disallows writing by others.
To maintain both data privacy and data integrity, it is necessary, and largely sufficient, to make one's files inaccessible to others. The lack of sufficiency could follow from the existence of set-UID programs created by the user and the possibility of total breach of system security in one of the ways discussed below (or one of the ways not discussed below). For greater protection, an encryption scheme is available. Since the editor is able to create encrypted documents, and the crypt command can be used to pipe such documents into the other text-processing programs, the length of time during which clear text versions need be available is strictly limited. The encryption scheme used is not one of the strongest known, but it is judged adequate, in the sense that cryptanalysis is likely to require considerably more effort than more direct methods of reading the encrypted files. For example, a user who stores data that he regards as truly secret should be aware that he is implicitly trusting the system administrator not to install a version of the crypt command that stores every typed password in a file.
Needless to say, the system administrators must be at least as careful as their most demanding user to place the correct protection mode on the files under their control. In particular, it is necessary that special files be protected from writing, and probably reading, by ordinary users when they store sensitive files belonging to other users. It is easy to write programs that examine and change files by accessing the device on which the files live.
On the issue of password security, UNIX is probably better than most systems. Passwords are stored in an encrypted form which, in the absence of serious attention from specialists in the field, appears reasonably secure, provided its limitations are understood. In the current version, it is based on a slightly defective version of the Federal DES; it is purposely defective so that easily-available hardware is useless for attempts at exhaustive key-search. Since both the encryption algorithm and the encrypted passwords are available, exhaustive enumeration of potential passwords is still feasible up to a point. We have observed that users choose passwords that are easy to guess: they are short, or from a limited alphabet, or in a dictionary. Passwords should be at least six characters long and randomly chosen from an alphabet which includes digits and special characters.
Of course there also exist feasible non-cryptanalytic ways of finding out passwords. For example, write a program which types out ``login: '' on the typewriter and copies whatever is typed to a file of your own. Then invoke the command and go away until the victim arrives.
The set-UID (set-GID) notion must be used carefully if any security is to be maintained. The first thing to keep in mind is that a writable set-UID file can have another program copied onto it. For example, if the super-user (su) command is writable, anyone can copy the shell onto it and get a password-free version of su. A more subtle problem can come from set-UID programs which are not sufficiently careful of what is fed into them. To take an obsolete example, the previous version of the mail command was set-UID and owned by the super-user. This version sent mail to the recipient's own directory. The notion was that one should be able to send mail to anyone even if they want to protect their directories from writing. The trouble was that mail was rather dumb: anyone could mail someone else's private file to himself. Much more serious is the following scenario: make a file with a line like one in the password file which allows one to log in as the super-user. Then make a link named ``.mail'' to the password file in some writable directory on the same device as the password file (say /tmp). Finally mail the bogus login line to /tmp/.mail; You can then login as the super-user, clean up the incriminating evidence, and have your will.
The fact that users can mount their own disks and tapes as file systems can be another way of gaining super-user status. Once a disk pack is mounted, the system believes what is on it. Thus one can take a blank disk pack, put on it anything desired, and mount it. There are obvious and unfortunate consequences. For example: a mounted disk with garbage on it will crash the system; one of the files on the mounted disk can easily be a password-free version of su; other files can be unprotected entries for special files. The only easy fix for this problem is to forbid the use of mount to unprivileged users. A partial solution, not so restrictive, would be to have the mount command examine the special file for bad data, set-UID programs owned by others, and accessible special files, and balk at unprivileged invokers.
for p in $(rpm -qa); do rpm --setugids $p; done
for p in $(rpm -qa); do rpm --setperms $p; done
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.
This 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.
Internal pages updates by age: Latest : Past week : Past month : Past year
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
Copyright © 1996-2012 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. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
Disclaimer:
Last modified: December 16, 2011