GSoC Idea: per-process filesystem namespaces for FreeBSD

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GSoC Idea: per-process filesystem namespaces for FreeBSD

Theron Tarigo
Hello All,

I am an undergraduate a Boston University looking to contribute to
FreeBSD this summer under GSoC.

The idea I would like to implement is to bring to FreeBSD a per-process
mounting / namespaces functionality similar to that of the Plan9
operating system as a means to give greater flexibility in combination
with less overhead than is associated with chroots and jails for
purposes of isolating software setups from one another and from the
underlying system.

For those unfamiliar with Plan9, here is a rough explanation of the
namespace feature: unlike in Unix, where all processes share the same
virtual filesystem, each process instead has its own view of the
filesystem according to what has been mounted, which, unlike Unix mount,
as an unpriviliged operation changing only what is seen by the
particular process and any processes it later spawns.  Thus it is
possible for one process's /bin to be completely different from another
process's /bin, and neither need be the same as the system's /bin,
should one exist.

As an example of its application and potential usefulness, a user may
mount on top of /usr/local an overlay pointing to a location owned by
the user, allowing existing binary packages which expect a /usr/local
PREFIX to be installed and run without any modification either to the
binary packages or to the underlying system.  Currently the only ways to
achieve this are by recompiling ports with a different PREFIX or by
configuring a jail.  Some, but not all, programs will function
out-of-place under tweaked PATH and LD_LIBRARY_PATH, but this is not a
general solution and leads to messy environments.

Although I have not previously worked with kernel programming in
particular, I have good experience of high-level practices and low-level
details of C programming and I can teach myself new technical details
quickly.  In researching how to approach the task, I will study the
existing implementation of chroot, jail, and fdescfs as examples of
process-specific namespace behavior already supported in FreeBSD
kernel.  The nullfs and unionfs may also serve as work to build off of,
although unionfs as currently implemented appears to be partially broken.

Robustness of the implementation allowing, it should eventually be
possible to replace system directories /bin, /sbin, /etc, etc. with
bindings configured at boot time to improve the safety of live system
upgrades and to provide a means of returning to older configurations
which is not dependent on filesystem-specific snapshotting features.

Although per-process filesystem namespacing is unconventional in the
face of the dominant Unix single-namespace model, introducing the
feature to a Unix-like system does not constitute a radical change, as
it is compatible with and indeed facilitates the meeting of the
reasonable expectation of existing and unmodified software to find
resources in predetermined file paths.

My attempt here to outline the relevant concepts is to the best of my
limited understanding.  Hopefully I am not creating or propagating any
misinformation and have not grossly misassessed the complexity of the task.

I would greatly appreciate any suggestions of approaches to this task
and of who to contact for more expertise and for potential mentorship.

Thanks,
Theron Tarigo
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Konstantin Belousov
On Tue, Mar 13, 2018 at 12:53:18PM -0400, Theron wrote:

> Hello All,
>
> I am an undergraduate a Boston University looking to contribute to
> FreeBSD this summer under GSoC.
>
> The idea I would like to implement is to bring to FreeBSD a per-process
> mounting / namespaces functionality similar to that of the Plan9
> operating system as a means to give greater flexibility in combination
> with less overhead than is associated with chroots and jails for
> purposes of isolating software setups from one another and from the
> underlying system.
>
> For those unfamiliar with Plan9, here is a rough explanation of the
> namespace feature: unlike in Unix, where all processes share the same
> virtual filesystem, each process instead has its own view of the
> filesystem according to what has been mounted, which, unlike Unix mount,
> as an unpriviliged operation changing only what is seen by the
> particular process and any processes it later spawns.  Thus it is
> possible for one process's /bin to be completely different from another
> process's /bin, and neither need be the same as the system's /bin,
> should one exist.
>
> As an example of its application and potential usefulness, a user may
> mount on top of /usr/local an overlay pointing to a location owned by
> the user, allowing existing binary packages which expect a /usr/local
> PREFIX to be installed and run without any modification either to the
> binary packages or to the underlying system.  Currently the only ways to
Do you understand what consequences of this feature is, when mixed with
setuid ?

> achieve this are by recompiling ports with a different PREFIX or by
> configuring a jail.  Some, but not all, programs will function
> out-of-place under tweaked PATH and LD_LIBRARY_PATH, but this is not a
> general solution and leads to messy environments.
>
> Although I have not previously worked with kernel programming in
> particular, I have good experience of high-level practices and low-level
> details of C programming and I can teach myself new technical details
> quickly.  In researching how to approach the task, I will study the
> existing implementation of chroot, jail, and fdescfs as examples of
> process-specific namespace behavior already supported in FreeBSD
> kernel.  The nullfs and unionfs may also serve as work to build off of,
> although unionfs as currently implemented appears to be partially broken.
>
> Robustness of the implementation allowing, it should eventually be
> possible to replace system directories /bin, /sbin, /etc, etc. with
> bindings configured at boot time to improve the safety of live system
> upgrades and to provide a means of returning to older configurations
> which is not dependent on filesystem-specific snapshotting features.
>
> Although per-process filesystem namespacing is unconventional in the
> face of the dominant Unix single-namespace model, introducing the
> feature to a Unix-like system does not constitute a radical change, as
> it is compatible with and indeed facilitates the meeting of the
> reasonable expectation of existing and unmodified software to find
> resources in predetermined file paths.
>
> My attempt here to outline the relevant concepts is to the best of my
> limited understanding.  Hopefully I am not creating or propagating any
> misinformation and have not grossly misassessed the complexity of the task.
>
> I would greatly appreciate any suggestions of approaches to this task
> and of who to contact for more expertise and for potential mentorship.

You need to understand a lot about the FreeBSD VFS to sketch the
approach for implementation.  I do not want to sound sceptical, but
the amount of architectural work, and then the quantity of the details
to discover and handle for this project certainly exceed the scope of
GSoC.

If you can formulate the basic ideas of the possible implementation, this
might add more substance to the discussion.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Kristoffer Eriksson-2
In reply to this post by Theron Tarigo

