On Mon, Apr 19, 2010 at 11:53 AM, Karl MacMillan <karlwmacmillan@xxxxxxxxx> wrote: > On Mon, Apr 19, 2010 at 10:33 AM, Daniel J Walsh <dwalsh@xxxxxxxxxx> wrote: >> >> If you look at the interface userdom_read_home_certs. >> >> [InterfaceVector userdom_read_home_certs $1:source ] >> $1,home_cert_t,file,read,lock,getattr,open,ioctl >> $1,home_cert_t,dir,ioctl,search,read,lock,open,getattr >> $1,home_cert_t,lnk_file,read,getattr >> $1,home_root_t,dir,getattr,open,search >> $1,home_root_t,lnk_file,read,getattr >> $1,user_home_dir_t,dir,getattr,open,search >> $1,user_home_dir_t,lnk_file,read,getattr >> >> A domain that is allowed to search the homedir is always going to >> generate an AVC that is a long way off. >> > > Seems to me that the problem is that the read / getattr on > user_home_dir_t directories and files is adding too much distance. > I looked at this a bit more - there are a few interesting issues: 1. The open permissions have not been added to the perm_map file (patch attached to fix that). When there is no perm map then we weight the permission at 5 and assume read and write. Since we heavily penalize providing a write interface for a read access request, this causes the return of a large distance (as I believe that it should). I'd like to find a long term home for the perm map file that increases it's likelihood of being updated with new permissions (Chris - what do you think of including this with reference policy?). 2. As I mentioned, the weighting on things like reading a symlink or directory contents is fairly high. For this use I don't think that's appropriate - the attached perm map patch also reduces these pretty drastically. 3. The bulk of the rest of the distance comes from the unrelated type/object access. We get access to 4 type/object class pairs that aren't requested. Unfortunately there is no tracking of the notion of related access or scaling of the type penalty based upon how minor the related access is. Perhaps we should scale the type penalty with the permission weighting? 4. The final issue is that this interface is a bit broad for the requested access - requesting getattr for the cert files and getting read is a pretty significant bump. Once you resolve the perm_map issue then the distance is just over the threshold - which is about where I was aiming with this algorithm (go me). Now, the reality is likely that a read would come right after this getattr - if that had have been in the audit log all would be fine. Having said that, I'm not against making the threshold a little higher to return these (another patch attached). Long term, I wonder if we should return interfaces above the threshold but commented out with a note explaining that the interface, while providing the requested access, is potentially dangerously broad. Dan, any chance you want to add that feature? Karl >> I thing we should either remove the bastards and just add all as childs, >> or recode it like the attachment. >> > > I'm against removing the threshold altogether - if we do that then > we'll get a match for almost everything including completely wrong > interfaces. Can we start with tweaking either the perm weights or the > distance calculation? For example, what happens when you drop the > weight for dir read down to 5 or 1 and similar for lnk_file (they are > both 10 right now)? After that we might need to tweak the threshold. > > Also - I've been hacking on a patch to add in attribute access to the > interface vectors. Any idea how much help we would get from that? > > Karl > >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.14 (GNU/Linux) >> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkvMacAACgkQrlYvE4MpobNeAgCfcoVssEQJ8mfZT/aBvAt0z7+3 >> CoMAnR1bOcXk7x/jIZ+0i2Kc/faUJAVk >> =Uuf7 >> -----END PGP SIGNATURE----- >> >
Attachment:
0001-Update-perm-map-with-open-permissions.patch
Description: Binary data
Attachment:
0002-Increase-the-matching-threshold.patch
Description: Binary data
