Re: reiser4 plugins

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle Moffett wrote:
> On Jun 26, 2005, at 22:37:48, David Masover wrote:
> 
>> $ make -C linux-2.6.12.zip/.../contents
> 
> 
> I've yet to see how such automatic unzipping does not inherently  introduce
> system insecurity into _existing_ applications by changing POSIX and  UNIX
> semantics.
> 
> When I do this in my suid perl script:
> 
> open my $fh, '<', $ARGV[0];
> 
> I do _not_ mean this:
> system '/bin/zip', 'x', $path1, $path2;
> 
> Neither do I want the kernel to unzip it, because that just  introduces the
> kernel to a whole series of normally application-level vulnerabilities.

That just means the zip plugin has to be more carefully written than I
thought.  It would have to be sandboxed and limited to prevent buffer
overruns and zip bombs.

I think that you could create a situation where an untrusted zip could
be explored, and the worst side effect would be that the files you see
inside the untrusted zip wouldn't be what you expect.  But that's no
surprise -- if the zip is really malicious, there's no amount of
sandboxing that would give you valid files anyway.

I was probably taking this too lightly, though.

Remember that zip, at least, would not be in the kernel.  I think what
is going in the kernel is gzip and lzo, and it's being done so
transparently that you never actually see the compressed version.

> Can you illustrate for me with precise, clear, and unambiguous arguments

That will take some time.  And some thinking.

> how this can avoid all possible pitfalls,

Especially if you want perfection.

> including the automatic encryption/decryption and most other non- standard
> filesystem features (Basically the whole '...' directory), should  probably
> be left out of any patch submitted for inclusion until they can be 
> _proven_
> (or at least thoroughly checked) not to have undesirable results.

I am doing that out of habit.  Actually, it probably ends up more as:
  .../foo.zip/
instead of
  foo.zip/.../

But, it is left out.  At least that interface.

Now, the cryptocompress as it currently stands does not involve ... and
does not introduce any new security holes in the way that you are
describing.  There might be some issues with key management (someone
hinted vaguely at that), but nothing insurmountable.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQr9xZ3gHNmZLgCUhAQKmOA/9EGus4fGXKnBPoK4Rpd9K/6tgy0A7QFIO
EeF50BSgl7M5sot9Vp28Dg1DA9X8gXHf/BxWIUse2doEdrbYKy3HFNd4ZChPFXCS
j4ZtJo/eGYQntIFZ+exNJG2gDeprSBUH9AnMxF9xBfG8CxBdl6WL1dx8d7kc7ip/
UYGiu+9WmC9LanEb0ezhsO8I0KBvjx73Q3FTbD9N0cMIzK1Drv7p9r9rhswsoIzg
eZnKrT2Z0u8BASbd0GfCAT3DH3Zn6zHf6Zk9FOaPaqcLwWlXbELaTbFvBp+2rpnH
9j3NwKHTtCKX5Z2BOQqtiEDEE8QInuDlcEV2K/y4g9YM1mMw3TNoXswaZrbPWWeF
RD/YyzknaDhfgQdz9kQ2bfHJM7//Y9IUJZp/3NmWhvhc2+QBhXBBoTb8UEnRl7tK
D9UIgsDFDVHlLcO9KPKokjyf3fRL57dd0ictHFORvicVIK6NFSfFP9LY/ZsmUXF9
Fbqwwuu8/5n9z5j9IyIqf5m7XJkHcZCeLFDkn89VS4ZM8W1aB0g3yRIlhSEDDkVt
0nZZRzvIlRHCPoPMZuoFhWSngi50ZAYXlRicKrHQERP8f7ECkB1JvY2rLSFqM+FX
BGUZpXxgHe/zgg806ACNbfdnny5WgZ7qXl/IXD9svQa3lIgxY6We8ACj8Oi6c7eu
5ooBcT7AmRE=
=pBA8
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/