> 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.
I know, I read the doc. I also studied the code of pam_selinux and I'm confident that implementing either a) or b) will not be difficult. However as it would mean a non-trivial modification in external package (which probably isn't desirable to happen fast), I agree that solution c) is the best initial solution. I just wanted to outline what other options are there, since that was also a part of that initial discussion. Thanks Jan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
