Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Samuel Thibault]

Olaf Buddenhagen, on Mon 19 Sep 2016 23:43:55 +0200, wrote:
> I don't know which threads you have read exactly; but there have been
> pretty conclusive discussions on this issue IMHO.

I'd be really good if such conclusions would have been written somewhere
else than a list thread :/

Samuel

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Olaf Buddenhagen]

Hi,

On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun  wrote:

> > This was famously shown with the example of the
> > firmlink translator used in /tmp, which would cause the removal of
> > any file targeted by the firmlink on /tmp cleanup during system
> > startup.
>
> I see that.  It seems to still have that problem.  I created a directory
> /root/baitdir, and put in it a file named 'bait'.  As a non-privileged
> user, I created a firmlink in /tmp to /root/baitdir and rebooted.  Voila!
> 'bait' vanished.
> 
> I took the time to read some of this mailing list's archive on the
> subject.  The consensus seems to be that you can't trust unprivileged
> translators.  So "find", which is used to clean /tmp, should not, in this
> case, cross translator boundaries.

I don't know which threads you have read exactly; but there have been
pretty conclusive discussions on this issue IMHO.

The "quickfix" solution is simply by default not to follow translators
running with a different UID than the client. (Unless the translator is
running as root.) That's pretty much what FUSE does on Linux.

A more ambitious solution I came up with Carl is to change the reauth
mechanism: when crossing translator boundaries during a lookup, instead
of obtaining an new auth token associated with all of the IDs available
to the client process, we would create an auth token associated with
only the intersection of the IDs from the previous auth token, and the
IDs available to the new translator we are entering. This way, when for
example a root process follows a firmlink run by an ordinary user, it
would get an auth token associated with only that user's IDs, not the
root IDs; and when the firmlink redirects to some other FS location, the
following lookup would still be limited to that user's IDs -- so the FD
obtained from the lookup could not be used to delete a file that the
untrusted user has no permissions for.

> I was thinking at first that we should have something like the "-xdev"
> switch; "-xtrans", maybe?

Selecting how to treat translators in general is another long-standing
issue, but with a broader and somewhat different scope than the trust
issue. Backups are a pretty illustrative standard example for that.

The fundamental problem with this is that translators range from things
that behave and should be treated like traditional filesystem mounts, to
others that should be pretty much transparent -- trying to treat all of
them in the same manner is bound to create problems in one situation or
the other. We need a more fine-grained solution.

Trying to add options to handle all the possible cases to all relevant
client programs is not realistic. Thus the solution I advocate instead
is something I refer to as "namespace-based translator selection": the
user adds special suffixes to paths, which are transparent to the
clients doing the lookup, but invoke special handling in the lookup
mechanism. Thus for example "rm -r /foo,,*" would follow all
translators, while "rm -r /foo,,0" wouldn't follow any; yet other
options could be more selective, following only certain classes of
translators etc.

Many years ago Sergiu worked on a prototype implementation we called
"nsmux" (for lack of a more suitable name) in the context of a GSoC
project (kinda), and we got many in-depth discussion along with a
partially working implementation. It didn't get finished, because the
implementation as a proxy server turned out more involved than initially
anticipated (the other option would be implementing it in glibc); and
also because I wasn't able to keep up with the amount of mentoring
necessary I think... But the idea is still out there.

(My favourite feature of this mechanism is the ability to specify
"dynamic" translators to be applied during the lookup, without a need to
explicitly set them up first; so we could for example do something like
"vi /foo/bar.gz,,unzip" -- I believe this would really give the Hurd an
edge in convenience over other systems...)

> Yet since filesystem mounts are themselves done with translators, what does
> "-xdev" mean on Hurd?  I've poked around a bit in the source, and played
> with 'stat'.  It seems like several translators take an arbitrary number
> and present it as their device number.  Seems like legacy support, and it's
> easy for a translator to defeat -xdev by announcing the same device as its
> parent.

This is actually an interesting idea for a partial solution: we could
introduce some mechanism that would allow specifying (e.g. as an option
to settrans) whether a translator should be transparent or mount-like;
which would determine whether the translator is allowed to claim the
same device ID as its parent or not. That would require some major
interface changes in the Hurd -- but it might be worth the effort.

> On a related note, how do you find the owner of a passive translator?  I
> expected either showtrans or ls to 

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Olaf Buddenhagen]

Hi,

On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun  wrote:

[...]
> > The solution, whatever it is, should focus only on determining whether
> > a server can be trusted or not. This should affect everything (servers,
> > (active) translators and translator records).
>
> Yes, we need to clearly determine when a server is trusted.
[...]

