Battening down the hatches
How can you implement mainframe-style access control in Unix?
April 1998
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Battening down the hatchesHow can you implement mainframe-style access control in Unix?
|
April 1998
|
Mainframe systems have enjoyed outstanding internal security tools for years. Can you create similarly secure environments on your Unix systems? Chuck Musciano compares mainframe and Unix security environments, with particular regard to access control and resource control. Plus, a few products designed to help bump Unix security up to mainframe-level standards. (2,600 words)
 Mail this article to a friend |
f you want to make a mainframe systems programmer giggle, mention
this oxymoron: Unix security. With a background in
outstanding systems security tools, the typical mainframer is
appalled at the openness and lack of accountability in the Unix
environment. Users log in at all hours, from almost anywhere, and
no one knows who has come and gone. They rummage through
directories, access files, delete data, and no audit records are
ever written. Administrators become root, modify critical system
files, and their trail is never tracked or recorded. Access control
tools are minimal, and centralized security administration is not
provided.
It's tough to argue with those mainframers. Over the years, mainframe security systems have matured into robust, manageable environments that audit and control every aspect of access into a mainframe system. Products like RACF and ACF-2 (for MVS) and ALERT (for VSE) offer features that, until recently, Unix admins could only dream about.
It's important to remember, though, that security in the mainframe world was not built-in from day one. Instead, it evolved as a set of separate products that were installed on top of the base operating system. Similarly, security tools are evolving for Unix, not as part of Unix itself, but as a set of products that you install and configure atop your base Unix installation.
For many sysadmins, "Unix security" entails securing the Unix system from the outside world: installing firewalls, locking down sendmail and other network services, and tightening user password controls. In contrast, mainframe security focuses on internal issues: restricting file access, controlling logins, and managing privileged activity. While no one is disputing the need for good network security, Unix admins often neglect internal issues, assuming that a greater threat exists outside the system than does from within.
Nothing is further from the truth. By some estimates, up to 80 percent of system intrusions and unauthorized accesses are caused by internal users, familiar with the system and given some level of access as part of their job. Without appropriate internal security tools, it is easy to wreak havoc on an otherwise well-secured system.
|
|
|
|
|
Access control
The first goal of any security system is to make sure that the right
people are on the system, at the right time, doing the right
things.
Unix, like any mainframe operating system, uses user name and password authentication to prevent unauthorized users from logging on to the system. Accounts on the system can only be created by a systems administrator with root access. Users can change their passwords as often as they wish, and some systems offer restrictions that force users to choose "good" passwords. As Unix has matured, more secure features, such as password aging, have been added. This forces users to change their passwords periodically, enhancing systems security.
Even with these features in place, however, Unix lacks a critical feature found in most mainframe-class access control packages: access control based on time and location. Traditional mainframe systems often have hundreds, even thousands of users, many of them performing data entry and other "heads down" tasks. The login profiles for these users might restrict their access to the hours between 8 a.m. and 5 p.m., Monday through Friday. Moreover, since these users tend to work in terminal rooms or similar areas, they may only be allowed to log in from one of those terminals. In some shops, each user is restricted to the specific terminal on his or her desk.
These access controls also restrict users with broader access, and even limit the times systems programmers can access the system. System operators may have their access restricted to their shift hours, limited to the machine console only. Systems programmers are often limited to logging in from terminals in secured areas, augmenting login security with physical site security.
Some mainframe security packages allow multiple user profiles to be defined, based on time and location of access. Perhaps you allow your administrators full administrative access when they log in from their desks during normal business hours, but limit their access when they log in across the network or after 7 p.m. Operators that log in during third shift may only be allowed to run backup jobs, while the primetime shift can only manage print services and interactive applications. The possibilities are endless, wonderfully flexible, and ensure that someone with malicious intent will have a much harder time getting into your system.
Resource control
Still, people have been known to
damage systems while logged in, at the right time, from the right
place. The next step in preventing unauthorized access is to
control which system resources a user can access.
Unix has a simplistic access control system: Every resource on the system has permission bits defining the access permissions for the resource owner, members of one defined group of users, and everyone else on the system. The process of defining access rights for a number of users across a large set of files can be tedious, and it's prone to errors. In addition, this method does nothing to create an audit trail that documents which users access which resources on the system.
Mainframe systems use more flexible access controls known as rules-based security. Instead of attaching access privileges to resources, the system maintains a set of rules that define who can access each resource. This rule set is consulted any time any user accesses anything on the system. If a rule exists that allows requested access, the user proceeds. If access is denied, the user is stopped. Either way, the activity can be logged, providing an accurate record of every user's actions on the system.
Rules can be fairly broad, using the Unix equivalent of wildcards to define access rights (or restrictions) for large sets of files. These access rights coupled with robust login security make it impossible for users to access data for which they have not been given permission. Just as important, these systems provide centralized management of access rights, where one security officer can control access for whole user communities. For example, mainframe security allows a single security officer to grant access privileges -- to other users only -- for resources to which he or she has no access.
Recent advances in certain Unix versions have tried to replicate some
of this capability. Solaris 2.6, for example, provides the
setfacl and getfacl commands, which set
and display access control lists assigned to specific files. For
the first time, Solaris users can create a list of users and give
them access to a file, without having to create a group and fiddle
with the file's permission bits. This is a far cry from
mainframe-style resource control, but a big step up from the classic
User/Group/Other style of Unix access control.
Managing privileged access
The biggest hole in the Unix security model is the concept of the
superuser: an account that can access all resources on a system.
Anyone with this access must be completely trusted, because there is
no way to stop them once they're logged in. These users can copy
data, remove files, kill processes, and most importantly, alter
system security parameters to give other users greater access.
Nothing is more frightening in the Unix world than discovering that
your systems administrator has run amok.
Mainframe people cringe at the concept of a superuser. No one user on a mainframe system has this kind of broad access. Systems programmers may have access to system configuration files, but they cannot access sensitive data and do not have the ability to alter access privileges for other users. That responsibility is given to a security officer, who can alter access privileges but has no other access to any system resources. In this kind of environment, it takes two malicious individuals, working together, to thwart security and damage a system.
As frightened as mainframe admins are of unlimited power, Unix admins are terrified of losing it. How, they wonder, can you administer a system without free, untrammeled access to every nook and cranny within it? What if it crashes, and you can't get to the one critical file that needs to be fixed to bring things back online?
Some mainframe shops create an account with global privileges. In this way, they're prepared in the event of some horrible disaster that requires unlimited, immediate access to repair. No one is given the account name or password; instead, it is locked away for safe keeping. When an emergency is declared, the account and password are given to one administrator who proceeds to fix things. Needless to say, every auditing tool and logging mechanism is turned on for this special account, and the lucky user usually has two or three people hanging over his shoulder while logged in.
Controlled privileged access is a wonderful tool. You can give your fledgling administrators access to just those parts of the system you trust them with (printing, say, or tape management) and reserve the scary stuff for your experienced people. Simple commands that require root access, like cancelling print jobs or resetting passwords, can even be granted to first-level support people working at your help desk. Of course, all these accesses are logged, so it's easy to reconstruct what went wrong if mistakes are made.
Filling the mainframe/Unix security gap: Some notable products
So far, we've only looked at the gaps between mainframe and Unix
security. Fortunately, several vendors have stepped up to fill those
gap, bringing mainframe security to the Unix world. What follows is
a sampling of available tools; if you're interested in learning
more, a quick search of the Web will turn up dozens of similar
products and vendors.
These tools come in several flavors. Some wrap control programs and
auditing tools around standard Unix tools, adding a layer of access
control and auditing to commands like login and
su. These wrapped tools are generally less secure and
robust than the replaced versions, but migrate easily when the
operating system is upgraded or patched.
Some vendors go one step further, replacing system utilities with more secure versions. Replacement tools are more secure and less prone to being hacked, but you may wait months for a vendor to release a version of a tool that works with the latest and greatest version of the operating system. In addition, you may want to secure a tool that the vendor never bothered to include in its security suite.
A few security packages make the ultimate leap: They hook into the Unix system trap interrupts, filtering out system calls that need to be secured and validating them before handing them back to the operating system. This is how mainframe security packages have worked for years; Unix shops are only slowly giving way to this solution. The beauty of the solution is that any access, from any application, can be trapped and processed by these packages. The fear is that if the package goes awry you can't regain control of your system. In addition, you face the same version-compatibility issues each time the operating system is upgraded.
If you are looking for better login access control, a package like PowerPassword from SyMark might fill the bill. This tool offers time and location restrictions on logins, supports additional authentication schemes, and offers password aging features. It generates complete audit trails of login activity, and uses multiple authentication servers with automatic failover. The product does not replace or modify system utilities and is available for all popular Unix environments.
If you want to move beyond login control and restrict privileged access, the OmniGuard product line from Axent Technologies could be the right choice. These products offer all of the login control features of PowerPassword, but go on to support restricted root access with better auditing capabilities.
The OmniGuard Unix Resource Manager centralizes Unix account management within a single console for multiple Unix systems. Account management capabilities can delegated to a single person who need not know the account definition rules for disparate Unix systems. Instead, the administrator can specify consistent access rules for your user community and correctly implement them on a variety of Unix systems.
OmniGuard Unix Privilege Manager allows a subset of root access to be given to users while providing a complete audit trail of user activity. For example, you can use the OmniGuard/URM scripting language to grant your Oracle database administrators the ability to kill and restart any process owned by Oracle, and provide the ability to restart databases on the system. Because OmniGuard/URM provides full auditing down to the keystroke level, you can create a fully privileged root account that your admins can use, giving them full access to the system while logging everything they do.
The OmniGuard products use a mixture of wrapping and replacement tools to enforce their security policies. They are fairly flexible, and the scripting language is easy to use.
If you are ready to step up to the big league, a product like AutoSecure from Platinum Technology is right up your alley. Like its mainframe brethren, AutoSecure hooks the Unix system trap, applies various security rules to appropriate system calls, and provides outstanding system security for those disciplined enough to take advantage of it. AutoSecure (and its twin, SeOS, from Memco Software) offers centralized security management, rules-based security with wildcards, restricted login controls, network security, and full auditing and reporting.
Most importantly, AutoSecure allows you to prevent root from gaining
full access to the system. Unlike wrapped tools and replacement
binaries, AutoSecure can keep anyone with root access from getting
to specific system resources, while granting that access to
conventional users. AutoSecure also has interesting features that
protect against Trojan horses and viruses, capturing checksums of
system utilities and alarming when attempts are made to change those
files. AutoSecure will even find and catalog every binary on your
system that runs with the setuid bit on, and let you know if those
programs are modified.
What now?
As I noted, this is just a sampling of available security tools,
showing the range of what is available. If you are serious about
security, you need to determine what is right for your system, your
users,and your budget, and act accordingly. In terms of bringing your Unix environment up to the security enjoyed by mainframe systems, the only mistake you can make is to do nothing.
|
|
Resources
About the author
Chuck Musciano has been running various Web sites, including the
HTML Guru Home Page,
since early 1994, serving up HTML tips and tricks to hundreds of
thousands of visitors each month. He's been a beta tester and
contributor to the
NCSA httpd project
and speaks regularly on the Internet, World Wide Web, and related topics. Chuck is currently CIO at the American Kennel Club.
Reach Chuck at chuck.musciano@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright98.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-04-1998/swol-04-unixsecurity.html
Last modified: