14:01:17 <sgallagh> #startmeeting OpenLMI (2013-11-04)
14:01:17 <zodbot> Meeting started Mon Nov  4 14:01:17 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:26 <sgallagh> #meetingname OpenLMI Public IRC Meeting
14:01:27 <zodbot> The meeting name has been set to 'openlmi_public_irc_meeting'
14:01:33 <sgallagh> #chair sgallagh tsmetana jsafrane rdoty
14:01:34 <zodbot> Current chairs: jsafrane rdoty sgallagh tsmetana
14:01:40 <sgallagh> #info Meetings are recorded and will be posted on www.openlmi.org. Opinions expressed do not necessarily reflect the reviews of the participant's employer.
14:01:49 <sgallagh> #topic Roll Call
14:01:53 <sgallagh> Who is around today?
14:02:05 <rdoty> Russ Doty
14:02:13 <kkaempf> Klaus Kämpf
14:02:18 <praveen_pk> Praveen Paladugu
14:02:24 <jsafrane> Jan Safranek
14:02:27 <rnovacek> Radek Novacek
14:04:11 <sgallagh> #info Attendance: Stephen Gallagher, Russ Doty, Klaus Kämpf, Praveen Paladugu, Jan Safranek, Radek Novacek
14:04:23 <tsmetana> Tomas Smetana
14:04:27 <sgallagh> #undo
14:04:28 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xda68450>
14:04:36 <sgallagh> #info Attendance: Stephen Gallagher, Russ Doty, Klaus Kämpf, Praveen Paladugu, Jan Safranek, Radek Novacek, Tomas Smetana
14:04:52 <sgallagh> #topic Follow-ups
14:05:11 <sgallagh> So last week we had a very lively discussion with praveen_pk
14:05:45 <sgallagh> There were two main topics: access to the BMC and access-control at the provider level.
14:06:44 <praveen_pk> For publishing the BMC information, we worked out the initial model, and we should be good to start working o it
14:07:02 <sgallagh> praveen_pk: That was discussed on the mailing list, yes?
14:07:11 <praveen_pk> sgallagh: yes
14:07:40 <sgallagh> I saw rdoty's reply, but I'd also like to hear from one of the more low-level developers on the project about whether the models seem sensible.
14:07:40 <praveen_pk> For access-control at the provider level, I sent out an update to the mailing list on Friday
14:08:32 <sgallagh> #info praveen_pk: For publishing the BMC information, we worked out the initial model, and we should be good to start working on it
14:09:08 <jsafrane> I think that we need more groups - like storage op, storage admin, networking op, networking admin etc.
14:09:13 <sgallagh> So as far as the access-control, the determination was that this wasn't being done by the CIMOM itself, but was instead being handed off to the providers to validate.
14:09:37 <praveen_pk> yes
14:09:38 <sgallagh> jsafrane: Groups where?
14:09:54 <sgallagh> (Sorry, trying to maintain context)
14:10:25 <jsafrane> sgallagh: groups/roles of the users, like BMC's Administrator / Operator
14:10:39 <sgallagh> Ah, in addition to those listed in the image attached to the email
14:10:53 <kkaempf> Do we really want a policy layer in the cimom (resp. the providers) ?
14:10:57 <tsmetana> wouldn't the groups have to be more or less hardcoded in the providers?
14:11:01 <sgallagh> #url https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-November/001858.html
14:11:10 <sgallagh> #link https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-November/001858.html
14:11:40 <rdoty> Let's back up a minute - what are our goals for access controls?
14:11:49 <rdoty> Delegation of ability to make changes?
14:11:57 <jsafrane> I was thinking about a layer between the CIMOM and the provider - like CMPI authorization proxy
14:11:59 <rdoty> Control over who can read what?
14:12:01 <sgallagh> #info In Dell's system, the user identity is passed to each individual provider for access-control determination. It is not performed by the CIMOM.
14:12:09 <rdoty> How would it be used?
14:12:53 <kkaempf> iirc sfcb allows to run a provider with user-level privileges. This seems to be a more viable model as it hands off privilege control to the operating system.
14:13:11 <kkaempf> the down-side is that only one user can access one provider :-/
14:13:13 <jsafrane> kkaempf: also pegasus can do that
14:13:40 <sgallagh> kkaempf: Well, presumably a provider could be designed to fork/exec a worker process as a user
14:13:46 <sgallagh> And that's irrespective of the CIMOM in use
14:13:52 <kkaempf> Ack
14:15:19 <kkaempf> I just fear we're adding lots of complexity for little use.
14:15:37 <sgallagh> So I think Russ's point should be addressed first.
14:15:49 <sgallagh> What are the goals we want to accomplish with access-control?
14:16:06 <rdoty> A system administrator should have full root access to the system.
14:16:15 <rdoty> What other users and roles are needed?
14:16:34 <rdoty> (And why?)
14:16:43 <sgallagh> rdoty: Auditing comes readily to mind
14:17:12 <rdoty> How would that work?
14:17:43 <sgallagh> We need to be able to pass the user's identity down as far as possible.
14:18:03 <sgallagh> So we know exactly whose account was used to format the database partition, for example.
14:18:09 <stefw> rdoty, the other big use case, is being able to see stuff, but not change stuff through an openlmi provider
14:18:26 <rdoty> stefw: can you provide some examples?
14:18:28 <stefw> ie: monitor a system vs. configure it
14:18:34 <stefw> yes, you want to be able to see disk state
14:18:40 <rdoty> We can already set read-only access in Pegasus
14:18:40 <stefw> of all the servers on a network
14:18:45 <sgallagh> #info Attendance: Stef Walter
14:18:55 <stefw> but you don't want to be able to make changes
14:18:57 <stefw> rdoty, that's good news
14:19:12 <sgallagh> right now we can only set it globally for a user
14:19:14 <stefw> so you can give the cimom policy that says certain users can only see things, but not run commands?
14:19:15 <jsafrane> I think we already have user name available in the providers
14:19:28 <stefw> that's a good start
14:19:50 <stefw> ideally integrating with PolicyKit would allow cimom policy to be decided that way
14:19:51 <sgallagh> stefw: Meaning that they either have no access, read-only access or full access to 100% of the providers.
14:20:07 <sgallagh> Or rather, the providers in a namespace
14:20:24 <sgallagh> But the inter-relationships of those providers tend to be so tight that separating the namespaces is... difficult
14:20:24 <stefw> right
14:20:56 <sgallagh> I'm working on a patch to OpenPegasus to enhance this limited access control to at least support groups
14:21:00 <sgallagh> Right now it's a user whitelist only
14:22:24 <sgallagh> But again, let's talk about requirements before implementations
14:22:25 <rdoty> kkaempf: what has been your experience with CIM and access controls? Badly needed or not an issue?
14:22:41 <sgallagh> #topic Requirements of access control
14:23:00 <sgallagh> #info rdoty: A system administrator should have full root access to the system.
14:23:23 <sgallagh> #info stefw:  being able to see stuff, but not change stuff through an openlmi provider
14:23:24 <kkaempf> rdoty: Somewhere in between. There are no strict requirements but I do see the use-cases like 'read-only' or auditing. So I do support access control.
14:23:34 <sgallagh> #info stefw: monitor a system vs. configure it
14:23:54 <rdoty> kkaempf: do we need anything more than read/write and readonly?
14:24:03 <sgallagh> #info OpenPegasus has very limited trinary access control right now (user whitelist): No access, Read-Only and Read-Write on a user in a namespace
14:24:07 <kkaempf> rdoty: I just fear we're opening a can of worms here.
14:24:11 <stefw> it's not just about access control though
14:24:30 <stefw> although that is a solid issue to tackle
14:24:33 <rdoty> kkaempf: Yes! How big is the can and how many worms?
14:24:39 <stefw> it's about preserving the identity of the user performing the operation
14:24:42 <kkaempf> rdoty: r/w and r/o plus logging the user identity for audit is sufficient imho
14:24:52 <rdoty> And are the worms harmless or poisonous?
14:25:04 <sgallagh> rdoty: Your metaphor is falling apart
14:25:06 <stefw> and making that identity available to auditing, access control, and session management
14:25:07 <kkaempf> rdoty: we need to work upstream (cmpi definition) to get this properly established
14:25:24 <rdoty> That's an interesting place to put the work
14:26:10 <rdoty> kkaempf: One of the questions that has been raised is "do we need to let certain groups only see part of the CIM data?"
14:26:17 <rdoty> And if so, how do we regulate that?
14:27:17 <rdoty> Also, praveen_pk - you probably have the most experience of anyone on access controls for CIM. What are your observations?
14:27:17 <kkaempf> rdoty: Such details belong to the application level. I can't imagine doing this properly on the cimom/provider level.
14:27:32 <sgallagh> That's really the crux of the question to my mind. Assuming that we maintain the user identity all the way down the stack, do we have need of more detailed access-control than the trinary states I described above.
14:27:45 <rdoty> kkaempf: Ummm... Can you expand on "application"?
14:28:06 <kkaempf> rdoty: the code issuing the cim/xml requests to the cimom.
14:28:12 <sgallagh> Of course, I'm interested to hear jsafrane's thoughts on a CMPI authz proxy.
14:28:21 <praveen_pk> rdoty: unfortunately, don't have much experience with CIM access controls. One of our Dell Internal teams does, which I am not part of.
14:28:39 <rdoty> kkaempf: If we do it client side, can't people work around it by writing directly to CIM/XML?
14:28:52 <sgallagh> praveen_pk: Would it be possible to convince a representative of such a team to participate in the email discussion or at next week's IRC meeting?
14:29:02 <rdoty> Our major focus is on providing CLI and scripting; I don't see how client side controls would work...
14:29:06 <praveen_pk> sgallagh, will try
14:29:17 <sgallagh> praveen_pk: Thanks!
14:29:49 <sgallagh> #action praveen_pk to attempt to recruit Dell access-control representation
14:30:05 <kkaempf> rdoty: only if they have credentials to the cimom
14:30:34 <kkaempf> rdoty: in sfcb you need to belong to the sfcb group
14:31:10 <sgallagh> Right, and in Pegasus (right now), it's a per-user whitelist, defaulting only to 'root' and 'pegasus' (with the latter being disabled on the system by default)
14:32:16 <sgallagh> We need to figure out how much security is enough.
14:32:40 <rdoty> And how much people will use. Which may not be the same...
14:32:48 <sgallagh> stefw: If we got the user identity down to the CIMOM and had it logging its calls to the provider, is that sufficient for auditing in your mind?
14:32:51 <stefw> and how much is a requirement...
14:33:00 <stefw> ie: like auditing needs
14:33:17 <sgallagh> Or is it more important to bring the user all the way into the provider (running *as* the user) and using something like PolicyKit to grant the escalation back up to invoke the change?
14:33:54 <stefw> my assumption is that it is the latter, but it may be worth asking sgrubb about auditing requirements.
14:34:07 <jsafrane> just for the record, AFAIK Microsoft has list of allowed users for a namespace, no 'roles'/'groups'
14:34:07 <stefw> the entity doing auditing is a trusted part of the audit system
14:34:35 <sgallagh> Well, sgrubb will always tell you that it must be audited at the kernel, but he's a purist :)
14:34:41 <stefw> heh
14:35:01 <stefw> i'm not against having caller do access control
14:35:16 <stefw> in the cockpit project (a UI for servers)
14:35:19 <rdoty> stefw: how would that work?
14:35:22 <stefw> we've talked about how we migth implement that
14:35:23 <stefw> https://raw.github.com/cockpit-project/cockpit/master/doc/cockpit-transport.png
14:35:33 <rdoty> stefw: for the CLI/script case?
14:35:46 <stefw> no, this is specific to UI cases
14:35:54 <rdoty> I can see how to do it inside Cockpit, but not for the API
14:36:06 <stefw> we've discussed how we would not use the CIMOM for remote access at all
14:36:10 <stefw> and not use it for authentication
14:36:12 <sgallagh> Right, and the key question here is: how important is that?
14:36:27 <sgallagh> (That was for Russ)
14:36:31 <stefw> but locally connect to it once we have already authenticated and checked with system policy about a given CIM request.
14:37:03 <sgallagh> stefw: Sure, but we do have the option to talk about moving that policy into either the CMPI layer or the provider layer
14:37:19 <stefw> right, that would be the rigth architecture, in my opinion.
14:37:27 <sgallagh> Given what praveen_pk has reported about Dell's usage, this seems to be acceptable to the CIM standard as well
14:37:34 <stefw> that's good to hear
14:37:53 <rdoty> Umm, is Dell's implementation DMTF/CIM compliant?
14:37:55 <sgallagh> So to me, it's a matter of striking the right balance between control and difficulty of implementation
14:38:08 <stefw> the wrapper/local-access approach seems like a workaround for current identity/audit/access-control lacks in our cimom
14:38:18 <sgallagh> rdoty: As near as I can tell, the providers are just returning an error when it can't complete
14:38:22 <sgallagh> Which is perfectly valid
14:38:38 <fche> (without enough control, implementation may be moot; there is a minimum degree of security sysadmins will require)
14:39:23 <rdoty> sgallagh: my understanding is that Dell is using the DMTF/CIM technology stack for communications.
14:39:43 <rdoty> fche: don't sysadmins use root or su today?
14:39:59 <rdoty> fche: what security do sysadmins require?
14:40:15 <fche> that could be sufficient, but 'course we're talking across-the-network, so it's trickier
14:40:33 <stefw> rdoty, sudo has auditability...
14:40:35 <stefw> that's exactly the point
14:40:45 <stefw> you get a loginuid assigned to thte process tree started from your ssh login
14:40:50 <stefw> then when you sudo, your loginuid stays the same
14:40:58 <stefw> so the kernel auditing infrastructure can tell it's rdoty doing that action
14:41:00 <rdoty> Sure, we need to have audit; no argument there.
14:41:03 <stefw> even though he is now uid = 0
14:41:11 <rdoty> What about fine grain access controls?
14:41:25 <stefw> from the cockpit perspective, we want to have roles, such as monitoring roles, or junior admin roles
14:42:24 <stefw> just like you can give someone access to tail /var/log/messages
14:42:29 <stefw> but not necessarily change it
14:44:00 <stefw> in most cases the current crop of system management daemons allow for this.
14:44:10 <sgallagh> stefw: I agree that this is ideal. I'm asking what level is *necessary*.
14:44:12 <stefw> for example realmd lets you see what domain you're joined to, but not leave a domain, withuot credentials.
14:44:29 <stefw> sgallagh, as i said above none of this is *necessary* if we wrap the CIMOM and only use local access
14:44:45 <stefw> or not use CIM for certain operations
14:44:45 <sgallagh> Well, that's from the perspective of a single consumer.
14:44:54 <stefw> right
14:45:04 <sgallagh> If we're talking about OpenLMI as the definitive remote scripting interface... discuss :)
14:45:08 <stefw> CIM and OpenLMI retains it's current use cases without such modifications
14:45:34 <stefw> in order to grow into further use cases, additional architecture requirements become apparent
14:48:57 <sgallagh> I get the feeling we're all talking past one another.
14:49:20 <stefw> sgallagh, yes perhaps
14:49:53 <sgallagh> We acknowledge that we *can* implement as fine-grained an access control as one could possibly want. We can do the CMPI authz proxy or we can have all providers fork/exec as the user and request PolicyKit escalations.
14:50:25 <sgallagh> But the question I'm trying to answer is: how much do we absolutely have to do (and will people be willing to actually configure)?
14:50:32 <sgallagh> Where's our biggest bang for the buck?
14:51:06 <stefw> to me, that really depends on the scripting requirement for access control
14:51:25 <rdoty> praveen_pk: it would be very helpful to have some information on how iDRAC users configure the access controls.
14:51:33 <stefw> because from a UI perspective the solution of wrapping the CIMOM access and just using it locally, is a really decent solution.
14:51:47 <rdoty> Do they use them, do they just give everyone full access, or something in the middle?
14:51:56 <sgallagh> rdoty: What are your thoughts on that: how much control (let's ignore auditing for the moment), do you think customers want from the scripting environment?
14:52:12 <praveen_pk> rdoty: will check and get back how the access controls are defined
14:52:30 <rdoty> sgallagh: that's the question we are wrestling with.
14:52:46 <rdoty> My take is that system administrators need full access (with auditing)
14:53:05 <sgallagh> #info All agree that proper auditing is necessary
14:53:20 <rdoty> Other users, especially monitoring, may get by with restricted access. But how/where?
14:53:22 <sgallagh> #info Much debate as to the level of access-control that is sufficient vs. complete.
14:53:50 <sgallagh> #info rdoty My take is that system administrators need full access (with auditing)
14:53:56 <rdoty> I don't see a real use case for "allow this user the ability to configure storage but not see network configuration details"
14:54:00 <sgallagh> #info rdoty Other users, especially monitoring, may get by with restricted access
14:54:12 <sgallagh> #info rdoty I don't see a real use case for "allow this user the ability to configure storage but not see network configuration details"
14:54:22 <sgallagh> I find myself largely in agreement with that assessment.
14:54:33 <stefw> that's because that is completely the wrong granularity
14:54:42 <rdoty> I would suggest that we need specific real-world use cases for restricted access, which we can evaluate on a case by case basis.
14:54:44 <stefw> when you see everything in terms of providers, then yes, it does look awkward.
14:55:08 <rdoty> For the moment, we should proceed with the Pegasus trinary model
14:55:08 <sgallagh> stefw: What perspective do you see?
14:55:23 <stefw> that within a provider a user may be able to do some operations, but not others
14:55:36 <stefw> for example someone may be able to place a spare into a raid array
14:55:43 <stefw> but not necessarily destroy the array
14:55:52 <stefw> i'm speaking to the ideal here
14:56:06 <stefw> and i understand this is hard to implement within the current architecture of the cimom
14:56:13 * sgallagh nods
14:56:21 <stefw> PolicyKit and the various system management daemons that we have today, do have the architecture to implement this.
14:56:32 <stefw> although not all do, and we don't take advantage of this
14:56:45 <rdoty> Ah. That is a critical point.
14:56:52 <stefw> but in the future
14:56:56 <sgallagh> stefw: So I take it that you recommend the "have all the providers run as the user and authorize with PolicyKit" approach?
14:56:57 <rdoty> "We aren't doing it today, but we could"
14:57:03 <stefw> we *are* doing it today
14:57:06 <stefw> but not everyone is doing it.
14:57:14 <stefw> and it's not as fine grained as it it could be
14:57:16 <rdoty> Expand, please
14:57:18 <stefw> by default
14:57:18 <stefw> yes
14:57:35 * sgallagh cautions that we have two minutes remaining.
14:57:48 <rdoty> Let's take this to the mailing list.
14:57:59 <rdoty> I'd like to see details on use cases and capabilities.
14:58:12 <stefw> but again to frame all of this
14:58:16 <stefw> we have a solution
14:58:16 <rdoty> And I have grave reservations about the use of fine grain access control in the real world.
14:58:20 <stefw> to implement these things
14:58:25 <stefw> by not using all parts of the CIM stack
14:58:30 <stefw> and it's a decent approach
14:58:34 <stefw> if CIM wishes to fill more roles
14:58:43 <stefw> then there's that balance between complexity of a requirement
14:58:44 <sgallagh> rdoty: Well, the nice thing about fine-grained access control is that you can still flip all the bits to "yes"
14:58:48 <stefw> compared with the use cases that it facilitates
14:59:12 <rdoty> sgallagh: at which point your investment is not justified...
14:59:34 <sgallagh> rdoty: Yes, I realize that.
14:59:37 <rdoty> And if people are going to do that, why build the controls?
15:00:06 <sgallagh> Well, the infrastructure to do that also overlaps very well with the infrastructure needed for in-depth auditing
15:00:24 <sgallagh> So it may not be much extra effort atop that
15:00:32 <rdoty> sgallagh: should we have an in-depth discussion of auditing next week?
15:00:40 <sgallagh> In any case, we're at the top of the hou
15:00:42 <sgallagh> *hour
15:00:59 <sgallagh> rdoty: Yes, I think we should consider having a formal agenda next week
15:01:27 <sgallagh> #info Auditing will be the primary agenda item for next week's meeting
15:01:43 <sgallagh> Thank you everyone for coming, sorry we ran a couple minutes over.
15:01:54 <sgallagh> Please continue the discussion on the mailing list.
15:02:00 <sgallagh> #endmeeting