Actually, a generic notion of a server being "trusted" is a much more
complex problem. We discussed several options with Carl in the context
of his work on "object migration", which required determining when it's
safe to execute server code with the authority of the client. IIRC we
didn't come up with a conclusive approach...

However, trusting lookups is a way more specific problem, which we
believe we have a pretty good idea of how it can be addressed.

-antrik-

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Richard Braun]

On Tue, Sep 20, 2016 at 01:33:44AM +0200, Samuel Thibault wrote:
> I don't think we want to make /tmp use trustiness to determine whether
> to follow a translator or not.  If as root I run
> 
> settrans -c /tmp/foo /hurd/firmlink /some/where
> 
> I'd expect only foo to be removed.

If we want to stick to the Unix interface, and I strongly think we do
want that, then we'd need to make any translator visible as a separate
file system indeed. On my Debian jessie, the clean_tmp() in
/lib/init/bootclean.sh does use find -xdev, so this would work as
intended.

I don't know if that's already the case or not since Justus' work on
/proc/mounts. The work required here is to rely on the parent to report
whether a node is a separate file system. This could also break programs
assuming a file system is a directory if the attached translator
presents itself as something else.

-- 
Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Richard Braun]

On Wed, Sep 07, 2016 at 03:57:08PM -1000, Brent W. Baccala wrote:
> OK, I understand.  I personally lean in the direction of adding something
> like an "-xtrans" switch to find, telling it not to enter translators,
> because that's a lot clearer than usurping the interpretation of existing
> switches from systems without translators.  However, I also appreciate the
> wisdom in what you say, in which case I revert to my earlier suggestion of
> modifying the FTS code in glibc to interpret FTS_XDEV to mean "don't enter
> translators".

I think it's an acceptable workaround.

> > We'd also have to make sure that remove()/unlink()/rmdir() don't cross
> > the file system into the untrusted translator.
> 
> 
> How do we do that without modifying programs?  Probably the FTS code;
> that's what both rm and find seem to use to transverse directory structures.

Probably.

> Also, I agree with Kalle that not entering translators should be the
> default for "rm".  If so, and we modify FTS without touching the programs,
> then it also becomes the default for "chmod", "chown", "chcon", "grep", and
> "du".  In particular, I don't think we want that for "grep" (not so sure
> about the others).
> 
> If I understand you, Richard, you'd like to see grep's default be to enter
> trusted translators, but not untrusted ones.  Am I correct?

Yes, but not only grep.

> I'm not sure I understand when you say "More limited in that our trust
> > set is finite". Actually, we'd like our trust set _not_ to be finite,
> > since we want the system to be extensible, by both the admin and any
> > unprivileged user. Again, too rigid.
> 
> 
> I meant that we have a standard set of trusted translators in /hurd, and
> that set is finite, just like the set of programs in /bin is finite.  We
> certainly don't have a means for verifying any old program in a user's bin
> directory to see if it's safe to run as root.

Unless that user has root access.

> Would you like to see a scheme where only a limited set of trusted
> translators were accessible to a process, and the user had the ability to
> extend the trust set of his own processes?  Something like adding
> directories to your own PATH, but this would apply to translators running
> under different UIDs, and not just programs that you started yourself?

My current idea is something like Plan9 factotum, an agent that would
be used by any program, client or server, to validate that it's safe to
communicate through a given port.

-- 
Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Brent W. Baccala]

On Wed, Sep 7, 2016 at 11:49 AM, Richard Braun  wrote:

>
> We really, really don't want to make standard Unix tools aware of
> Hurd-specific stuff, because that allows us to completely reuse the
> work of others. With a trend towards systemd, it's even more likely
> that our efforts will be put into providing some of the stuff specific
> to _others_ system instead.
>

> Personally, I would consider any solution that isn't entirely contained
> in the Hurd (kernel, servers, glibc and related) to be a no-go.
>

OK, I understand.  I personally lean in the direction of adding something
like an "-xtrans" switch to find, telling it not to enter translators,
because that's a lot clearer than usurping the interpretation of existing
switches from systems without translators.  However, I also appreciate the
wisdom in what you say, in which case I revert to my earlier suggestion of
modifying the FTS code in glibc to interpret FTS_XDEV to mean "don't enter
translators".


> > Makes sense.  The parent is where you've got all that information.  Is
> > there no way to retrieve it?
>
> There might, I haven't looked thoroughly, and it could be implemented
> if needed.
>

OK.  I just though I might be overlooking something obvious.


> We'd also have to make sure that remove()/unlink()/rmdir() don't cross
> the file system into the untrusted translator.


How do we do that without modifying programs?  Probably the FTS code;
that's what both rm and find seem to use to transverse directory structures.

