Messages in this thread | | | Date | Thu, 6 Nov 2008 16:11:34 -0600 | From | Michael Halcrow <> | Subject | Re: [PATCH 0/5] eCryptfs: Filename Encryption |
| |
On Thu, Nov 06, 2008 at 02:52:26PM -0600, Dave Kleikamp wrote: > On Thu, 2008-11-06 at 14:27 -0600, mhalcrow@linux.vnet.ibm.com wrote: > > On Wed, Nov 05, 2008 at 04:57:54PM +0100, Pavel Machek wrote: > > > On Tue 2008-11-04 15:37:54, Michael Halcrow wrote: > > > > This patchset implements filename encryption via a > > > > passphrase-derived mount-wide Filename Encryption Key (FNEK) > > > > specified as a mount parameter. Each encrypted filename has a > > > > fixed prefix indicating that eCryptfs should try to decrypt the > > > > filename. When eCryptfs encounters > > > > > > That is 'interesting'. What happens if normal filename has that > > > prefix? > > > > If the lower filename has the prefix but does not have a valid tag > > 70 packet following the prefix, then eCryptfs will complain in the > > syslog and then pass through the lower filename as-is. > > I'd recommend hiding this kind of syslog verbosity behind a debug > config option. I think it would be very easy to create a DOS attack > against ecryptfs by putting all sorts of clever things in the lower > file system.
I instead prefer leaving the default behavior as-is, while perhaps introducing a module option to suppress such warning messages at the user's explicit request. In general, I would imagine that the majority of people would really like to know when a malicious attacker is managing to write bogus mangled eCryptfs-ish files to their lower filesystem, even if the means of transmitting the information about the attack includes the possibility of filling up the syslogs. In other words, if a malicious party is able to write to your filesystem under eCryptfs, you probably have much bigger problems to worry about than just your syslog filling up.
I can imagine some circumstances where filling up the syslog really is worse than ignoring corrupted eCryptfs files in the lower filesystem, but I submit that such circumstances are in the minority. I can also contrive some circumstances where the lower files get mangled through other non-malicious means, but I do not think such circumstances will occur frequently enough to justify the risks from staying quiet about file corruption (malicious or otherwise) in your lower filesystem. So, if I had to pick a default behavior to do the greatest good for the greatest number, I would leave the default verbosity where it is, while providing the admin the option of disabling the verbosity when encountering mangled lower files.
| |