On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> For those unfamiliar with Plan9, here is a rough explanation of the
> namespace feature: unlike in Unix, where all processes share the same
> virtual filesystem, each process instead has its own view of the
> filesystem according to what has been mounted ...

What if I mount a new /etc with a passwd file where root has no
password, and then run "su"?

(How does Plan9 handle that?)

Regards/Kristoffer Eriksson
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Theron Tarigo
Hi Kristoffer,

That will of course need to be worked out, since it is the classic
safety problem  of chroot.  The first idea I can think of is that any
user-switching (i.e. executing setuid files) resets the namespace,
similarly to "su - " resetting the environment variables by way of
simulating a new login.  Maybe it will not work out to be so simple, as
I can see there will be a lot of research ahead for me, but I feel
strongly that it will not be insurmountable.  If I implement this as a
special filesystem rather than as a modification to the vfs, it can be
as simple as not allowing any setuid, as with the "nosuid" option of
existing filesystems.

As I understand it, Plan9 uses namespaces so thoroughly that a superuser
is not needed and all restrictions of privilege are accomplished through
launching "unprivileged" processes into a namespace that contains only
the resources that user should have access to.  While this may make
sense within Plan9, it is sufficiently alien to the Unix ways of
handling security that I don't think it makes any sense to try to do
things this way on FreeBSD.  There will probably always be security
risks associated with anything running as uid 0 regardless of
restrictions to its environment.*  What I am trying to accomplish is to
stay roughly within the Unix model but to provide a layer of flexibility
appropriate for addressing a specific need, and the solution I have in
mind happens to parallel a Plan9 concept.

Theron


* """
      In addition, there are several ways in which an unprivileged user
outside
      the jail can cooperate with a privileged user inside the jail and
thereby
      obtain elevated privileges in the host environment.
""" - JAIL(8) manual

On 03/13/18 15:55, Kristoffer Eriksson wrote:

> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
>> For those unfamiliar with Plan9, here is a rough explanation of the
>> namespace feature: unlike in Unix, where all processes share the same
>> virtual filesystem, each process instead has its own view of the
>> filesystem according to what has been mounted ...
> What if I mount a new /etc with a passwd file where root has no
> password, and then run "su"?
>
> (How does Plan9 handle that?)
>
> Regards/Kristoffer Eriksson

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Warner Losh
In reply to this post by Kristoffer Eriksson-2
On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:

>
> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> > For those unfamiliar with Plan9, here is a rough explanation of the
> > namespace feature: unlike in Unix, where all processes share the same
> > virtual filesystem, each process instead has its own view of the
> > filesystem according to what has been mounted ...
>
> What if I mount a new /etc with a passwd file where root has no
> password, and then run "su"?
>
> (How does Plan9 handle that?)
>

Plan9 handles that by having a daemon that does user authentication. It's
actually more complicated than that, but the machine owner has control over
who can do what. For this to work in FreeBSD, either we'd need to disallow
the 'file' type for passwd, or we'd have to do something sensible with
setuid programs. Well, maybe not 'or' but 'and' since the security of
setuid programs depends on the security of the filesystem.... Plan 9
doesn't have these complications, so it can offer a user malleable
filesystem without security risk.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Bakul Shah
On Tue, 13 Mar 2018 15:43:08 -0600 Warner Losh <[hidden email]> wrote:
Warner Losh writes:

> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
>
> >
> > On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> > > For those unfamiliar with Plan9, here is a rough explanation of the
> > > namespace feature: unlike in Unix, where all processes share the same
> > > virtual filesystem, each process instead has its own view of the
> > > filesystem according to what has been mounted ...
> >
> > What if I mount a new /etc with a passwd file where root has no
> > password, and then run "su"?
> >
> > (How does Plan9 handle that?)
> >
>
> Plan9 handles that by having a daemon that does user authentication. It's
> actually more complicated than that, but the machine owner has control over
> who can do what. For this to work in FreeBSD, either we'd need to disallow
> the 'file' type for passwd, or we'd have to do something sensible with
> setuid programs. Well, maybe not 'or' but 'and' since the security of
> setuid programs depends on the security of the filesystem.... Plan 9
> doesn't have these complications, so it can offer a user malleable
> filesystem without security risk.

Plan9 has no root (superuser) or setuid.  You can mangle
anything in your namespace but it affects only *your* own
process and its future descendents.

The following paper on Plan9 authentication in Linux may be
worth reading:
    https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34433.pdf

While I have wanted per-process namespace in BSD for a long
time, I agree with Konstantin this is a non-trivial project.
Even if the design was fully fleshed out, implementing it
would likely take longer than 12 weeks.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Mark Saad-5
In reply to this post by Warner Losh

> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
>
>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
>>
>>
>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
>>> For those unfamiliar with Plan9, here is a rough explanation of the
>>> namespace feature: unlike in Unix, where all processes share the same
>>> virtual filesystem, each process instead has its own view of the
>>> filesystem according to what has been mounted ...
>>
>> What if I mount a new /etc with a passwd file where root has no
>> password, and then run "su"?
>>
>> (How does Plan9 handle that?)
>>
>
> Plan9 handles that by having a daemon that does user authentication. It's
> actually more complicated than that, but the machine owner has control over
> who can do what. For this to work in FreeBSD, either we'd need to disallow
> the 'file' type for passwd, or we'd have to do something sensible with
> setuid programs. Well, maybe not 'or' but 'and' since the security of
> setuid programs depends on the security of the filesystem.... Plan 9
> doesn't have these complications, so it can offer a user malleable
> filesystem without security risk.
>
> Warner

 A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like “ FreeBSD needs a proper stacking vfs ...”   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs’s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .

Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server .

 http://netbsd.gw.com/cgi-bin/man-cgi?multiboot+8+NetBSD-current
http://ipxe.org/


---
Mark Saad | [hidden email]

> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Warner Losh
On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]> wrote:

