01.01.2013, 09:30, "Tetsuo Handa" <from-****@I-lov*****>: >> 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. Why? I don't agree. > 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.) Great slides, thanks for them. In lfj2008-bof.pdf you say, that to protect /etc/shadow being read if linked to /tmp/shadow pathname based access control needs "to restrict pathname changes", but label based don't need to care about it. So you saying yourself that it is possible to fully control access to /etc/shadow if we also control renaming, linking, mounting. And all these things are controllable. So why you now saying perfectly protecting using pathname based access control fails and I should understand and accept it. I don't understand, if you saying in pdf yourself that it is possible. It just requires more work. Plus, you then prove that this more work is in fact what is may be required and is a good thing. Which I agree. (For example, binding /etc/ to /tmp - we need protection against this, this is pathname based feature, and this also solves problem of /etc/shadow being pathname manipulated.) So why it fail or not compatible with read-only directories? It looks compatible and your words support it. >> 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. I understand that. >> 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". I know. But this is 'traverse' operation, so you possible have parts of pathname (becasue it is supposed to traverse elements of pathname) not just inode numbers. (How is Smack LSM enforce r or x on directory - so probably LSM have some hooks into traverse mechanisms. I don't sure if it have parts of pathname at that time, though, if not, then it is not possible of course.) In any case you maybe able to calculate directory realpath from dentry (just cd to '..' until / is meet, I think that's how realpath is already works.) > 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. That was just example with 'allow path="/home/backup"', but there was other examples too. > 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. But Smack is LSM and it can restrict traverse operation. So there should be some hooks. >> 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. ic. > The concept of canonical pathname does not work. This exampel does not say anything about canonical pathname. It try to forbid traverse by min/maj/inode. > 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/ ). I understand that, but this does not mean this approach does not work at all. For example, if I forbid for some min/maj/inode (directory) access altogether, then user will be not able to chdir to any underlying pathname and then unlink("backupfile"). So this will work. (Plus, we still be possible able to determine realpath of parent directory.) > 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. People will not be able to chdir behing that directory, so it works. > 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. I think they are compatible, or at least step in that direction. We don't need to achieve perfect security suddenly, but can go step by step and see if this helps. Best regards,
TOMOYO
Fork