Also, I agree with Kalle that not entering translators should be the
default for "rm".  If so, and we modify FTS without touching the programs,
then it also becomes the default for "chmod", "chown", "chcon", "grep", and
"du".  In particular, I don't think we want that for "grep" (not so sure
about the others).

If I understand you, Richard, you'd like to see grep's default be to enter
trusted translators, but not untrusted ones.  Am I correct?

I'm not sure I understand when you say "More limited in that our trust
> set is finite". Actually, we'd like our trust set _not_ to be finite,
> since we want the system to be extensible, by both the admin and any
> unprivileged user. Again, too rigid.


I meant that we have a standard set of trusted translators in /hurd, and
that set is finite, just like the set of programs in /bin is finite.  We
certainly don't have a means for verifying any old program in a user's bin
directory to see if it's safe to run as root.

Would you like to see a scheme where only a limited set of trusted
translators were accessible to a process, and the user had the ability to
extend the trust set of his own processes?  Something like adding
directories to your own PATH, but this would apply to translators running
under different UIDs, and not just programs that you started yourself?

agape
brent

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Richard Braun]

On Tue, Sep 06, 2016 at 02:49:31PM -1000, Brent W. Baccala wrote:
> Consider the case with symlinks.  If "rm" transversed them, it could be a
> big problem.  Let's see... what's the option for that?... oh, there is
> none!  Isn't that interesting?  "rm" has no option to follow symlinks!
> 
> "find" does, however.  "find -L -delete" is a dangerous combination, and
> when run as root will trigger the exact same behavior that we're seeing
> with firmlinks in /tmp.
> 
> So, part of the solution is just making sure that the system scripts and
> binaries do what we want.  That "find" command used to clean /tmp should
> not recurse into translators.  It should delete the underlying nodes
> instead.

We really, really don't want to make standard Unix tools aware of
Hurd-specific stuff, because that allows us to completely reuse the
work of others. With a trend towards systemd, it's even more likely
that our efforts will be put into providing some of the stuff specific
to _others_ system instead.

Personally, I would consider any solution that isn't entirely contained
in the Hurd (kernel, servers, glibc and related) to be a no-go.

> Makes sense.  The parent is where you've got all that information.  Is
> there no way to retrieve it?

There might, I haven't looked thoroughly, and it could be implemented
if needed.

> > The solution, whatever it is, should focus only on determining whether
> > a server can be trusted or not. This should affect everything (servers,
> > (active) translators and translator records).
> 
> Yes, we need to clearly determine when a server is trusted.  Yet I think it
> has to be both more comprehensive and more limited than that.  More
> comprehensive in that we need to determine whether programs can be trusted
> as well.  More limited in that our trust set is finite.
> 
> In this case, our trust set is "ext2fs", "find", and "bootclean.sh" (plus
> shared libraries, the kernel, the shell, etc).  We trust ext2fs to notify
> us when it's handing off to a different translator.  We trust "find" to
> respect those notifications and not to cross those boundaries.  We trust
> "bootclean.sh" to clean /tmp without touching the rest of the filesystem.

How do you define "trusting programs". If it's the path to the binary,
then I disagree, it's far too rigid. If it's a process, and it can be
determined that this process has a property that tells us we can trust
it, then yes. The "more comprehensive" part would be what property,
and how to manipulate and check them.

I'm not sure I understand when you say "More limited in that our trust
set is finite". Actually, we'd like our trust set _not_ to be finite,
since we want the system to be extensible, by both the admin and any
unprivileged user. Again, too rigid.

Finally, I also disagree that we trust "ext2fs" or "find". We trust root.
When a program is started, it trusts the initial ports it receives. We
trust the root translator, and we trust what belongs to root inside of
it. What I want is to safely extend that trust to other users (root and
self should be default), and again, to other properties (like POSIX
style capabilities). And I'd like to merely avoid contact with servers
that aren't part of this trust computing base.

We'd also have to make sure that remove()/unlink()/rmdir() don't cross
the file system into the untrusted translator.

-- 
Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Kalle Olavi Niemitalo]

"Brent W. Baccala"  writes:

> I see that.  It seems to still have that problem.  I created a directory
> /root/baitdir, and put in it a file named 'bait'.  As a non-privileged
> user, I created a firmlink in /tmp to /root/baitdir and rebooted.  Voila!
> 'bait' vanished.

We recently discussed it at .

> A few slight changes to rm itself, and we could use "rm -rfx"
> as a common verb meaning "delete everything and don't go into
> translators".

In my opinion, rm -r should always delete translators (including
ext2fs mount points) like it deletes symlinks.

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Brent W. Baccala]

