A chroot is actually can be use as isolation, recovery, privilege separation, and honeypotting.
1) Isolation
A chroot environment can be used to create and host a separate copy of the operating system.
Testing and development
A test environment can be set up in the chroot for software that would otherwise be too risky to deploy on a production system.
Dependency control
Software can be developed, built and tested in a chroot populated only with its expected dependencies. This can prevent some kinds of linkage skew that can result from developers building projects with different sets of program libraries installed.
Compatibility
Legacy software or software using a different ABI must sometimes be run in a chroot because their supporting libraries or data files may otherwise clash in name or linkage with those of the host system.
2) Recovery
Should a system be rendered unbootable, a chroot can be used to move back into the damaged environment after bootstrapping from an alternate root file system (such as from installation media)
3) Privilege separation
Chroots are often used as a pre-emptive way of containing a security breach by preventing an unprivileged attacker from doing any damage or probing the host system with a compromised program. An attacker with root privileges, however, may trivially defeat this separation because the chroot does not bar system calls, shield processes outside the chroot from tracing or disallow access to block devices.
4) Honeypotting
In a version of the above, a chroot directory can be populated so as to simulate a real system running network services. However, unlike an actual jail mechanism, chroot does not virtualize system calls, access to block devices or virtual file systems (such as/proc and/sys on Linux). This may make it difficult to conceal the presence of the system outside the chroot.
A chroot on Unix operating systems is an operation that changes the root directory. It affects only the current process and its children. "chroot" itself can refer to the chroot(2) system call or the chroot(8) wrapper program. The "chroot" system call was invented during development of Version 7 Unix, in order to provide a realistic test environment of the distribution being prepared.
A program that is re-rooted to another directory cannot name files outside that directory. This is often misunderstood to be a security device, used in an attempt to sandbox an untrusted, untested or otherwise dangerous program, as if chroot was a working jail mechanism.
In practice, chrooting is complicated by programs expecting at startup to find scratch space, configuration files, device nodes and shared libraries at certain preset locations. To allow programs to spawn inside the chroot directory, it must be populated with a minimum set of these files.
Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also works as a simple capability system, in which the program is explicitly granted access to resources outside the chroot based on the descriptors it can carry in.
Actually by doing this Aurora project can cause injury to the public.
But if the project team can apply IT code of conduct in this project, i think this project
can give many benefits to public, organization, and project team itself.
Below is the several benefits if the Aurora project can apply IT Code of conduct:
1) Can void harm to public
2) Can ensure the good management in the project
3) Can show profesionalism of the organization
Slashdot Mirror
wow.. Using a chroot actually a good action to improve internet security and this should be continued
A chroot is actually can be use as isolation, recovery, privilege separation, and honeypotting. 1) Isolation A chroot environment can be used to create and host a separate copy of the operating system. Testing and development A test environment can be set up in the chroot for software that would otherwise be too risky to deploy on a production system. Dependency control Software can be developed, built and tested in a chroot populated only with its expected dependencies. This can prevent some kinds of linkage skew that can result from developers building projects with different sets of program libraries installed. Compatibility Legacy software or software using a different ABI must sometimes be run in a chroot because their supporting libraries or data files may otherwise clash in name or linkage with those of the host system. 2) Recovery Should a system be rendered unbootable, a chroot can be used to move back into the damaged environment after bootstrapping from an alternate root file system (such as from installation media) 3) Privilege separation Chroots are often used as a pre-emptive way of containing a security breach by preventing an unprivileged attacker from doing any damage or probing the host system with a compromised program. An attacker with root privileges, however, may trivially defeat this separation because the chroot does not bar system calls, shield processes outside the chroot from tracing or disallow access to block devices. 4) Honeypotting In a version of the above, a chroot directory can be populated so as to simulate a real system running network services. However, unlike an actual jail mechanism, chroot does not virtualize system calls, access to block devices or virtual file systems (such as /proc and /sys on Linux). This may make it difficult to conceal the presence of the system outside the chroot.
A chroot on Unix operating systems is an operation that changes the root directory. It affects only the current process and its children. "chroot" itself can refer to the chroot(2) system call or the chroot(8) wrapper program. The "chroot" system call was invented during development of Version 7 Unix, in order to provide a realistic test environment of the distribution being prepared. A program that is re-rooted to another directory cannot name files outside that directory. This is often misunderstood to be a security device, used in an attempt to sandbox an untrusted, untested or otherwise dangerous program, as if chroot was a working jail mechanism. In practice, chrooting is complicated by programs expecting at startup to find scratch space, configuration files, device nodes and shared libraries at certain preset locations. To allow programs to spawn inside the chroot directory, it must be populated with a minimum set of these files. Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also works as a simple capability system, in which the program is explicitly granted access to resources outside the chroot based on the descriptors it can carry in.
Actually by doing this Aurora project can cause injury to the public. But if the project team can apply IT code of conduct in this project, i think this project can give many benefits to public, organization, and project team itself. Below is the several benefits if the Aurora project can apply IT Code of conduct: 1) Can void harm to public 2) Can ensure the good management in the project 3) Can show profesionalism of the organization