>
> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
>
> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
>
>
> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
>
> For those unfamiliar with Plan9, here is a rough explanation of the
>
> namespace feature: unlike in Unix, where all processes share the same
>
> virtual filesystem, each process instead has its own view of the
>
> filesystem according to what has been mounted ...
>
>
> What if I mount a new /etc with a passwd file where root has no
>
> password, and then run "su"?
>
>
> (How does Plan9 handle that?)
>
>
>
> Plan9 handles that by having a daemon that does user authentication. It's
> actually more complicated than that, but the machine owner has control over
> who can do what. For this to work in FreeBSD, either we'd need to disallow
> the 'file' type for passwd, or we'd have to do something sensible with
> setuid programs. Well, maybe not 'or' but 'and' since the security of
> setuid programs depends on the security of the filesystem.... Plan 9
> doesn't have these complications, so it can offer a user malleable
> filesystem without security risk.
>
> Warner
>
>
>  A kind of related task; FreeBSD could benefit from : Fixing  and
> improving unionfs / nullfs. There are some weird issues with the current
> unionfs and while it works in many cases there are some edge cases where
> the comments are something like “ FreeBSD needs a proper stacking vfs ...”
>   the examples I can think of ; imagine you have a jail , chroot or even a
> Pxe booted system where you want a a read only null mount from the hosts
> /bin to the targets /bin . Now expand that to most of the base system and
> the mount tmpfs’s for /tep /var/log etc.  most of that works but try to
> unmount it in the wrong order or thrash a unionfs with lots of writes ,on
> top of a tmpfs and things break .
> So to be clear the project would be to better document the various uses of
> unionfs and nullfs that work , for the ones that do not diving into the
> stacking vfs and seeing if it could be implemented and if it would help .
>
> Alternatively making FreeBSD multiboot compliant would rock . This would
> allow FreeBSD to natively boot from ipxe or syslinux derivates; thus
> allowing you to boot a working FreeBSD install via a kernel and mfsroot
> image off a web server .
>

There appears to already be a multiboot.c in the bootloader. I've been told
by others in the past it just works...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Mark Saad-5


> On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
>
>
>
>> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]> wrote:
>>
>>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
>>>
>>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
>>>>
>>>>
>>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
>>>>> For those unfamiliar with Plan9, here is a rough explanation of the
>>>>> namespace feature: unlike in Unix, where all processes share the same
>>>>> virtual filesystem, each process instead has its own view of the
>>>>> filesystem according to what has been mounted ...
>>>>
>>>> What if I mount a new /etc with a passwd file where root has no
>>>> password, and then run "su"?
>>>>
>>>> (How does Plan9 handle that?)
>>>>
>>>
>>> Plan9 handles that by having a daemon that does user authentication. It's
>>> actually more complicated than that, but the machine owner has control over
>>> who can do what. For this to work in FreeBSD, either we'd need to disallow
>>> the 'file' type for passwd, or we'd have to do something sensible with
>>> setuid programs. Well, maybe not 'or' but 'and' since the security of
>>> setuid programs depends on the security of the filesystem.... Plan 9
>>> doesn't have these complications, so it can offer a user malleable
>>> filesystem without security risk.
>>>
>>> Warner
>>
>>  A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like “ FreeBSD needs a proper stacking vfs ...”   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs’s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
>> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .
>>
>> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server .
>
> There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works...
>
> Warner

I am going down the rabbit hole to see how it works .

However I still think the unionfs / nullfs work I mentioned before would be a good project related to the plan9 idea in some ways .


