I just had an idea... allow the kernel security level to be specified
for a jailed environment. Add a 'securelevel' field to the jail
structure and bump the API rev.
The kernel uses the higher of the global securelevel and the securelevel
defined by the jail when running
In message [EMAIL PROTECTED], Matt Dillon writes:
I just had an idea... allow the kernel security level to be specified
for a jailed environment. Add a 'securelevel' field to the jail
structure and bump the API rev.
That would be trivial to do, but I thought that securelevels were
:
:In message [EMAIL PROTECTED], Matt Dillon writes:
:I just had an idea... allow the kernel security level to be specified
:for a jailed environment. Add a 'securelevel' field to the jail
:structure and bump the API rev.
:
:That would be trivial to do, but I thought that
:
:In message [EMAIL PROTECTED], Matt Dillon writes:
:I just had an idea... allow the kernel security level to be specified
:for a jailed environment. Add a 'securelevel' field to the jail
:structure and bump the API rev.
:
:That would be trivial to do, but I thought that
* Matt Dillon [EMAIL PROTECTED] [010425 12:24] wrote:
But if we have the ability to run at a higher securelevel inside a jail
we can allow console-root logins to access the system at the global
securelevel of -1 yet force every single other login to the system and
*ALL*
Another cool feature, which would be harder to implement, would be
to have a secondary path for jail which specifies the path under
which filesystem modifications can be made (create files, edit files,
etc...), and outside of which only read access is permitted. This way
you could
Matt Dillon writes:
.
Idea #2: There are a number of sysctl's that effect jails globally,
such as jail_sysvipc_allowed.
Encapsulate these parameters in an internal named kernel structure and
provide system calls to set and retrieve the parameters. e.g.
int
7 matches
Mail list logo
