From ago control wiki
Jump to: navigation, search
[22:18:51]  <jstrom>	 hari: is /command url used by anything, or is it just left over since before jsonrpc?
[22:30:00]  <hari>	 jstrom: leftover
[22:30:26]  <hari>
[22:30:31]  <hari>	 jstrom: ^
[22:31:15]  <hari>	 jstrom: we can kick it i
[22:31:23]  <hari>	 n the trash
[22:31:36]  <hari>	 i wanted to remove it as soon as we introduce auth for jsonrpc anyway
[22:33:31]  <jstrom>	 everything is authed (basic auth) now, right? if enabled
[22:34:09]  <hari>	 yeah, that is just a hack until we have real auth via json-rpc
[22:34:26]  <hari>	 and some kind of a permissions system
[22:34:41]  <jstrom>	 any explicit plans?
[22:35:05]  <hari>	 only rough ideas
[22:35:22]  <jstrom>	 oaky
[22:35:38]  <tang2>	 hari: so how can i do that: replacing "libboost-xxx.49.0" by "libboost-xxx (>=1.49.0)" in debian/control file ?
[22:35:47]  <hari>	 i'm not yet sure how granular access control shall be, and how to let the user configure it
[22:36:03]  <jstrom>	 it's a tricky subject.. balancing security vs usability
[22:36:06]  <hari>	 tang2: iirc wheezy uses the 49 as part of the package name
[22:36:42]  <hari>	 jstrom: and the q is how far we want it to go.. shall just json-rpc do access control, or do we want it on the qpid layer, too
[22:36:56]  <hari>	 e.g. to restrict messagesend, use multiple qpid users, and so on..
[22:37:08]  <hari>	 (also utlizing qpid acls)
[22:37:50]  <jstrom>	 yeah.
[22:38:17]  <hari>	 restrict just on device level, or also on specific commands, parameters, and so on
[22:38:18]  <jstrom>	 device-level security too? user X can accses lighting but not vent controlling
[22:38:24]  <jstrom>	 yea
[22:38:42]  <hari>	 but what my imagination still lacks is how to present that to the user
[22:38:57]  <hari>	 i've seen how folks can be burnt by LDAP ACIs ;-)
[22:39:14]  <hari>	 or iptables rules, or whatever with some complexity
[22:39:40]  <hari>	 and how to store them.. probably not in a .ini :-)
[22:39:45]  <jstrom>	 hehe
[22:39:54]  <jstrom>	 yeah.. teaching users security isn't easy
[22:40:31]  <jstrom>	 but i'm glad to hear there have been some thoughts on it :)
[22:41:36]  <hari>	 jstrom: if we'd work with multiple queues on qpid, we could restict specific users to specific queues, and have devices only on some queues, and so on
[22:41:55]  <hari>	 but things ain't get simpler by that..
[22:42:24]  <jstrom>	 especially not if you want to add another users which uses both..
[22:42:48]  <jstrom>	 I dont know too  much about qpids security details
[22:43:13]  <jstrom>	 but I guess it cannot control on the contents of the message? i.e. to restrict command to a specific device, you'd still need ACLs in the end-node
[22:43:25]  <hari>	 you can do a lot, but not down to a message level afaict (at least with the topic exchange, but I might be wrong, as usual :-)
[22:44:05]  <hari>	 if we want filters based on message content, we probably need to implement them in agoclient
[22:44:44]  <hari>	 the other approach I was thinking about is to do all access control just in json-rpc
[22:45:07]  <hari>	 it is not like that "strangers" could talk to qpid directly anyway..
[22:45:43]  <hari>	 with proper permissions on the config/messagesend and a non-default qpid pw, direct qpid access would be prevented
[22:45:44]  <jstrom>	 The issue is that agorpc would have to know about all details for every device..
[22:46:09]  <hari>	 on the pro side, it would be a single level where we apply access control
[22:46:18]  <jstrom>	 and if you want to be paranoid, there could be bugs in other pieces which have access to the bus
[22:46:25]  <jstrom>	 yea
[22:46:31]  <hari>	 spliting rules to agorpc, qpid itself, agoclient and so on, wouldn faciliate either
[22:47:27]  <jstrom>	 another issue, what would i.e. agoevent or agoscenario be allowed to send
[22:47:29]  <jstrom>	 ?
[22:47:34]  <jstrom>	 anything, or limited on the user configuring it?
[22:47:38]  <hari>	 good q
[22:47:53]  <hari>	 and let's not forget that we have physical access to most devices controlled by HA software anyway
[22:48:19]  <hari>	 i mean i can restrict access to the light switch on the ago side, but physical access to the switch is still possible in most cases :-)
[22:48:22]  <jstrom>	 :D
[22:48:23]  <jstrom>	 yeah
[22:48:44]  <hari>	 so I think we should offer some protection
[22:48:59]  <hari>	 the q is if we need to become extremely paranoid and granular..
[22:49:33]  <hari>	 good point with scenario and event, we would need per user events/scenarios then
[22:50:02]  <jstrom>	 I'd say there could be a few levels. configuration (adding7removing devices, changing names, moving around rooms), device-commands, readonly, none.
[22:50:18]  <hari>	 yeah, we need some "roles" for sure
[22:50:20]  <jstrom>	 s/I'd say/one idea/
[22:50:56]  <jstrom>	 ok, so what if user a sets up a scenario which is evil, then we revoke the users rights.. is the scenario still usable, lurking there with it's evil code? ;)
[22:51:35]  <jstrom>	 or is the scenario banned, or just that part of the scenario which uses action xy..
[22:51:44]  <hari>	 if we want to get that tight, agoclient needs to be involved, too
[22:51:49]  <jstrom>	 ep
[22:51:50]  <jstrom>	 yep
[22:51:52]  <hari>	 so teh scenario would run commands as user
[22:52:00]  <hari>	 and agoclient would check vailidty on each received command
[22:52:23]  <jstrom>	 yeah
[22:52:34]  <hari>	 if we make agoclient a lot more complex, we should think about using a python wrapper
[22:52:44]  <jstrom>	 around the c lib?
[22:52:49]  <hari>	 so that we don't have to duplicate everything from c++ client into the python client
[22:52:49]  <hari>	 yeah
[22:53:38]  <hari>	 per device and/or parameter ACLs should belong there
[22:54:08]  <hari>	 i wonder if we have the username in some qpid message field
[22:54:34]  <jstrom>	 well, are you going to trust a plain username in the qpidd message? or do you need cryptographically signed messages..
[22:54:37]  <hari>	 agorpc would need to open multiple sessions per user
[22:54:48]  <hari>	 qpid uses sasl authentication
[22:54:54]  <hari>	 and we can also use ssl encryption
[22:55:11]  <jstrom>	 ah, direct end-to-end auth from end-user to the qpid broker?
[22:55:31]  <hari>	 that would be one possible approach, albeit needing some changes in agorpc
[22:55:52]  <hari>	 we could make multiple queues on the broker, e.g. a specific one for security system related commands, and so on
[22:56:44]  <hari>	 unfortunately acls are not dynamic in qpid, but there is a QMF command api which allows to tell qpid to reload the acl file
[22:57:25]  <jstrom>	 can we write ACLs from QMF? would want some UI for that, I guess
[22:57:56]  <jstrom>	 nah, I got to go to bed now.. this discussion will go on forever, got to break now ..: )
[22:58:00]  <hari>	 but we still woudl need more granular control than qpid acls
[22:58:14]  <hari>	 e.g. agocontroller in agoresolver supports a lot of config commands, but also essential stuff
[22:58:30]  <hari>	 so this needs to be filtered based on command..
Personal tools