Generalized Role-Based Access Control for Securing Future Applications Michael J. Covington, Matthew J. Moyer, Mustaque Ahamad, 23rd National Information Systems Security Conference, 2000 (summary by Jeff Ellen) Summary: It seems that everyone is interested in how software and computers will become more a part of our daily lives, to some degree or another, and whether or not it will truly be for the better. And whether the interest is merely passing or obsessive, it is understandable. Anyone that owns an appliance probably bought it in order to make their life easier (no washing by hand, no lugging around large quantities of water, ice, wood, candles, or coal) so it is natural to wonder how they could be improved even further. Even noted humorist Dave Barry has written on the subject, worrying about whether the fridge will be smart enough to communicate with the bathroom scale, and the two will conspire to keep him from enjoying unhealthy snacks. One more serious concern, however, is what type of systems will keep these applications secure. As the authors state, the home is a unique challenge, in that information of a personal and/or sensitive nature is abundant, and generally the homeowner/operators cannot be assumed to have any level of technical knowledge. The authors (at the time) were designing a security system to meet those needs. The system is based on Generalized Role-Based Access Control (GRBAC), which adds object roles and environment roles to the traditional subject roles of RBAC. The intent of this paper is to describe GRBAC, its uses, and why it is necessary. Discussion Points from class: - authors try to make point that GRBAC will allow non-technical 'administrators' to easily secure the house. Isn't that the function of a good GUI more than the underlying structure? - starting to blur the lines between physical and virtual security - long discussion about whether or not people will even use it. authors claim the system must be useable and non-intrusive, then people will use it. Is this assumption true(most homes have locks, but people are too lazy to lock it). Can any design really be simple enough? Counterpoint: people don't lock their doors because they don't think it is very likely that someone will try to open their door. However, most of these same people would probably have a great fear about someone breaking into their computer. - following above, needs to be bug free. after one malfunction or undesired result, the owner will decide it is not worth the hassle, and turn it (authentication, whatever) off. Counterpoint: people put up with windows bluescreens. - besides 'traditonal' security against malicious intrudors, authors talk about using the system to authenticate/allow certain users certain privilages, like letting the TV decide whetehr a child can watch a certain show. But isn't that something the parent should be doing? - big issue of the system being non-intrusive is that many times 100% certaintity of identity is not possible. Logging into a computer leaves no doubt, but reliance on weight sensors & face scanners at todays technology level can result in less than 100% confidence in the users identity. GRBAC can handle this quite well - as an aside, GRBAC looks like it has very little to do with RBAC itself. - Role activation & Role hierarchies are mentioned as drawbacks to RBAC, but does GRBAC address them sufficiently? - possible drawback of GRBAC; what about automated tasks, like the window shutting itself at a certain time? Some class memebers felt that the grammar described did not allow for this possibility. - how does system handle multiple admins? (multiple parents) - GRBAC might have an easy to understand representation, which might make it easy to verify, but that doesn't mean it will be easy to use, especially for the non-techncial individuals. - one advantage of GRBAC is the way it handles uncertainties. However, the example in the paper discusses what happens when a child walks away and then reappears. Shouldn't the house be able to keep track of that with 100% confidence? Voting: 5 weak accept 5 weak reject 5 strong reject