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