During his LinuxWorld Conference & Expo session in San Francisco August 6-9, Lingel will discuss why you don't know as much as you think you do when it comes to your users and their authentication. He'll discuss a bevy of little-known Linux tools and techniques for determining user access privileges on Linux systems. Recently, Lingel sat down with SearchEnterpriseLinux.com for an interview on Linux security and the tools that administrators can use to determine who's doing what on their systems.
Kurt Lingel: They should ask, "Who has access, and what do they have access to?" Users have to sign off on the idea that they are the data owners, and therefore they are the only person with access to that data. The concern with that way of thinking is that there are often people in an organization who have special-access privileges, yet the data owner has no real knowledge of who is accessing data. I'll show attendees the manual methods to find who else has access to what. I'll go into detail and look at specific tools for databases like MySQL and Oracle and then talk about internal mechanisms in specialized applications that handle security and access internally.
Well, a DBA [database access administrator] would know about user access within their database, and whoever is taking care of Web applications would log their users and know who has access to which files, but what happens is people who own all of the data -- [the IT managers] -- they don't know how to use the specific Linux tools that exist for each of those technologies. Typically, they are not as familiar with how to audit who has access to what in, say, a Web server environment. Who is your target audience for your session? Is it the Linux guy looking to brush up or a Windows admin looking to manage Linux in his heterogeneous data center?
Originally I was thinking the LinuxWorld session should target the people in charge of compliance and auditing, as well as those in charge of the day-to-day enforcement and granting of access. But even your typical help desk worker would get something out of it, because they get calls that relate to access and security all the time. Above all, the people who need to understand that these tools exist are those security-minded people who are charged with generating the compliance and security policies within an enterprise.
Sure, we all know about these questions. Who has access? Who has access to which files? But sometimes security folks haven't asked their administrators things like, "Hey, I really do need a detailed report on all these programs and whatever special privileges they might have." It's the same thing with the database owner. Or maybe I am the owner of the financial applications, and I believe I've given a specific user access to it, but low and behold, there's access elsewhere. And whoever is in charge of data store maintenance, do those people know there are special programs or individuals within an organization with special access privileges? Are you comfortable with that? There are many obvious questions, but IT managers might not ask them often enough. What do you think makes Linux security so unique?
There are a lot of extensions that have been added to it. I've been a fan of the way the whole pluggable authentication module [PAM] stuff has been implemented, because it means we've been given technology like multifactor authentication and fingerprint/password combinations [ Editor's note: Pluggable authentication modules are mechanisms to integrate multiple low-level authentication schemes into a high-level application programming interface, which allows for programs that rely on authentication to be written independently of the underlying authentication scheme.] Basic file system and groups, though -- stuff like that -- are very comparable to other Unix systems. At LinuxWorld, you plan to cover access and identity issues for a variety of platforms, including Web servers and databases. Is there an area where Linux security management has become especially challenging?
Databases are one thing that is often overlooked. DBAs have access to most of the data in there, so IT managers will set them up as if they are in total control of all the data and access privileges. Managers who own all of the data in the IT environment don't have as much knowledge as they should about these databases.
Another challenge is applications that come bundled with their own internal security. In these cases, how do you know that these applications aren't doing something in such a way that it has more access to data than it needs? For example, I have a program, and that program has to run with root access on Linux and has to be able to log into the database. It will do its own security check. These applications that have their own internal security are becoming very hard for people to say, "Do I really understand who has access to what in my network?" In these cases, you rely on a vendor to publish schemas and to do their own audits on the applications.What are some real-world examples of these self-contained security applications?
Oracle Financials, or even SAP or PeopleSoft. When a user deploys these applications, and they log in to it and then do something like update an HR file for an employee's salary, for example. The thing is all of the security for that transaction is handled and managed internally by the database. If someone had the authority to audit that database, then in reality they actually have the ability to control access to that database. Users need to ask if there is access available to that database from outside the application. Managers really need to be sure they know if it is just the HR folks, in this case, that have access and auditing privileges for people's salaries, and why. Basically, IT mangers need to keep asking questions -- "Do I know who has access to what?" -- over and over again.
Email Jack Loftus with your comments and suggestions.