Chroot is just one of the security mechanisms that is used by HP-LX. But I would not highlight this as one of the major security mechanism.
The containment mechanism implemented in HP-LX is something new. By this I mean, you can create "compartments". Every compartment is independent of other compartments. But this does not help much unless you can allow communication between the compartments. This is where "communication rules" come into play. You you can say something like:
Compartment web -> compartment java port 9999 method tcp device eth_lo
You have now created a communication channel that allows a process to talk from the web compartment (your web server) to the java compartment via the loopback device on port 9999.
Additionally, you have the ability set rules on files. You could say:
Here your application running in the web compartment has only "read" access, no matter what the DAC permissions are on any file in the/apache/htdoc directory tree. If you had a file/apache/htdoc/project/index.html which is 666 you would still only have "read" access.
For files in the/apache/logs directory
you give "read,write" access to files in the directory tree.
To me, these are the most important security features provided by HP-LX.
You are right that HP-LX has an audit subsystem. Actually, this audit subsystem can be run on any Linux system. It is not specific to HP-LX.
None of the code for the audit subsystem in HP-LX is from SecureWare. But the lessons learned from SecureWare/VirtualVault is what motivated this audit subsystem.
The audit kernel driver and the audit daemon are all open sourced. The reduction program is not open sourced. (I hope to change that in the future:-) But I have battle on my hands on that one).
The goal of the audit subsystem was to get the audit data out in any format that the user wanted. You could view this audit data in a format that you wanted or you could pipe your audit data into an IDS system of your choice.
HP-LX audit is 1.0 software. It is missing many things. But, after some evaniglizing (sp??), it was a 6 month effort from the "go" word to out the door. So, somethings needed to be cut back on.
And 2 years when the folks who build your "secure" box are gone, you have a company like HP still standing there. I think we can all agree that anyone can create a secure box with all the open source tools that are available now. But, creating the box is only part of the story. Someone has to maintain it, someone has to document what was done to the box (how was it build, etc). With HP-LX you get that in a box. Plug it in, install it and you are off and running in 20 minutes.
HP-LX has no VirtualVault code. There is nothing in HP-LX code that is derived from VV.
A trusted/secure OS should not be your ONLY security mechanism. It is just a part of the overall architecture.
So, what were the goals of this product:
VirtualVault covered the ultra security needs. But at a cost. You needed to intergrate your applications on a VV. You had to teach your sysadmins about VirtualVault. Many smaller shops could not justify the cost of these. So an alternative was created by HP.
Some form os security is better than no security at all. So, what HP wanted to do is lower the complexity of the security mechanism and raise the ease of use. This would allow people to get applications up and running quick on their machine and not have to retrain their systems on a new os.
So, the product had to be:
1. Help protect services on the network boundry. So, this is not designed as a multi-user system. It is designed to protect any type of service that is made available on a public network.
2. Easy to use. Without this, it would be an interesting product, but acceptence by the non-security folks would be hard.
3. Security should not be intrusive. So, as little code change as possible. By this I mean, try not to make changes to user space programs. The admin should be familiar with the environment that he is running in. Only 2 programs are changed, init and xinetd.
4. Sometimes security had to be relaxed in order to keep it easy to use.
These were the four high level drivers for this product.
From a feature set, there are three major components:
1. Containment. Protecting agains ALL buffer overflow attacks is difficult. So, lets contain the damage. Compartments helps us issolate the application from other applications/subsystems on the system.
2. An audit subsystem to be able to watch what is going on on the system. Collection audit does not help if you can't do anything with it. So, it had to be flexible. It is in it's early stages.
3. Lockdown. This mean, locking down most of the permissions on the system. Use tripwire to monitor what is going on on the system. Turn off most of the service that are needed. Generally, do whatever you would do to lockdown a system that is put on a public network.
This should give a little insight into the motivation for the product. This should help shed some light why some decisions where made. The goal of this product to to find a right balance between "ease of use and security". You can be the most secure product, but if it is difficut to use, it will be cast aside. HP-LX is an attempt to achive this balance. More work is needed, but it is the first step...
Slashdot Mirror
Chroot is just one of the security mechanisms that is used by HP-LX. But I would not highlight this as one of the major security mechanism.
/apache/htdoc read
/apache/logs read,write,append
/apache/htdoc directory tree. If you had a file /apache/htdoc/project/index.html which is 666 you would still only have "read" access.
/apache/logs directory
The containment mechanism implemented in HP-LX is something new. By this I mean, you can create "compartments". Every compartment is independent of other compartments. But this does not help much unless you can allow communication between the compartments. This is where "communication rules" come into play. You you can say something like:
Compartment web -> compartment java port 9999 method tcp device eth_lo
You have now created a communication channel that allows a process to talk from the web compartment (your web server) to the java compartment via the loopback device on port 9999.
Additionally, you have the ability set rules on files. You could say:
web
web
Here your application running in the web compartment has only "read" access, no matter what the DAC permissions are on any file in the
For files in the
you give "read,write" access to files in the directory tree.
To me, these are the most important security features provided by HP-LX.
You are right that HP-LX has an audit subsystem. Actually, this audit subsystem can be run on any Linux system. It is not specific to HP-LX.
:-) But I have battle on my hands on that one).
None of the code for the audit subsystem in HP-LX is from SecureWare. But the lessons learned from SecureWare/VirtualVault is what motivated this audit subsystem.
The audit kernel driver and the audit daemon are all open sourced. The reduction program is not open sourced. (I hope to change that in the future
The goal of the audit subsystem was to get the audit data out in any format that the user wanted. You could view this audit data in a format that you wanted or you could pipe your audit data into an IDS system of your choice.
HP-LX audit is 1.0 software. It is missing many things. But, after some evaniglizing (sp??), it was a 6 month effort from the "go" word to out the door. So, somethings needed to be cut back on.
And 2 years when the folks who build your "secure" box are gone, you have a company like HP still standing there. I think we can all agree that anyone can create a secure box with all the open source tools that are available now. But, creating the box is only part of the story. Someone has to maintain it, someone has to document what was done to the box (how was it build, etc). With HP-LX you get that in a box. Plug it in, install it and you are off and running in 20 minutes.
First some clarification.
HP-LX has no VirtualVault code. There is nothing in HP-LX code that is derived from VV.
A trusted/secure OS should not be your ONLY security mechanism. It is just a part of the overall architecture.
So, what were the goals of this product:
VirtualVault covered the ultra security needs. But at a cost. You needed to intergrate your applications on a VV. You had to teach your sysadmins about VirtualVault. Many smaller shops could not justify the cost of these. So an alternative was created by HP.
Some form os security is better than no security at all. So, what HP wanted to do is lower the complexity of the security mechanism and raise the ease of use. This would allow people to get applications up and running quick on their machine and not have to retrain their systems on a new os.
So, the product had to be:
1. Help protect services on the network boundry. So, this is not designed as a multi-user system. It is designed to protect any type of service that is made available on a public network.
2. Easy to use. Without this, it would be an interesting product, but acceptence by the non-security folks would be hard.
3. Security should not be intrusive. So, as little code change as possible. By this I mean, try not to make changes to user space programs. The admin should be familiar with the environment that he is running in. Only 2 programs are changed, init and xinetd.
4. Sometimes security had to be relaxed in order to keep it easy to use.
These were the four high level drivers for this product.
From a feature set, there are three major components:
1. Containment. Protecting agains ALL buffer overflow attacks is difficult. So, lets contain the damage. Compartments helps us issolate the application from other applications/subsystems on the system.
2. An audit subsystem to be able to watch what is going on on the system. Collection audit does not help if you can't do anything with it. So, it had to be flexible. It is in it's early stages.
3. Lockdown. This mean, locking down most of the permissions on the system. Use tripwire to monitor what is going on on the system. Turn off most of the service that are needed. Generally, do whatever you would do to lockdown a system that is put on a public network.
This should give a little insight into the motivation for the product. This should help shed some light why some decisions where made. The goal of this product to to find a right balance between "ease of use and security". You can be the most secure product, but if it is difficut to use, it will be cast aside. HP-LX is an attempt to achive this balance. More work is needed, but it is the first step...
The ReplayTV box is also connected to a phone line if you want to use their TV scheduling capability.