Want to remove the chroot /var/jail/wp_intranet/dev/null

[zeekha]

Hi Team,

In my security check report I get the file /var/jail/wp_intranet/dev/null is character files crw-rw-rw-   1 bin        bin          3 /var/jail/wp_intranet/dev/null
and

special device files that are not in the /dev directory can be used to gain unauthorized access to the data on the device. Hence we thought of removing it. But doing this could harm something in the web proxy part. In Linux they have a chroot rpm and if that rpm is removed this part gets resolved itself as this null file is also removed.

Now just wanted to have check as Linux do we have any chroot package or some solution to remove it in similar fashion.
Pleae reply on this.

[Patrick Wallek]

With /dev/null there is no "device" with data to access.  The /dev/null device file is a "bit bucket".  If you redirect something to /dev/null it just disappears.

Typical us of /dev/null is something like:

/dir/to/a/script_to_run > /dev/null 2>&1

In the above any output the script generates, error messages or informational messages (anything to stdout or stderr), will get redirected to /dev/null and thus just disappear.

In general having device files that are NOT in /dev is a bad idea.  But I'm not sure there is much of a risk with /dev/null.

[Bill Hassell]

This appears to be something associated with Virtual Vault. What version is HP-UX (uname -r)?

[Matti_Kurkela · Accepted solution]

Apparently your web proxy is protected with a chroot jail: the web proxy process sees /var/jail/wp_intranet as the root directory ("/"), so it cannot access the real /dev directory. Therefore, if the web proxy needs any devices, a copy of each required device must be placed in /var/jail/wp_intranet/dev/ directory. 

Many Unix programs require access to /dev/null, even if the reason for the requirement is not obvious. Removing the /var/jail/wp_intranet/dev/null device would very likely cause the web proxy component to fail.

/dev/null is a very safe device - by definition, any attempt to read data from it should always return only the "end-of-file" response and nothing else. Any data written to it should by definition be discarded.

Reconfiguring the web proxy component to use the real /dev/null instead of the copy in the chroot environmen would mean deconfiguring the chroot jail set-up - in other words, removing a major security feature.

In Linux, a chroot RPM would be an easy way to deploy a "pre-packaged" chroot jail with all the appropriate settings. A RPM could also include install/remove scripts that would change the configuration of some service so that the service works within a chroot jail if the RPM is present, and without the chroot jail if the RPM is removed. If your system configuration is designed to use a chroot jail and security is one of the primary requirements, removing the chroot RPM might not be a good idea.

But if the /var/jail/wp_intranet/dev/null is part of a legitimate security set-up, why is the security check reporting it?

The optimistic answer would be: the security check is testing the system administrator (i.e. you) to see if the administrator can be manipulated to change things without thinking when presented with authoritative-looking recommendations.

But my experience suggests a more pessimistic theory is more likely true: the security check was produced by running some automated tests and listing the deviations compared to some  "standard" system, without really analyzing the findings and without trying to figure out what is their actual impact.

If you got the report by running an automated tool, this is to be expected: the user of such a security checking tool is supposed to do the thinking. In this case, you should verify that it really is a chroot jail, and make sure the major/minor device numbers of /var/jail/wp_intranet/dev/null match the corresponding numbers of the real /dev/null.

But if the report was the result of a paid third-party security audit, I would be somewhat disappointed of the quality of the audit process and would recommend getting someone else to perform audits in the future.

Bill Hassell noticed that this might be a VirtualVault system. If so, be advised that very few generic Unix system auditors will really understand the extra security mechanisms of VirtualVault. This would be another reason to treat the security check report as a raw data that must be analyzed further to identify the real issues.

[zeekha]

Thanks a lot  MK for your clear explanation into this. Now have better idea on to this.