On Mon, Feb 13, 2017 at 01:57:58PM +0800, Anand Jain wrote: > I think my any other reason for not having file-name encryption is easily > overridden by the reason that, if file-name encryption is not optional now > then, it would be a regression as because it was indeed optional before, in > EXT4. Are you sure it was optional? If so, when? That would have been a bug, because the inductive requirement of the crypto policy was in the design from the very beginning of our implementation phase. There may have been some design docs that talked about it being optional, but they date from before we started thinking about how to protect against Evil Maid attacks. > Moreover the data center solutions has to worry about the compatibility of > the tools and applications which may or may not run with the uid of the > file-data. Even without file name encryption, some tools and applications can be blocked due to SELinux; does that mean we should give up on SELinux because it breaks "compatibility"? Or if they were expecting to read the data contents, the updatedb(8) program will break once file encryption is turned on. That doesn't mean we should give up on data block encryption. It perhaps might be more useful if you were to talk about *specific* tools and applications you are concerned about, instead of trying to talk about this in the abstract, since by definition enhanced security techniques will always break *some* compatibility --- of rootkits, and attack tools used by Evil Maids if nothing else! Regards, - Ted
