On 01/09/2012 12:18 PM, Jan Zelený wrote: > Hello everybody, > I'm sending a rough design of SELinux rules and the architecture of how I > plan > to implement them. This a plan that I came up with kinda quickly, so it's > rather crude, please consider it only aguidance to show concepts, don't look > for exact attribute names and similar stuff. > > What I'm not completely sure about are those potentially very large filter to > handle everything in very small number of queries to remote server - do you > think it's doable this way or should I rather implement client-side filtering? > > > Assumptions: > =========== > 1. pam_sss will be configured in session part of PAM stack, thus receiving > and > forwarding SSS_PAM_OPEN_SESSION messages > 2. We already have a list of all groups the user is member of when > SSS_PAM_OPEN_SESSION message arrives > > > Chain of actions: > ============== > 1. pam_sss receives and forwards SSS_PAM_OPEN_SESSION to PAM responder > 2. PAM responder issues DP_METHOD_PAM_HANDLER DBUS call with pd->cmd == > SSS_PAM_OPEN_SESSION > 3. IPA provider receives the DBUS method and invokes a callback for new > target > BET_SESSION (or BET_SELINUX?) > 3. IPA provider checks if it is also configured to be used as access provider > 3.1. If not, it queries remote server for host record and related host groups > (I plan to somehow utilize contents of ipa_hbac_hosts.c for that) > 4. One query for applicable SERules, something like: > (| > (HBACRule=*) > (& > (| > (user=<login>) > (user=<group1>) > (...) > ) > (| > (host=<hostname>) > (host=<hostgroup1>) > (...) > ) > ) > (default=1) > ) > 5. IPA provider checks if it is also configured to be used as access provider > 5.1. If not, it performs one query for needed HBACRules and stores them in > sysdb > (| > (dn=<HBACRule1>) > (...) > ) > 6. Filter HBAC rules based on: user/group, host/hostgroup, Allow > 7. Filter SERules based on HBAC dns (basically delete those that were > retrieved from the server based on (HBACRule=*) and the target HBAC rule is > not in the filtered list) > 8. Store filtered SERules to sysdb > 9. Create PAM response of new type SSS_PAM_SEUSER_DATA, send it to responder > 10. Re-send the reply to PAM client > 11. Decode the response and give the list to pam_selinux - here are following > three options how to do that, but I'm not looking for the best solution right > now: > a) pam_setenv/pam_getenv > b) pam_set_data/pam_get_data > c) directly writing to a particular file in /etc/selinux
As far as I know pam_selinux implemented what we outlined here http://freeipa.org/page/Integration_with_SELinux#pam_selinux so c) would probably be best option for now. At least this was the recommendation that we discussed when the original planning for this feature was made couple months ago. > > Any input is welcomed > Thanks > Jan > > > _______________________________________________ > sssd-devel mailing list > sssd-devel@lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/sssd-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
