Hi,

On Fri, January 11, 2008 09:46, Tetsuo Handa wrote:
quoted text
> It depends.
> Some users have to continue using brain dead legacy applications
> without modification because ...
>
>    the application's source code is not available.

Source isn't needed, as long as the vendor has it.

quoted text
>    the distributor no longer supports the application.

Then why should anyone else support it?

quoted text
>    the application is too difficult/complicated to reconstruct.

Then you can't trust it and it shouldn't have permission to do
potentially dangerous things in /dev/ either. Even if you can
contain the device node creation, it most likely does other
potentially dangerous things too. As a whole it can't be trusted.

quoted text
> I assume "a static /dev/" means a /dev/ directory in 2.4 kernels.
> This filesystem's advantage:

I'm not talking about devfs, I'm talking about a real static /dev.
I'm using it now and it works fine (I let udev manage /udev/ to see
what's it's doing).

quoted text
>   (1) Can guarantee filename/attribute pairs.

Wrong. All nodes are created and thus there's never a need to create
new nodes. So /dev/ can't be modified by anyone. This works because
all nodes that anyone might want to create already exist.

quoted text
>   (2) Can keep nodes that needn't to be deleted/modified for read-only.

This would also be true for all nodes in a static /dev I think.

quoted text
>   (3) Can hide unwanted device nodes.

In a static /dev you only create the nodes you want. It's true that it
can't hide nodes for hardware that doesn't exist (other than deleting
the nodes manually), but that was the norm for years before the
whole dynamic /dev thing catched up.

quoted text
> I don't know. I'm not using rare software.

It doesn't have to be rare, anything is fine. You don't know
anything else than udev? (And shell commands like mknod etc.)

Then why all the talk about mysterious apps that might need to
do all kind of crazy things in /dev?

quoted text
> No. The kernel must be involved.

quoted text
> Who can guarantee that the daemon can access all namespaces?
> The process who requests "mknod" and the process who performs "mknod"
> are not always using the same namespace.

This is true on a theoretical level. But practically I think you can either
run multiple daemons, one for each namespace where you want to
control /dev/, or if you really want one daemon you can pass the
directory fd to it where the node should be created and use mknodat().
I believe that crosses namespaces correctly.

If the daemon can't be contacted or doesn't want to do a mknod for you,
the preloaded lib can fallback to doing the mknod itself, though normally
that would be disallowed by MAC.

But I think that the chance that any process needs to create device nodes
in a chroot is at the level of fairy existance.

quoted text
> If "foo" or "bar" is a statically linked or suid-root application
> (where LD_PRELOAD is ignored), they would attempt to create device nodes
> directly (i.e. call sys_mknod() instead of communicating with the daemon)
> and abort due to failure.
> Not only applications who wants to create device nodes in /dev/ ,
> but also all applications who wants to modify entries in /dev/ .

If the preloaded library is setuid, it will also work for setuid programs.
It's true that it won't work for statically linked apps, but so what?

Device node creating apps are rare enough, let alone the ones that are
also statically linked. Nice theoretical problem, but I don't think anyone
will care in practice.

quoted text
> From the beginning, the kernel is deeply involved because in-kernel MAC
> is essential to realize "only the tiny daemon can modify /dev/".
> Why not do this "filename/attribute" checking in the kernel too?

That "only the tiny daemon can modify /dev/" is done with MAC rules,
the ones that should be the default for all applications except udev by
default already. For teh kernel nothing changes.

quoted text
>> The ammount of code will be the current parsing code + a few hundred
>> lines of code, including the preloaded library.
>
> You will be bothered with "what is the realpath of /dev/null?" and
> "how can I reach the realpath?" because you have to manage
> namespace information.

Or ignore the problem and see if it's a real problem or a nice theoretical
case. And when it turns out to be a real problem, there are probably
ways to fix it (See above). But you know what exactly is needed only
after problems do turn up.

quoted text
> OK. I'll consider adding this feature.
> But I'd like to use approach (B) to keep the advantage (3).
>
> (A) White-listing + Black-listing approach.
>
>     "Permit any operations if the filename didn't appear
>      in the configuration file".
>
> (B) White-listing + Wild-card approach.
>
>     "Support wildcard and permit only operations if
>      the filename-with-wildcard/attributes-with-wildcard appeared
>      in the configuration file".

With this the filesystem at least adds some unique abilities.

If anyone really needs it and where/how it should be implemented is
another matter.

Without it it's a glorified and complicated drop-in replacement for
a static /dev/.

Regards,

Indan


-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html