Page MenuHomeFreeBSD

Add jail_attach2 syscall
Needs ReviewPublic

Authored by kaktus on May 28 2020, 9:33 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 11 2024, 6:58 AM
Unknown Object (File)
Jan 24 2024, 5:49 PM
Unknown Object (File)
Dec 20 2023, 4:14 AM
Unknown Object (File)
Sep 2 2023, 10:21 PM
Unknown Object (File)
Sep 1 2023, 5:34 AM
Unknown Object (File)
Aug 20 2023, 7:19 AM
Unknown Object (File)
Jul 27 2023, 6:31 AM
Unknown Object (File)
Jul 11 2023, 6:55 AM
Subscribers

Details

Summary

This adds jail_attach2 syscall that behave like a regular jail_attach but allows for passing additional flags.

Right now it can be used to disable ptrace on attached process, with an option of disabling it for child too.

TODO:
man

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 31356

Event Timeline

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#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.