---
Mark Saad | [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Theron Tarigo
In reply to this post by Bakul Shah
On 03/13/18 18:23, Bakul Shah wrote:

> Plan9 has no root (superuser) or setuid.  You can mangle
> anything in your namespace but it affects only *your* own
> process and its future descendents.
>
> The following paper on Plan9 authentication in Linux may be
> worth reading:
>      https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34433.pdf
>
> While I have wanted per-process namespace in BSD for a long
> time, I agree with Konstantin this is a non-trivial project.
> Even if the design was fully fleshed out, implementing it
> would likely take longer than 12 weeks.
Although it would limit the usefulness of it, ignoring any and all file
suid bits for any process with a non-empty mount table should in theory
prevent exploitation of setuid.  Allowing safe setuid in combination
with ("trusted" ?) namespaces would be something to add support for much
later if someone decides it would be useful.

By focusing on a narrowed case, that of allowing an unprivileged process
to alter its view into the vfs in a way which is only preserved through
execve() in specific safe circumstances, I hoped to avoid the
insurmountable complexity of implementing the feature in the full
generality that is available on Plan9.

On 03/13/18 18:31, Mark Saad wrote:

>  A kind of related task; FreeBSD could benefit from : Fixing  and
> improving unionfs / nullfs. There are some weird issues with the
> current unionfs and while it works in many cases there are some edge
> cases where the comments are something like “ FreeBSD needs a proper
> stacking vfs ...”   the examples I can think of ; imagine you have a
> jail , chroot or even a Pxe booted system where you want a a read only
> null mount from the hosts /bin to the targets /bin . Now expand that
> to most of the base system and the mount tmpfs’s for /tep /var/log
> etc.  most of that works but try to unmount it in the wrong order or
> thrash a unionfs with lots of writes ,on top of a tmpfs and things
> break .
> So to be clear the project would be to better document the various
> uses of unionfs and nullfs that work , for the ones that do not diving
> into the stacking vfs and seeing if it could be implemented and if it
> would help .
>
Using nullfs / unionfs in combination with chroot could be made
functionally equivalent to per-process namespace, but would have the
very same security problems as already discussed (as any chroot have) so
configuring such environments would be available only to superuser.

So it appears that the most significant obstacle to achieving at least
an approximation of the behavior of user-controlled per-process
namespace is managing setuid safely.

One thought I had is to do all of this purely in user-space by creating
an extension to libc which allows appropriately linked programs to find
files according to some set of prefixes defining the namespace, defined
through an environment variable, but have all system interactions
function in the normal ways.  Would this be sufficiently general to be
of any use?  If this approach does pose any security threats, it
indicates a hole is already present in the system! (MacOS once had a
problem with allowing privileged programs to be launched under a
modified library path...)

On 03/13/18 20:00, Mark Saad wrote:
> However I still think the unionfs / nullfs work I mentioned before
> would be a good project related to the plan9 idea in some ways .
Is there a way I could go about fixing up unionfs while also making
significant progress towards eventual support for true per-process
namespace?

Theron
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Rodney W. Grimes-4
In reply to this post by Warner Losh

... non related text deleted ...

> > Alternatively making FreeBSD multiboot compliant would rock . This would
> > allow FreeBSD to natively boot from ipxe or syslinux derivates; thus
> > allowing you to boot a working FreeBSD install via a kernel and mfsroot
> > image off a web server .
> >
>
> There appears to already be a multiboot.c in the bootloader. I've been told
> by others in the past it just works...

I run a test bed that PXE boots FreeBSD {10,11,12}{i386,amd64} using
FreeBSD 11.1 as the service provider.  I have a specially saved version
of /boot/pxeboot that gets broken and fixed several times over that
evolution that i have to place in each server image to get it working,
I do not know if ^head's /boot/pxeboot works for me or not, I'll try
it again soon.

This system uses stock FreeBSD + isc-dhcp + iPXE.  Everything else is pretty
much untouched.

This same environment via syslinux add ons to iPXE supports running
most .iso images as a netbooted payload, known working are ESXi 5.5,
and 6.5, as I use those frequently.

Michael Dexter is using similiar tooling to netboot via PXE bhyve
instances running as far back as the FreeBSD 5, though this requires
some modifications of things in those releases do to non working
code.

So in final summary, Warner is right "it just works", though there
are a few pointy sticks to get hung up on.

--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Rodney W. Grimes-4
In reply to this post by Mark Saad-5
> > On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
> >
> >
> >
> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]> wrote:
> >>
> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
> >>>
> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
> >>>>
> >>>>
> >>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> >>>>> For those unfamiliar with Plan9, here is a rough explanation of the
> >>>>> namespace feature: unlike in Unix, where all processes share the same
> >>>>> virtual filesystem, each process instead has its own view of the
> >>>>> filesystem according to what has been mounted ...
> >>>>
> >>>> What if I mount a new /etc with a passwd file where root has no
> >>>> password, and then run "su"?
> >>>>
> >>>> (How does Plan9 handle that?)
> >>>>
> >>>
> >>> Plan9 handles that by having a daemon that does user authentication. It's
> >>> actually more complicated than that, but the machine owner has control over
> >>> who can do what. For this to work in FreeBSD, either we'd need to disallow
> >>> the 'file' type for passwd, or we'd have to do something sensible with
> >>> setuid programs. Well, maybe not 'or' but 'and' since the security of
> >>> setuid programs depends on the security of the filesystem.... Plan 9
> >>> doesn't have these complications, so it can offer a user malleable
> >>> filesystem without security risk.
> >>>
> >>> Warner
> >>
> >>  A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like ? FreeBSD needs a proper stacking vfs ...?   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs?s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
> >> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .
> >>
> >> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server .
> >
> > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works...
> >
> > Warner
>
> I am going down the rabbit hole to see how it works .

If you have any questions I am happy to share my working tooling.

...

isc-dhcp from ports,
base system tftp setup via inetd
some bits of syslinix 6.03
proper set of iPXE.exe binaries built with iSCSI, http and nfs support,
you wont need iSCSI, I use that for other things like Windblows.
I boot direct from iPXE to nfs loaded kernel, only thing tftp is used
for is getting a modern version of iPXE onto the booting system.

iPXE loads a menu.ipxe to allow OS selection.
menu.ipxe loads /boot/pxeboot via NFS
YOU SHALL HAVE ISSUES HERE most pxeboot images are broken
pxeboot loads kernel via NFS
kernel runs, end up in /etc/rc.diskless that does the rest of the magic.


--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Mark Saad-5
On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes
<[hidden email]> wrote:

>> > On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
>> >
>> >
>> >
>> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]> wrote:
>> >>
>> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
>> >>>
>> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
>> >>>>
>> >>>>
>> >>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
>> >>>>> For those unfamiliar with Plan9, here is a rough explanation of the
>> >>>>> namespace feature: unlike in Unix, where all processes share the same
>> >>>>> virtual filesystem, each process instead has its own view of the
>> >>>>> filesystem according to what has been mounted ...
>> >>>>
>> >>>> What if I mount a new /etc with a passwd file where root has no
>> >>>> password, and then run "su"?
>> >>>>
>> >>>> (How does Plan9 handle that?)
>> >>>>
>> >>>
>> >>> Plan9 handles that by having a daemon that does user authentication. It's
>> >>> actually more complicated than that, but the machine owner has control over
>> >>> who can do what. For this to work in FreeBSD, either we'd need to disallow
>> >>> the 'file' type for passwd, or we'd have to do something sensible with
>> >>> setuid programs. Well, maybe not 'or' but 'and' since the security of
>> >>> setuid programs depends on the security of the filesystem.... Plan 9
>> >>> doesn't have these complications, so it can offer a user malleable
>> >>> filesystem without security risk.
>> >>>
>> >>> Warner
>> >>
>> >>  A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like ? FreeBSD needs a proper stacking vfs ...?   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs?s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
>> >> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .
>> >>
>> >> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server .
>> >
>> > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works...
>> >
>> > Warner
>>
>> I am going down the rabbit hole to see how it works .
>
> If you have any questions I am happy to share my working tooling.
>

I think you are both missing my point. I can boot FreeBSD with ipxe
loading mfsbsd style setups like this

:freebsd
initrd ${base-root}/freebsd/mfsroot.gz
chain ${base-root}/other/memdisk harddisk raw

I want to be able to boot and run it like I would Linux or ESXi with
the ability to directly load an kernel and a mfsroot/initrd and pass
kernel loader arguments

