Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: In-kernel Authentication Tokens (PAGs) | Date | Sat, 12 Jun 2004 17:58:34 -0400 |
| |
On Jun 12, 2004, at 17:44, Chris Wright wrote: > Typically, objects that LSM cares about include a pointer to opaque > data (security blob) which describes the security domain for the > object. > See task->security as an example. It's not clear to me if > task->security > is sufficient and you only need a back pointer to the task or if each > PAG needs it's own security blob.
Ahh, ok. In this case, a PAG is an independent object, not directly associated with any specific task or other PAG, so therefore it will likely need its own security blob. Currently, in the creation of my PAG I just copy over the UID from the calling task. If I was to convert it to use LSM, I guess I should just leave out the UID entirely, and just have a pointer to a security blob. What is the best way to portray the security blob to user-space, in terms of sys-calls? I need a way for user-space apps to change the security context in a similar way as it is changed for a task or process. Do you have a link to some documentation on the kernel API for LSM? I basically need to copy the current task's security blob into a new one and be able to compare two contexts to see if one can affect the other. Thanks!
> Sounds like an extension to rlimits. The counters could be stored in > ->user to limit the userwide number of tokens.
Ok, thank you very much, that's exactly what I need. I am somewhat new to kernel development, so finding my way around the structs is somewhat difficult. Is there a good guide somewhere on the net that you can point me to?
Cheers, Kyle Moffett
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |