Hi,
I am working on adding more access control in "configfs".
In current state, the ACL's are not very fine-grained to allow "who"
can modify "what" in "configfs"
Currently we can have ACL's like "Can Process A write into configfs?"
But I am working on possibility of having ACL's like
"Can process A configure the resources of only process B?"
I am planning to use SELinux framework to do so.
Currently I guess SELinux provides only one security-context for
entire configfs filesystem, which is not enough to achive
above-mentained fine-grained control.
I am thinking about adding few LSM hooks into CKRM code which will
call SELinux for checking policies and ACL's before changing the
resource allocation. And depending on response from policies given to
SELinux framework, decision can be taken to either allow or disallow
the resource allocation modification.
These security hooks has to be at proper places inside CKRM so that it
will have enough semantic information required to take decision by
SELinux.
As a simple example, consider the cpuset pseudo filesystem. Processes may
write a pid in string form to one of the files in order to act on the
process with that pid. Simply controlling writes to the file doesn't
enable us to control what processes you can affect; we needed a security
hook in that code after looking up the pid to check whether you could
affect that particular process. (based on its security context)
---------------------->> (Example borrowed from Stephen Smalley)
To add such security hooks, I think, we need to do following changes.
-----------------------------------------------------------------------------------------------
Add security_context to res_group structure in (include/linux/res_group.h)
------------------------------------------------------------------------------------------------
We also need to add following hooks to CKRM code.
All these hooks are mint to control some specific action.
I can think of following actions to be controlled using SELinux.
------------------------------------------------------------------
1. Can process A "create new res_group" in existing res_group C ?
---> Hook for creating class can go in function "make_rgcs_rgroup"
(in kernel/res_group/rgcs.c).
This function have information regarding which task is
creating res_group and
in which res_group is it getting created.
------------------------------------------------------------------
2. Can process A "delete" res_group C ?
---> Hook can go in function "rgcs_rgroup_release_item" (in
kernel/res_group/rgcs.c).
This function have information regarding who is deleting
which res_group.
------------------------------------------------------------------
3. Can process A "modify the share" of res_group C ?
---> Hook for changing the share can be added in function
"set_shares" (in kernel/res_group/rgcs.c).
------------------------------------------------------------------
4. Can process A "see the status" of res_group C ?
--> Hook can go in "show_stats" in (in kernel/res_group/rgcs.c).
------------------------------------------------------------------
Actions like "Can process A "add" process B in res_group C" will be
having some difficulty as it is involving 3 ojects and one action (ie
"add"). And SELinux ACL's normally work on two objects at one time, So
I am planning to break it into sub-actions as follows.
5. Can process A add process B in res_group C ?
1. Can process A write in res_group C ?
2. Can process B be member of res_group C ?
3. Can process A controls grouping of process B ?
---> All these three hooks can go in "set_res_group" in
(in kernel/res_group/task.c).
as access to res_group C and task_struct for A and B.
------------------------------------------------------------------
I have not tried to control "resource-controllers" from SELinux ACL's.
Those ACL's will be on following lines
"Can process A 'modity' share of res-group B only for resource type 'CPU'."
I dont know if even that is required. I feel that will be overkill.
With the rules that I have planned, If process A can modify shares of
res-group B, then it can modify all of its shares.
---------------------------------------------------------------
I am looking forward for some feedback on the direction I am moving..
I will also like to know if these hooks are correct and enough.
Please feel free to correct me if I am going wrong.
Thanx,
--
Pravin Shinde
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