:centos674
set centos674_args edd=off ramdisk_size=50000 nomodeset
ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
ksdevice=${net0/mac} verbose ip=dhcp
root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
nousb
echo ${centos674_args}
kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz ${centos674_args}
initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img


> ...
>
> isc-dhcp from ports,
> base system tftp setup via inetd
> some bits of syslinix 6.03
> proper set of iPXE.exe binaries built with iSCSI, http and nfs support,
> you wont need iSCSI, I use that for other things like Windblows.
> I boot direct from iPXE to nfs loaded kernel, only thing tftp is used
> for is getting a modern version of iPXE onto the booting system.
>
> iPXE loads a menu.ipxe to allow OS selection.
> menu.ipxe loads /boot/pxeboot via NFS
> YOU SHALL HAVE ISSUES HERE most pxeboot images are broken
> pxeboot loads kernel via NFS
> kernel runs, end up in /etc/rc.diskless that does the rest of the magic.
>
>
> --
> Rod Grimes                                                 [hidden email]



--
mark saad | [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Warner Losh
On Tue, Mar 13, 2018 at 7:35 PM, Mark Saad <[hidden email]> wrote:

> On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes
> <[hidden email]> wrote:
> >> > On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
> >> >
> >> >
> >> >
> >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]>
> wrote:
> >> >>
> >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
> >> >>>
> >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]>
> wrote:
> >> >>>>
> >> >>>>
> >> >>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of
> the
> >> >>>>> namespace feature: unlike in Unix, where all processes share the
> same
> >> >>>>> virtual filesystem, each process instead has its own view of the
> >> >>>>> filesystem according to what has been mounted ...
> >> >>>>
> >> >>>> What if I mount a new /etc with a passwd file where root has no
> >> >>>> password, and then run "su"?
> >> >>>>
> >> >>>> (How does Plan9 handle that?)
> >> >>>>
> >> >>>
> >> >>> Plan9 handles that by having a daemon that does user
> authentication. It's
> >> >>> actually more complicated than that, but the machine owner has
> control over
> >> >>> who can do what. For this to work in FreeBSD, either we'd need to
> disallow
> >> >>> the 'file' type for passwd, or we'd have to do something sensible
> with
> >> >>> setuid programs. Well, maybe not 'or' but 'and' since the security
> of
> >> >>> setuid programs depends on the security of the filesystem.... Plan 9
> >> >>> doesn't have these complications, so it can offer a user malleable
> >> >>> filesystem without security risk.
> >> >>>
> >> >>> Warner
> >> >>
> >> >>  A kind of related task; FreeBSD could benefit from : Fixing  and
> improving unionfs / nullfs. There are some weird issues with the current
> unionfs and while it works in many cases there are some edge cases where
> the comments are something like ? FreeBSD needs a proper stacking vfs ...?
>  the examples I can think of ; imagine you have a jail , chroot or even a
> Pxe booted system where you want a a read only null mount from the hosts
> /bin to the targets /bin . Now expand that to most of the base system and
> the mount tmpfs?s for /tep /var/log etc.  most of that works but try to
> unmount it in the wrong order or thrash a unionfs with lots of writes ,on
> top of a tmpfs and things break .
> >> >> So to be clear the project would be to better document the various
> uses of unionfs and nullfs that work , for the ones that do not diving into
> the stacking vfs and seeing if it could be implemented and if it would help
> .
> >> >>
> >> >> Alternatively making FreeBSD multiboot compliant would rock . This
> would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus
> allowing you to boot a working FreeBSD install via a kernel and mfsroot
> image off a web server .
> >> >
> >> > There appears to already be a multiboot.c in the bootloader. I've
> been told by others in the past it just works...
> >> >
> >> > Warner
> >>
> >> I am going down the rabbit hole to see how it works .
> >
> > If you have any questions I am happy to share my working tooling.
> >
>
> I think you are both missing my point. I can boot FreeBSD with ipxe
> loading mfsbsd style setups like this
>
> :freebsd
> initrd ${base-root}/freebsd/mfsroot.gz
> chain ${base-root}/other/memdisk harddisk raw
>
> I want to be able to boot and run it like I would Linux or ESXi with
> the ability to directly load an kernel and a mfsroot/initrd and pass
> kernel loader arguments
>
> :centos674
> set centos674_args edd=off ramdisk_size=50000 nomodeset
> ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
> ksdevice=${net0/mac} verbose ip=dhcp
> root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
> nousb
> echo ${centos674_args}
> kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz
> ${centos674_args}
> initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img


FreeBSD takes all the arguments that DHCP supplies as loader / kernel env
variables (and if that's not working, I'll fix it). This is a recent
feature and might not be widely documented.

Warner