On Tue, Sep 6, 2016 at 2:05 AM, Richard Braun  wrote:

> On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> > I haven't been able to find any other places on my system where find uses
> > -xdev; just bootclean.sh, but my search has not been exhaustive.
> >
> > Obviously there's been a long history behind this problem, and I'm new on
> > the scene.  Does this change make sense?
>
> Any solution that isn't a global system solution is doomed to fail,
> since this problem may affect any RPC, including those that don't
> exist yet.
>

Let's try to hash this out, please.  I've read the entire "critique" and at
least some of the prior discussion on this list.  My response to it has
been, "we can work this out".

I think you have an excellent point on the need for trusted translators.  I
would suggest, however, that UNIX systems already have a basic solution to
this problem - the /bin, /sbin, and /usr/bin directories.  It's trivial to
write a program that looks like "rm" (or even "ls") but instead wreaks all
kinds of havoc.  The hard part is getting root to run it - that's why we
don't search dot in our PATHs.  It's unsophisticated, but it's simple and
usually works.

Clearly a user could fashion a translator that presented a filesystem in a
very deceptive manner to an unsuspecting superuser.  Maybe we should trust
the translators in /hurd, much like we trust the binaries in /bin, and
fashion our shell prompts and directory listings so they clearly warn us
when we're dealing with a translator that isn't in that trust set.

Yet, I don't think that this is the case here.

Consider the case with symlinks.  If "rm" transversed them, it could be a
big problem.  Let's see... what's the option for that?... oh, there is
none!  Isn't that interesting?  "rm" has no option to follow symlinks!

"find" does, however.  "find -L -delete" is a dangerous combination, and
when run as root will trigger the exact same behavior that we're seeing
with firmlinks in /tmp.

So, part of the solution is just making sure that the system scripts and
binaries do what we want.  That "find" command used to clean /tmp should
not recurse into translators.  It should delete the underlying nodes
instead.

> On a related note, how do you find the owner of a passive translator?  I
> > expected either showtrans or ls to provide that information (perhaps
> with a
> > verbose switch), but it had eluded me...
>
> I'm not sure you can from outside the parent.
>

Makes sense.  The parent is where you've got all that information.  Is
there no way to retrieve it?


> Besides, note that Justus and I are currently pushing towards the use
> of "translator records" instead of "passive translators" to more
> accurately reflect what they truely are.
>
> The solution, whatever it is, should focus only on determining whether
> a server can be trusted or not. This should affect everything (servers,
> (active) translators and translator records).
>

Yes, we need to clearly determine when a server is trusted.  Yet I think it
has to be both more comprehensive and more limited than that.  More
comprehensive in that we need to determine whether programs can be trusted
as well.  More limited in that our trust set is finite.

In this case, our trust set is "ext2fs", "find", and "bootclean.sh" (plus
shared libraries, the kernel, the shell, etc).  We trust ext2fs to notify
us when it's handing off to a different translator.  We trust "find" to
respect those notifications and not to cross those boundaries.  We trust
"bootclean.sh" to clean /tmp without touching the rest of the filesystem.

This seems doable!  The questions I see are, do we introduce a new switch
to find (-xtrans), and have to maintain a Hurd-specific version of
bootclean.sh, or do we overload a legacy switch (-xdev) and tolerate a more
obscure and confusing option name?  Do we introduce a "-x" switch to rm, to
make "rm -rfx" avoid translators, or do we make this the default behavior,
since "rm -rf" is so ingrained into people's minds that we need to respect
its semantics?

One step at a time.  Can we answer these questions, and fix our boot
sequence to properly clean /tmp?

agape
brent

Re: firmlink deleting files on boot / interpretation of find -xdev switch

[Richard Braun]

On Mon, Sep 05, 2016 at 09:55:44PM -1000, Brent W. Baccala wrote:
> I haven't been able to find any other places on my system where find uses
> -xdev; just bootclean.sh, but my search has not been exhaustive.
> 
> Obviously there's been a long history behind this problem, and I'm new on
> the scene.  Does this change make sense?

Any solution that isn't a global system solution is doomed to fail,
since this problem may affect any RPC, including those that don't
exist yet.

> On a related note, how do you find the owner of a passive translator?  I
> expected either showtrans or ls to provide that information (perhaps with a
> verbose switch), but it had eluded me...

I'm not sure you can from outside the parent.

Besides, note that Justus and I are currently pushing towards the use
of "translator records" instead of "passive translators" to more
accurately reflect what they truely are.

The solution, whatever it is, should focus only on determining whether
a server can be trusted or not. This should affect everything (servers,
(active) translators and translator records).

-- 
Richard Braun