Disabling ptrace should not be an option, it should be mandatory no matter what.

As noted in other review, the actual solution for what I suspect is the intended use case (inspecting something within the jail) would avoid actually attaching yourself in a manner visible in the jail in the first place.

Considering jail_set(2) can also attach with the JAIL_ATTACH flag, it would be handy to put these new flags in the same space, with a JAIL_ATTACH_MASK including them. Then the attaching done by jail_set can also do the right thing if it chooses.

While the JAIL_ATTACH flag was intended for jail creation imitating the old style of always attaching to a new jail, it's also legal for use with JAIL_UPDATE, i.e. for attaching to an existing jail. Thus you can actually do the attach operation with e.g. jail_setv(JAIL_UPDATE | JAIL_ATTACH, "name", "foo", NULL), which doesn't actually update anything but attaches anyway. That means that a new system call is technically redundant and could just be replaced by adding a new flag to jail_set. That does of course lack the elegance of an improved jail_attach(2).

In D25041#551522, @mjg wrote:

Disabling ptrace should not be an option, it should be mandatory no matter what.

In general I agree, but since this is POLA BSD…

As noted in other review, the actual solution for what I suspect is the intended use case (inspecting something within the jail) would avoid actually attaching yourself in a manner visible in the jail in the first place.

Not really sure about the invisible attachment here, what should happen after fork/exec? Should the child still be invisible?

jexec(8) that use jail_attach(2) is used by rc.d too.

ACK. Wasn't sure about the JAIL_ATTACH namespace anyway.

jail_attach2(2) is just an idea on how to solve the ptrace() and POLA issues :-)

I'll try the jail_set approach.

I'll try the jail_set approach.

I actually like the jail_attach(2) method better - it's more clear to a programmer who wants to attach to a jail.

I would like the flag to be available to jail_set(2) though. That should be as simple as:

`#define JAIL_ATTACH_NOTRACE 0x10
#define JAIL_ATTACH_NOTRACE_NOEXEC 0x20
#define JAIL_SET_MASK 0x3f
#define JAIL_ATTACH_MASK 0x30`

In D25041#551685, @kaktus wrote:

In D25041#551522, @mjg wrote:

Disabling ptrace should not be an option, it should be mandatory no matter what.

In general I agree, but since this is POLA BSD…

It's a super old security bug, not a feature.

As noted in other review, the actual solution for what I suspect is the intended use case (inspecting something within the jail) would avoid actually attaching yourself in a manner visible in the jail in the first place.

Not really sure about the invisible attachment here, what should happen after fork/exec? Should the child still be invisible?

jexec(8) that use jail_attach(2) is used by rc.d too.

Actually entering the jail (e.g., jexec) and trying to do something with resources tied to the jail (ifconfig -j or whatever) require 2 distinct syscalls. The latter should never appear inside.