> > ...
> >
> > isc-dhcp from ports,
> > base system tftp setup via inetd
> > some bits of syslinix 6.03
> > proper set of iPXE.exe binaries built with iSCSI, http and nfs support,
> > you wont need iSCSI, I use that for other things like Windblows.
> > I boot direct from iPXE to nfs loaded kernel, only thing tftp is used
> > for is getting a modern version of iPXE onto the booting system.
> >
> > iPXE loads a menu.ipxe to allow OS selection.
> > menu.ipxe loads /boot/pxeboot via NFS
> > YOU SHALL HAVE ISSUES HERE most pxeboot images are broken
> > pxeboot loads kernel via NFS
> > kernel runs, end up in /etc/rc.diskless that does the rest of the magic.
> >
> >
> > --
> > Rod Grimes
> [hidden email]
>
>
>
> --
> mark saad | [hidden email]
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Rodney W. Grimes-4
In reply to this post by Mark Saad-5
> On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes
> <[hidden email]> wrote:
> >> > On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
> >> >
> >> >
> >> >
> >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]> wrote:
> >> >>
> >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
> >> >>>
> >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <[hidden email]> wrote:
> >> >>>>
> >> >>>>
> >> >>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]> wrote:
> >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of the
> >> >>>>> namespace feature: unlike in Unix, where all processes share the same
> >> >>>>> virtual filesystem, each process instead has its own view of the
> >> >>>>> filesystem according to what has been mounted ...
> >> >>>>
> >> >>>> What if I mount a new /etc with a passwd file where root has no
> >> >>>> password, and then run "su"?
> >> >>>>
> >> >>>> (How does Plan9 handle that?)
> >> >>>>
> >> >>>
> >> >>> Plan9 handles that by having a daemon that does user authentication. It's
> >> >>> actually more complicated than that, but the machine owner has control over
> >> >>> who can do what. For this to work in FreeBSD, either we'd need to disallow
> >> >>> the 'file' type for passwd, or we'd have to do something sensible with
> >> >>> setuid programs. Well, maybe not 'or' but 'and' since the security of
> >> >>> setuid programs depends on the security of the filesystem.... Plan 9
> >> >>> doesn't have these complications, so it can offer a user malleable
> >> >>> filesystem without security risk.
> >> >>>
> >> >>> Warner
> >> >>
> >> >>  A kind of related task; FreeBSD could benefit from : Fixing  and improving unionfs / nullfs. There are some weird issues with the current unionfs and while it works in many cases there are some edge cases where the comments are something like ? FreeBSD needs a proper stacking vfs ...?   the examples I can think of ; imagine you have a jail , chroot or even a Pxe booted system where you want a a read only null mount from the hosts /bin to the targets /bin . Now expand that to most of the base system and the mount tmpfs?s for /tep /var/log etc.  most of that works but try to unmount it in the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs and things break .
> >> >> So to be clear the project would be to better document the various uses of unionfs and nullfs that work , for the ones that do not diving into the stacking vfs and seeing if it could be implemented and if it would help .
> >> >>
> >> >> Alternatively making FreeBSD multiboot compliant would rock . This would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus allowing you to boot a working FreeBSD install via a kernel and mfsroot image off a web server .
> >> >
> >> > There appears to already be a multiboot.c in the bootloader. I've been told by others in the past it just works...
> >> >
> >> > Warner
> >>
> >> I am going down the rabbit hole to see how it works .
> >
> > If you have any questions I am happy to share my working tooling.
> >
>
> I think you are both missing my point. I can boot FreeBSD with ipxe
> loading mfsbsd style setups like this
>
> :freebsd
> initrd ${base-root}/freebsd/mfsroot.gz
> chain ${base-root}/other/memdisk harddisk raw

Nope, not what I am doing.

> I want to be able to boot and run it like I would Linux or ESXi with
> the ability to directly load an kernel and a mfsroot/initrd and pass
> kernel loader arguments
>
> :centos674
> set centos674_args edd=off ramdisk_size=50000 nomodeset
> ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
> ksdevice=${net0/mac} verbose ip=dhcp
> root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
> nousb
> echo ${centos674_args}
> kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz ${centos674_args}
> initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img

:freebsd6411
set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64
iseq ${platform} efi && chain nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/loader.efi || chain nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/pxeboot
boot || goto failed
goto start

I agree it would be nice to get the "variable=value" stuff working.
I do know the above does infact pass that root-path to the kernel,
and without that mountroot fails, so some of this is working


--
Rod Grimes                                                 [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Warner Losh
On Tue, Mar 13, 2018 at 9:53 PM, Rodney W. Grimes <
[hidden email]> wrote:

> > On Tue, Mar 13, 2018 at 9:25 PM, Rodney W. Grimes
> > <[hidden email]> wrote:
> > >> > On Mar 13, 2018, at 7:16 PM, Warner Losh <[hidden email]> wrote:
> > >> >
> > >> >
> > >> >
> > >> >> On Tue, Mar 13, 2018 at 4:31 PM, Mark Saad <[hidden email]>
> wrote:
> > >> >>
> > >> >>> On Mar 13, 2018, at 5:43 PM, Warner Losh <[hidden email]> wrote:
> > >> >>>
> > >> >>>> On Tue, Mar 13, 2018 at 1:55 PM, Kristoffer Eriksson <
> [hidden email]> wrote:
> > >> >>>>
> > >> >>>>
> > >> >>>>> On 13 Mar 2018 12:53:18, Theron <[hidden email]>
> wrote:
> > >> >>>>> For those unfamiliar with Plan9, here is a rough explanation of
> the
> > >> >>>>> namespace feature: unlike in Unix, where all processes share
> the same
> > >> >>>>> virtual filesystem, each process instead has its own view of the
> > >> >>>>> filesystem according to what has been mounted ...
> > >> >>>>
> > >> >>>> What if I mount a new /etc with a passwd file where root has no
> > >> >>>> password, and then run "su"?
> > >> >>>>
> > >> >>>> (How does Plan9 handle that?)
> > >> >>>>
> > >> >>>
> > >> >>> Plan9 handles that by having a daemon that does user
> authentication. It's
> > >> >>> actually more complicated than that, but the machine owner has
> control over
> > >> >>> who can do what. For this to work in FreeBSD, either we'd need to
> disallow
> > >> >>> the 'file' type for passwd, or we'd have to do something sensible
> with
> > >> >>> setuid programs. Well, maybe not 'or' but 'and' since the
> security of
> > >> >>> setuid programs depends on the security of the filesystem....
> Plan 9
> > >> >>> doesn't have these complications, so it can offer a user malleable
> > >> >>> filesystem without security risk.
> > >> >>>
> > >> >>> Warner
> > >> >>
> > >> >>  A kind of related task; FreeBSD could benefit from : Fixing  and
> improving unionfs / nullfs. There are some weird issues with the current
> unionfs and while it works in many cases there are some edge cases where
> the comments are something like ? FreeBSD needs a proper stacking vfs ...?
>  the examples I can think of ; imagine you have a jail , chroot or even a
> Pxe booted system where you want a a read only null mount from the hosts
> /bin to the targets /bin . Now expand that to most of the base system and
> the mount tmpfs?s for /tep /var/log etc.  most of that works but try to
> unmount it in the wrong order or thrash a unionfs with lots of writes ,on
> top of a tmpfs and things break .
> > >> >> So to be clear the project would be to better document the various
> uses of unionfs and nullfs that work , for the ones that do not diving into
> the stacking vfs and seeing if it could be implemented and if it would help
> .
> > >> >>
> > >> >> Alternatively making FreeBSD multiboot compliant would rock . This
> would allow FreeBSD to natively boot from ipxe or syslinux derivates; thus
> allowing you to boot a working FreeBSD install via a kernel and mfsroot
> image off a web server .
> > >> >
> > >> > There appears to already be a multiboot.c in the bootloader. I've
> been told by others in the past it just works...
> > >> >
> > >> > Warner
> > >>
> > >> I am going down the rabbit hole to see how it works .
> > >
> > > If you have any questions I am happy to share my working tooling.
> > >
> >
> > I think you are both missing my point. I can boot FreeBSD with ipxe
> > loading mfsbsd style setups like this
> >
> > :freebsd
> > initrd ${base-root}/freebsd/mfsroot.gz
> > chain ${base-root}/other/memdisk harddisk raw
>
> Nope, not what I am doing.
>
> > I want to be able to boot and run it like I would Linux or ESXi with
> > the ability to directly load an kernel and a mfsroot/initrd and pass
> > kernel loader arguments
> >
> > :centos674
> > set centos674_args edd=off ramdisk_size=50000 nomodeset
> > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
> > ksdevice=${net0/mac} verbose ip=dhcp
> > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
> > nousb
> > echo ${centos674_args}
> > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz
> ${centos674_args}
> > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img
>
> :freebsd6411
> set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64
> iseq ${platform} efi && chain nfs://192.168.48.38/B/FreeBSD/
> 11.0/amd64/boot/loader.efi || chain nfs://192.168.48.38/B/FreeBSD/
> 11.0/amd64/boot/pxeboot
> boot || goto failed
> goto start
>
> I agree it would be nice to get the "variable=value" stuff working.
> I do know the above does infact pass that root-path to the kernel,
> and without that mountroot fails, so some of this is working
>

right, loader.efi and/or pxebooot is what sets the root path (and other
variables).  What others are asking for is some kind way to do just load
the kernel + a bundle of variables with some kind of 'mini /boot/loader'
(in our terms) that can turn the bundle into the metadata the kernel needs
to do it's job. We have an extra layer of with loader.efi/pxeboot and linux
doesn't...

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Jamie Landeg-Jones-2
In reply to this post by Theron Tarigo
Linux has already implemented something similar - with mount namespaces.

http://man7.org/linux/man-pages/man7/mount_namespaces.7.html

cheers!

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Martin Beran-2
In reply to this post by Theron Tarigo
On 03/14/18 01:16, Theron Tarigo wrote:

> On 03/13/18 18:23, Bakul Shah wrote:
>> Plan9 has no root (superuser) or setuid.  You can mangle
>> anything in your namespace but it affects only *your* own
>> process and its future descendents.
>>
> Although it would limit the usefulness of it, ignoring any and all file
> suid bits for any process with a non-empty mount table should in theory
> prevent exploitation of setuid.  Allowing safe setuid in combination
> with ("trusted" ?) namespaces would be something to add support for much
> later if someone decides it would be useful.
>
> By focusing on a narrowed case, that of allowing an unprivileged process
> to alter its view into the vfs in a way which is only preserved through
> execve() in specific safe circumstances, I hoped to avoid the
> insurmountable complexity of implementing the feature in the full
> generality that is available on Plan9.

Another possibility would be to decouple security related decisions from
the file system namespaces. What I mean is that, for example,
/etc/master.passwd should not be trusted by su because of the file name.
Instead, it could bear some attribute assigned by root denoting it as a
valid passwd database. If su accessed a file without this attribute, the
kernel would withdraw its capability to switch user identity, regardless
of its setuid. If any processes without a relevant privilege modifies
/etc/master.passwd, the kernel would automatically remove the "passwd
db" attribute from the file. Naturally, a password file installed by an
ordinary user via altering the file system namespace would not have the
attribute. Such security (in fact, integrity-defining) attributes would
be attached to the files and possibly other system objects themselves,
not to their names. I understand that implementing such security
mechanism would require much much larger effort than the above mentioned
ad-hoc solution. But I think it has the potential to solve many other
security-related problems.

--
Martin Beran
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Mark Saad-5
In reply to this post by Theron Tarigo
On Tue, Mar 13, 2018 at 8:16 PM, Theron Tarigo <[hidden email]> wrote:

> On 03/13/18 18:23, Bakul Shah wrote:
>>
>> Plan9 has no root (superuser) or setuid.  You can mangle
>> anything in your namespace but it affects only *your* own
>> process and its future descendants.
>>
>> The following paper on Plan9 authentication in Linux may be
>> worth reading:
>>
>> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34433.pdf
>>
>> While I have wanted per-process namespace in BSD for a long
>> time, I agree with Konstantin this is a non-trivial project.
>> Even if the design was fully fleshed out, implementing it
>> would likely take longer than 12 weeks.
>
> Although it would limit the usefulness of it, ignoring any and all file suid
> bits for any process with a non-empty mount table should in theory prevent
> exploitation of setuid.  Allowing safe setuid in combination with ("trusted"
> ?) namespaces would be something to add support for much later if someone
> decides it would be useful.
>
> By focusing on a narrowed case, that of allowing an unprivileged process to
> alter its view into the vfs in a way which is only preserved through
> execve() in specific safe circumstances, I hoped to avoid the insurmountable
> complexity of implementing the feature in the full generality that is
> available on Plan9.
>
> On 03/13/18 18:31, Mark Saad wrote:
>>
>>  A kind of related task; FreeBSD could benefit from : Fixing  and
>> improving unionfs / nullfs. There are some weird issues with the current
>> unionfs and while it works in many cases there are some edge cases where the
>> comments are something like “ FreeBSD needs a proper stacking vfs ...”   the
>> examples I can think of ; imagine you have a jail , chroot or even a Pxe
>> booted system where you want a a read only null mount from the hosts /bin to
>> the targets /bin . Now expand that to most of the base system and the mount
>> tmpfs’s for /tep /var/log etc.  most of that works but try to unmount it in
>> the wrong order or thrash a unionfs with lots of writes ,on top of a tmpfs
>> and things break .
>> So to be clear the project would be to better document the various uses of
>> unionfs and nullfs that work , for the ones that do not diving into the
>> stacking vfs and seeing if it could be implemented and if it would help .
>>
> Using nullfs / unionfs in combination with chroot could be made functionally
> equivalent to per-process namespace, but would have the very same security
> problems as already discussed (as any chroot have) so configuring such
> environments would be available only to superuser.

I was not thinking of you cobbling nullfs and unionfs into a FreeBSD
version of plan9's bind
I was thinking more about how nullfs , and unionfs are influenced by
plan9 and how they could benefit
from someone with some plan9 experience. Not to say that any of the
prior work was done poorly or
incorrectly because of a lack of plan9 experience . But that your
enthusiasm would be better focused
on a part of base that could use some polish and maybe some rethinking .

>
> So it appears that the most significant obstacle to achieving at least an
> approximation of the behavior of user-controlled per-process namespace is
> managing setuid safely.

One idea here could be to use capsicum to enforce this requirement but
that would be a new approach from what I understand.
https://www.freebsd.org/cgi/man.cgi?capsicum(4)

>
> One thought I had is to do all of this purely in user-space by creating an
> extension to libc which allows appropriately linked programs to find files
> according to some set of prefixes defining the namespace, defined through an
> environment variable, but have all system interactions function in the
> normal ways.  Would this be sufficiently general to be of any use?  If this
> approach does pose any security threats, it indicates a hole is already
> present in the system! (MacOS once had a problem with allowing privileged
> programs to be launched under a modified library path...)
>
> On 03/13/18 20:00, Mark Saad wrote:
>>
>> However I still think the unionfs / nullfs work I mentioned before would
>> be a good project related to the plan9 idea in some ways .
>
> Is there a way I could go about fixing up unionfs while also making
> significant progress towards eventual support for true per-process
> namespace?
>
> Theron

I think there is a lot of opportunity here to pick apart a subsystem
that shares some commonality with plan9 . I think that improving
unionfs / nullfs to have less edge cases would be a great project.
You would need to set a smaller goal for managing the expiation
of time you will have for GSoC .

Some small tasks that could be a starting point for working on this
project.  There are a few projects that depend on creating a
unionfs of a tmpfs and a readonly disk image.   One example would be
booting off a CD-Rom and using a unionfs to make a ram disk give the
read-only medium the appearance of have a read / write. Second example
is the Docker / Container setup where a read-only loop-mounted
disk image is unioned to a ram disk in a similar way to the cdrom was
before . Third option is where a Jail is created from a template
directory
that would mount versions of a binary or directory into the jailed
environment for various reason.


--
mark saad | [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: GSoC Idea: per-process filesystem namespaces for FreeBSD

Mark Saad-5
In reply to this post by Warner Losh
Warner
  I'll see if I can get this working , later today.  From what I
remember with NetBSD changes back in 2004 they wanted to get Xen
working booting from Grub with out chain loading.
If memory serves me that's what led them into getting the kernel to
boot via the multiboot protocol . Solaris/Illumos can also do the same
. I use iPXE at work to network boot an Illumos derivative with a
kernel, boot archive and  some variables to govern console bits and
what not. In a weird sort of coincidence Illumos imported FreeBSD's
loader to try and dump Grub so
maybe everything is there already ?  Lets see what I can get working today.

>> > >> > Warner
>> > >>
>> > >> I am going down the rabbit hole to see how it works .
>> > >
>> > > If you have any questions I am happy to share my working tooling.
>> > >
>> >
>> > I think you are both missing my point. I can boot FreeBSD with ipxe
>> > loading mfsbsd style setups like this
>> >
>> > :freebsd
>> > initrd ${base-root}/freebsd/mfsroot.gz
>> > chain ${base-root}/other/memdisk harddisk raw
>>
>> Nope, not what I am doing.
>>
>> > I want to be able to boot and run it like I would Linux or ESXi with
>> > the ability to directly load an kernel and a mfsroot/initrd and pass
>> > kernel loader arguments
>> >
>> > :centos674
>> > set centos674_args edd=off ramdisk_size=50000 nomodeset
>> > ks=${centos-root}/CentOS6.7_x64/ks/supermicro-4drives.ks
>> > ksdevice=${net0/mac} verbose ip=dhcp
>> > root-path=${centos-root}/CentOS6.7_x64/OS/ net.ifnames=0 biosdevname=0
>> > nousb
>> > echo ${centos674_args}
>> > kernel ${base-root}/centos/CentOS6.7_x64/isolinux/vmlinuz
>> > ${centos674_args}
>> > initrd ${base-root}/centos/CentOS6.7_x64/isolinux/initrd.img
>>
>> :freebsd6411
>> set root-path 192.168.48.38:/B/FreeBSD/11.0/amd64
>> iseq ${platform} efi && chain
>> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/loader.efi || chain
>> nfs://192.168.48.38/B/FreeBSD/11.0/amd64/boot/pxeboot
>> boot || goto failed
>> goto start
>>
>> I agree it would be nice to get the "variable=value" stuff working.
>> I do know the above does infact pass that root-path to the kernel,
>> and without that mountroot fails, so some of this is working
>
>
> right, loader.efi and/or pxebooot is what sets the root path (and other
> variables).  What others are asking for is some kind way to do just load the
> kernel + a bundle of variables with some kind of 'mini /boot/loader' (in our
> terms) that can turn the bundle into the metadata the kernel needs to do
> it's job. We have an extra layer of with loader.efi/pxeboot and linux
> doesn't...
>
> Warner



--
mark saad | [hidden email]
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
12