On 1/24/2018 2:31 PM, Ximeng Guan wrote: > Hello, > > I am trying to make some effective use of machine groups in AFS to > accommodate certain requirement of licensed software. I read about the > feature, and noticed that in the 1998 edition of the book "Managing AFS, The > Andrew File System" by Richard Campbell, the following text appeared in > Chapter 7 p.230: > > "... > There is one final quirk to the implementation: it's common for several > top-level directories of the AFS namespace to be permitted only to > system:authuser, that is, any user can access the rest of the namespace, but > only if the user has been authenticated as a user, any user, of the current > cell. Machine groups are intended to be useful for any person logged in to a > workstation so that software licenses can be honestly followed. Therefore, > when an unauthenticated user is using a machine that is a member of a group > entry on an ACL, the user's implicit credential is elevated to > system:authuser, but only if the machine entry in the group is an exact > match, not a wildcard. > > This rule permits any user of a given desktop to effectively have > system:authuser credentials for a directory. As long as that directory has an > ACL that includes the specific machine's IP address as a member of a group > entry, any user of the desktop, and only that desktop, would have access to > the directory. > ... > "
This text was true prior to IBM AFS 3.2 but has not been true for any release since IBM AFS 3.3. As of AFS 3.3 the Current Protection Set for a host includes neither system:anyuser nor system:authuser. In other words, hosts are not users. > That is exactly what we have in the top-level directories in our cell: We > have "system:authuser rl" on the ACL of root.cell. > > Access list for . is > Normal rights: > system:administrators rlidwka > system:authuser rl > > Then when I create a machine-based pts entry 10.12.8.31, add it to a new > group named machinegrp, and wait for >2 hours to let it be effective > (according to dafileserver's man page) > > $ pts member machinegrp > Members of machinegrp (id: -250) are: > 10.12.8.31 > > I would expect that a local user on 10.12.8.31, even without an AFS token, > would be able to "cd" into the top directory of the cell. But in reality that > does not happen. An unauthenticated user is denied of access. This is working as designed because the ACL does not include the host identity. > > When I explicitly put "machinegrp rl" on the ACL of the cell's top directory > (root.cell), an unauthenticated user is indeed able to access the AFS space. > > This is not quite convenient, because to allow the user of that specific > machine to launch a license software installed in a certain (deep) directory > under AFS, for example /afs/cellname/tools/vendors/abc/softwarexx/bin, we > would have to explicitly place "machinegrp l" on the ACL of the parent > directories of ./bin from /softwarexx all the way up to /cellname. > > Then if we have another software and another machine group, we will have to > do the same again, and the ACL of our root.cell directory will soon be > populated with machine group entries. That does not seem to be an elegant > solution. > > Did I miss anything here? Perhaps. The problem you are attempting to solve is that there exist directories and files that must be accessible only from a particular subset of trusted machines. This data is only supposed to be visible to users of those machines and no one else. What you are possibly missing is that IP ACLs are not a form of authentication and they cannot be used to provide any integrity protection or wire privacy. Any data that is accessed by the host without a user's AFS token is going to be transmitted in the clear. In addition, IP addresses can be spoofed. This use case is one that AuriStorFS was explicitly designed to address. AuriStorFS client hosts can be keyed using Kerberos v5 principals. AuriStor's RX security class supports combined identity authentication providing the file server both the identity of the user and the identity of the host. Finally, the AuriStorFS Access Control language permits different access permissions to be granted to each of the following combinations: authenticated user on unauthenticated host authenticated user on authenticated host anonymous user on authenticated host anonymous user on anonymous host The anonymous user on authenticated host communications with the file server are authenticated using the host principal and all data is both integrity protected and encrypted for wire privacy. Jeffrey Altman AuriStor, Inc.
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
