By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I think [the priority list] flows like this: You need a good, secure configuration. If that's done and deployed, you focus on understanding updates to programs. In other words, you want to look at all package updates and know what was fixed and if you need to update for it. Aside from that you need a good monitoring technique to ensure the systems you so carefully configured stay that way. Having a good handle on monitoring the security events being generated is one of the more important things to do assuming that a system is properly configured. You need to understand what's recorded in the security logs so that one day, when something odd shows up, you can spot it immediately. What is the most immediate threat to system security in business settings?
It all depends on risks. If they have lots of non-Linux machines that users or malware can install programs on, they need to address that issue. If, on the other hand, users are confined to where they can't install apps, I would look at ensuring that machines stay in configuration.
My team draws on our familiarity with the source code as well as known security principles [for] Linux and Unix. Most of the work that we do is applying the least privilege principle, which states that all administrators should be granted the least access possible while still being able to perform their roles. We also create new security mechanisms to allow our customers to meet regulatory or security requirements. We also review source code for security problems of all sorts. We do find problems that affect all Linux distributions and share the solution as well. Does this differentiate Red Hat from other distributions?
Two things define Red Hat in the security space. We have worked hard to meet many security targets both for government and industry. This means incorporating projects and packages that solve problems but also starting projects when none exist.. The other thing is that the work we do is shared immediately for any and all distributions to use. For example, the problems that we fixed or enhancements needed in order to meet the LSPP [Labeled Security Protection Profile] certification were sent to the original author(s) so that updated code could be released at the next opportunity. What are security configuration tool SELinux Troubleshooter's weak spots?
In the past, it could not analyze policy to determine if changing a Boolean would in fact cure a problem. This meant that security administrators had to use a lookup table every time a change was being considered. Recent work has fixed this so that it can parse the policy and determine algorithmically if a Boolean can solve a problem. Does Troubleshooter assume that users have a certain level of proficiency with software security language?
It does assume some basic knowledge about Linux and SELinux. It typically gives very explicit action items to solve the problem. It should be noted that you cannot make any changes to the host's configuration unless you have root privileges. So I think in practice that means only admins will be able to use its output, and they should know what it's saying to do. Has the tool improved?
Yes … analytical capabilities are improving. It can also now run off aggregated audit logs and correctly attribute problems to a specific host and offer to run the command in the remote host. This may seem like a small thing, but it shows that we see an expanded role for this tool to let admins know what is going on in their data center. In terms of best practices, should you audit a system every time you install a new application or modify it?
From a security perspective, yes that would be a good practice. Generally it's a simple process of checking to see what resources are currently being used. If the app runs as root, one would want to see if it can run under a less privileged account or if it's possible to add SELinux policy around it. How much effort should you put into running audits versus configuring a system to match ongoing security needs?
The basic idea is that once you set up a system securely, you want to make sure that it stays that way and is not weakened by accident. If the audits are automated, you can do it often and it doesn't [require] that much effort. When is it preferable to keep listening daemons on, and when should you turn them off? You would want to keep listening daemons on whenever you intend to use them and have them properly configured. For example, if you remotely access a server, you would want to keep sshd enabled, but you would also want to adjust tcp_wrappers and iptables settings to restrict which networks can attempt to log in. You would want them turned off in cases where they are network-facing, running as root, not configured, or simply don't apply to the hardware the OS is installed on. Examples of this might be Avahi or the ISDN daemon. What core daemons and features should system administrators have in their configuration to protect themselves from attack?
There are two parts to security. One is access control, and the other is audit trail. Regarding access control, SELinux is the most useful feature to consider for preventing a security breach of one application from becoming a complete system compromise. If an attacker gets into the system from a daemon, then they will be limited to the access rights allowed to just that daemon. This brings us to the second aspect, which is audit trail. This can be the syslog messages that applications send or the actual audit logs. Anytime an access decision is denied by SELinux and logged, it will go to the audit system if that is running. In a production environment, one would want to strive to follow file and directory layouts that SELinux is expecting so that the data is labeled correctly. If one does this, in theory you should not get any events unless you have a potential intruder. Caroline Hunter is an assistant editor at SearchEnterpriseLinux.com. Write to her at email@example.com. And check out the Enterprise Linux Log.