[email protected] wrote: > No, I used strings_group. I don't even see name_group in caitsith doc.
Oops. I didn't check the manual. s/name_group/string_group/ > You are right. So to protect against intentional deletion/tampering I need to > restrict remount of all upper level directories too. Hm. I don't see general > tools in > caitsith for that. To understand your wish, you need to understand how pathnames in Linux are managed. And you will find that trying to perfectly protect from intentional deletion/tampering using pathnames fails. There was a very long history of battle between pathname based access control (e.g. AppArmor) and inode based access control (e.g. SELinux). Since pathname based access control had an advantage which cannot be achieved using inode based access control, TOMOYO and AppArmor were able to join the mainline. (The advantage is not the ease of use; see http://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf and http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf for examples.) > I remember there is path.ino variable. But it seems it can't really protect > some particular inode from access, since it report only for last element in > the pathname (i.e. full pathname) and parent directory. In Linux, one inode can have multiple pathnames. Therefore, inode can be calculated from pathnames but pathnames cannot be calculated from inode. > If yes, this could be extended to: > > 1 acl traverse path.ino=1234567 path.major=8 path.minor=2 > 1 allow path="/home/backup" > 1 deny > > To allow access to this inode directory only if it is in it's canonical > filesystem place, but not otherwise. This is impossible because of how pathnames are managed in Linux. Three data structures involves here: "struct inode", "struct dentry" and "struct vfsmount". A pathname is converted to a "struct vfsmount" and "struct dentry" pair. "struct inode" can be determined via "struct dentry"->d_inode and parent directory can be determined via "struct dentry"->d_parent . But a "struct vfsmount" and "struct dentry" pair which is needed for calculating a canonical pathname cannot be determined from "struct inode". Therefore, we cannot calculate a pathname from "struct inode". When checking whether traversing a directory inode which has path.ino=1234567 path.major=8 path.minor=2 attributes is allowed or not, we cannot calculate a pathname because only "struct inode" is available when the hook for checking permission is called. On the contrary, we have hooks for checking permissions (which TOMOYO, AppArmor, AKARI, CaitSith uses) which are called after a pathname was converted to a "struct vfsmount" and "struct dentry" pair. We can calculate a pathname from these hooks but we cannot determine whether we have traversed a directory inode which has path.ino=1234567 path.major=8 path.minor=2 attributes or not. > People, to access protected data, still need to _traverse_ path, so if it's > possible to have operation like 'traverse' and apply rules to it if it's > anywhere in the file path that would be useful. Example suggestion: > > 1 acl traverse path.ino=1234567 path.major=8 path.minor=2 > 1 deny > > Is this possible to implement? I won't try to implement it. The concept of canonical pathname does not work. Trying to restrict based on grandparent directory's inode and/or its ascendant inodes above does not work because only last component's inode and its parent directory's inode are guaranteed to be checked, for a process might request pathnames relative to current directory (e.g. unlink("yourbackup") rather than unlink("/home/backup/year/month/day/yourbackup" when its current directory is /home/backup/year/month/day/ ). People can access protected data using relative pathnames. This means that, a directory with "path.ino=1234567 path.major=8 path.minor=2" may not be traversed when accessing a file which is located as a descendant of the directory. Also, /home/ or /home/backup/year/month/day/ might be bind mounted to somewhere else. If you use pathnames in your rules, please understand and accept that the rules are not compatible with read-only mounts/directories. _______________________________________________ tomoyo-users-en mailing list [email protected] http://lists.sourceforge.jp/mailman/listinfo/tomoyo-users-en
