On Wed, 2009-04-15 at 16:13 -0400, Stephen Smalley wrote: > On Wed, 2009-04-15 at 12:41 -0400, Eric Paris wrote: > > On Wed, 2009-04-15 at 11:51 -0400, Stephen Smalley wrote: > > > - Using a different class or set of permissions when checking for > > > access(2), likewise requiring reworking the underlying implementation so > > > that we can distinguish the checking from open(2). Then one could > > > choose to use dontaudit rules to suppress the access(2) checking w/o > > > suppressing the open(2) checking. However, this could present a major > > > consistency problem between what access(2) reports and what is actually > > > allowed upon open(2) or execve(2). > > > > Assuming I'm thinking about this the right way, to make this useful we > > must keep the access and the open permissions in sync. For every > > file/read we MUST have an access/read etc. Right? So to solve Dan's > > problem we'd need rules like: > > > > allow my_app_t my_file_t:file read > > allow my_app_t my_file_t:access read > > dontaudit my_app_t my_file_t:access write > > > > I'm worried that Dan would go wild adding > > dontaudit my_app_t my_file_t:access * > > > > Which would be just as bad for the end user experience as simply > > dontauditing them in the kernel (which I won't do) So if we go this > > route, don't do that dan. > > > > > > Now I could probably do some sort of fancy black magic in the kernel > > whereby we actually check file/* for the permission but display access/* > > for the audit message and access/* for the dontaudit rules, but that > > seems very fragile and untenable. Next is how audit2allow is going to > > try to generate a policy with only access/*, which is quickly going to > > fall down next on file/* > > > > I sorta feel like the 'right' solution is going to be forcing userspace > > to keep those 2 in sync. I'm willing to put an in kernel check on > > policy load that rejects policy when they are not in sync... but it > > feels like it should be an all userspace problem. Best in my opinion > > would be to make the userspace tool chain just create the access class > > allow rules out of the file class allow rule, and vice versa..... > > That will generate a lot of policy bloat. It would be far more compact > if we were to define new access_read, access_write, access_execute > permissions in each of the file classes, assuming we still have the > space, and forcibly set those bits whenever we set read, write, or > execute in the same access vector. Note that migrating access(2) to new permissions also requires adding a new policy capability flag to tell the kernel whether the policy expects access(2) to be controlled via read/write/execute or via the new permissions. Otherwise, new kernels with old policies would always try checking the new permissions, and these would either be always denied or always allowed depending on the handle_unknown flag, thereby causing access(2) to either always fail or always succeed (either of which could break applications). -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
