(2010/01/22 5:36), Dustin wrote: > > On Jan 21, 1:00 am, KaiGai Kohei<[email protected]> wrote: > >> * Again, the engine framework is not designed to host multiple modules >> in usual way. If a security module occupies the engine framework, it >> also has to load another module that provide physical storage engine, >> by itself. (Or, security module also has to provide i/o feature? it >> is quite nonsense.) > > It's not *entirely* clear what you mean by this. I do use the > engine to load multiple sub-engines that are separate and provide > security isolation.
What I wanted to say is, it is not an essential job for the security module to load and manage sub-modules, although it is possible. Basically, I don't think the security module should touch something corresponding to physical i/o operations. As long as user have enough privileges, it should call the secondary engine module without any preventions. If it does not need any additional properties on the session and items to be accessed, the matter is not too hard. The security module just track the entry points of secondary module, and can call it on its invocations. However, the secondary module may want to use conn->engine_storage, although the security module also want to cache the user's privilege. In addition, format of the item object is depending on the secondary module, so the security module cannot modify it in discretionary. If we focus on the security design that enforces simple isolation between (authenticated) users, we don't need store any additional security properties in item objects. But, it is not flexible. >> * The engine framework does not provide a hook just after a connection >> from client is established. It is not a must-requirement. However, >> we want to obtain privilege of the client process, and cache it in >> the userspace. >> If it is not available, we have to invoke a system-call for each >> access control decision, but it will be expensive. > > It certainly does and I use it. You can see it here: > > http://github.com/northscale/bucket_engine/blob/master/bucket_engine.c#L433 Oh, I could not find it. >> * The security module needs its private storage different from the storage >> engine module. >> Now, the conn structure has "void *engine_storage" to store an engine >> private information, but the right to use is closed for the second >> module. > > The engine should be aware of what you're doing with that data, so > it can supply the API to manipulate it. The matter is both of the security module and engine module want to use this private storage for their own purpose. :( >> In addition, the hash_item structure does not provide any private >> storage to store security context of the item (e.g this context will >> record what process create this object). > > Well, no. Expanding the item structure is *very* costly. That > should should be avoided where possible. > > That said, a given engine can define an item to look like whatever > it wants after the base stuff. You'll notice the base structure > doesn't even have a space for the key or data. Yes, do_item_alloc() allocates sizeof(hash_item) plus various length bytes of memory for each items. It is a well known technique to handle various kind of data objects, not only memcached. How much length do you expect for the security property of an item? I plan to add a "void *" pointer which indicates security_id object managed in libselinux. The security_id structure is a pair of security context (cstring) and reference counter. The number of security context is proportional to the number of users, not # of items, it does not cousume local memory so much. >> * The deployment of some hooks makes hard to decide what permission >> should be applied. For example, process_bin_delete() calls "get" >> method to confirm the object to be removed is existing. >> But the "get" method is only chance for the engine module to know >> a certain item is accessed in reader context. >> Of course, if we consider "delete" is a combination of "read" and >> "delete", it will be resolved. But it will damage the flexibility >> of security design. > > This is a good time to be talking about this, as the engine API > isn't dogma yet. Now I lean toward the security purpose framework which provides meaningful hooks for access controls, and capability to assign a security property on the session and items. Is it too early? Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <[email protected]>
