On Tue, Nov 15, 2011 at 09:41:57AM -0600, Eric Sandeen wrote: > On 11/14/11 11:05 PM, Theodore Ts'o wrote: > > Create a version of debugfs which only supports read-only examination > > of the file system metadata (but not the data blocks). The idea is > > that this version of debugfs might be suitable to be setuid root, and > > executable only by members of a particular group, or setgid disk, and > > globally executable, depending on the security/privacy policies in > > force at a particular site. > > Just curious - what problem does this solve? > > (Could the same policies simply make direct access to block devices > read-only for those users, and thus have an fs-independent solution > to whatever problem is at hand?) It's not enough to make access to the block devices be read-only; what's most important in this patch is removing the ability to show data blocks (i.e., removing the debugfs "cat" and "dump" commands). After all, a company with very strict user data privacy policies might require a developer to jump through hoops before getting access which allowed him or her to bypass file system access controls, whether it is logging in as root or installing some setuid/setgid binary which had the effect of bypassing mandatory or discretionary access controls --- which debugfs's "dump" and "cat" commands effectively do. There's another reason for removing all of the commands that might be used to modify file system metadata, as well as forcing the block device to be opened read-only. It makes it easier for a security/privacy committee who might want to audit the code to make sure no one can use the restricted version of debugfs to flip a setuid bit, or change a file's permissions, or some other entertaining file system modification. I could also imagine this sort of thing could also being useful for advanced support personnel who need to go on site (say, at a financial institution in NYC) and who needs to debug a customer's file system or investigate a performance problem. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
