On Mon, Aug 12, 2013 at 07:20:13PM -0700, John Johansen wrote: > On 08/12/2013 05:00 PM, Steve Beattie wrote: > > To be clear, the hash value is of the profile blob minus the header, > > which means skipping the protocol blob version and the namespace, if > > any, correct? At least, that's based on my incomplete understanding > > and read of the policy_unpack code this would apply against. > > > > I guess it's okay that the same policy under multiple namespaces > > results in the same hash (just trying to understand the implications > > thereof). > > > it is, the implication is that information isn't part of the hash. This > is both good and bad. Its possible for profiles under different versions > to have the same binary format and thus the same hash.
Yes, I can imagine an upgrade situation where the parser is upgraded to a new version which supports a new protocol version, but the kernel is still the old one, and the binary format happens to be identical (admittedly, somewhat unlikely, but probabilistically I would expect to be more likely than an actual sha1 hash collision). This could lead to someone believing mistakenly that some profiles may not need to be reloaded for a time. > Ignoring the namespace means profiles that are the same under different > namespaces should have the same hash. Which I *think* makes sense, I can see it being useful to know that the loaded ping profile in all your namespaces is visibly consistent in an obvious way. > It might be an idea to seed the hash with the profile version for each > profile and ignore the namespace. Or if we really want the namespace > info so that profiles loaded to different namespaces have different hashes > we could prepend that as well. I think it makes sense to include the protocol version, but not the namespace as part of the hashed data. > we are going to need an aa-hash tool to generate and compare these hashes Agreed. > whether we do it from the parser, or parsing the binary blob I don't care. This comes back to the incomplete[0] discussion we had about source layout. I think we both share a vision that as much functionality ought to be pushed into libraries with wrapper executables around them and language bindings that permit their use by other languages. In such a scheme I'm envisioning multiple libraries and thus multiple source (sub)directories. I would envision the hashing functionality to be self-contained in such a dir. As such I kind of see keeping it separate from the parser bits. [0] Incomplete because I failed to follow up on it. -- Steve Beattie <sbeat...@ubuntu.com> http://NxNW.org/~steve/
signature.asc
Description: Digital signature
-- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
