Allow kern.osrelease and kern.osreldate to be set in a jail at creation time.

[• ian]

Summary

Allow the kern.osrelease and kern.osreldate sysctl values to be set in a jail's creation parameters. This allows the kernel version to be reliably spoofed within the jail whether examined directly with sysctl or indirectly with the uname -r and -K options.

While it is possible to override the uname values with environment variables, that is not a reliable technique because env(1) may be used to clean the environment, revealing the underlying os release values. Overriding the sysctl values that uname uses ensures that a consistant lie is told within the jail.

The values can only be set at jail creation time, to eliminate the need for any locking when accessing the values via sysctl.

The overridden values are inherited by nested jails (unless the config for the nested jails also overrides the values).

There is no sanity or range checking, other than disallowing an empty release string or a zero release date, by design. The system administrator is trusted to set sane values. Setting values that are newer than the actual running kernel will likely cause compatibility problems.

Test Plan

Tested on 10.1-stable and 11-current by running an 8.4 jail, and running a freebsd + proprietary build process within the jail that is sensitive to the release and reldate values. Attempts to do so using UNAME_x variables failed due to use of env(1) in the build process, but worked fine using this new feature.

[emaste]

I haven't reviewed the details, but support this change in principle. It has been on my wishlist for some time.

[rpaulo]

Thanks, this is very useful.

[jamie]

I have a few little picky notes :-) ...

You don't need to modify jail(8). The only reason is has some "real" (KP_*) parameters mentioned is that they're hard-coded somewhere in the program, e.g. KP_SECURELEVEL is used for the -s option. It will get any other parameters (including these two) from the kernel.

We still have some pr_spare[] in struct prison; it seems pr_osreldate would best go in one of those slots.

There are a couple places that refer to the non-prison variables, that I think would be better with the prison ones. A couple of sysctl-like emulations (OpenSolaris and SVR4 I think), and imgact_elf.c which sounds like we'd be changing exec/rtld behavior with this (which I suspect is how we want it). Also, there's a per-proc osrel that should probably be set in do_jail_attach.

[• ian]

In D1948#14, @jamie wrote:

There are a couple places that refer to the non-prison variables, that I think would be better with the prison ones. A couple of sysctl-like emulations (OpenSolaris and SVR4 I think), and imgact_elf.c which sounds like we'd be changing exec/rtld behavior with this (which I suspect is how we want it). Also, there's a per-proc osrel that should probably be set in do_jail_attach.

It looks to me like the OpenSolaris values are used only within the kernel, and I think the kernel should not try to lie to itself about version (bad things might happen if a zfs filesystem were accessed using different code inside/outside of a jail because of differing versions in the same kernel).

The svr4 values probably should be changed, but it's going to be a lot of work, will it be worth it? Does anybody still run svr4 binaries on modern systems (in jails where they are spoofing the os version)?

It looks like the per-proc pr_osrel should not be changed, because it's used within the kernel to detect what ABI the binary was built for and adjust behavior accordingly.

It looks like imgact_elf is the one that should change, because it appears to be attaching aux data just to communicate the value over to userland so that getosreldate(3) can get the value without a syscall. I'll get that fixed up, along with your other comments.

[jamie]

Sounds good - thanks for looking into those. I had just kind of looked around at things, mostly because I wasn't all that familiar with osreldate (osrelease is a little easier to digest).

[• ian]

Updates based on review feedback...

• No need to add new jail parms to jail(8) source.
• Move pr_osreldate into one of the pr_spare slots.
• Propagate the pr_osreldate value into the elf aux note when launching an app, so that getosreldate() returns the correct value within the jail.
• Add the two new jail parms to the jail(8) manpage.

[imp]

I love this.

sys/kern/kern_jail.c

990

1 and %d bytes long
and toss the OSRELEASELEN - 1 to the right place (assuming vfs_opterror is a vararg function.

[jhb]

A few nits. I think this is an excellent idea in general though and much better than the env var hack.

sys/kern/kern_jail.c

250

FYI, prison0.pr_cpuset is set in init_main.c in proc0_init(). It probably is best to do the prison0 initialization all in one place either here or there. I probably have a slight preference for doing it there?

4370

RDTUN perhaps? (It it is not at all clear to me when RD vs RDTUN is used here, but from this limited diff it seems like RDTUN might be used for things that can be set at jail creation time in which case this qualifies.)

[rpaulo]

Looks good to me.

sys/kern/kern_jail.c

250

I'd prefer to see it here, as well.

[• ian]

Commited as r279361, not sure why the commit hooks didn't automatically close this.