On fre, 2014-09-05 at 13:20 -0500, Federico Mena Quintero wrote: > On Thu, 2014-09-04 at 19:05 +0200, Alexander Larsson wrote: > > > 4. IPC stability guarantees > > During GUADEC, Dodji Seketeli told me about a tool he's working on to > determine whether a C/C++ API/ABI has changed. This is not IPC > stability, of course, but it may definitely come in handy to ensure the > general sanity of the ABI. > > http://gcc.gnu.org/wiki/ABIInstrumentation
Yeah, this could be used to inspect ABI compat over time for the same runtime (i.e. minor releases). It is also interesting wrt builds of the runtime from different sources (say a distro rebuild of the gnome-os runtime). > It should be easy to do a comparison of DBus interfaces, right? I guess > you could introspect them, serialize the results, and compare them. I > don't know how this would work without having to introspect both pieces > of code you are testing. Well, once you have the serialized results it should be possible to at least assure some level of compat (i.e. no methods removed or changed), although details wrt implementations would be harder to catch. However, it is not so easy to do the introspection, as that requires the app to be running and the list of object names, paths, and exposed interfaces must be known a priori. If we had a list of all the exposed things and they were all activatable then it would be easy to at least introspect the toplevel interfaces (i.e. the ones global to an app, but not necesarrily ones on objects that you have to call into the API to create first.) > > 5. Sandboxing APIs > > > > In a sandboxed environment app code doesn't have access to most of > > the host system. However, apps still need some ways to securely > > access various services (like users files, hw, host services, etc). > > We need to define these APIs, and whatever security layer protects > > against their misuse. > > Does anyone have ideas for how to sandbox a traditional app so as to > restrict its access to files, DBus onto other processes, etc. - even if > the app doesn't work at first? I'd like to see where things start > failing and then seeing how to open up those bits via DBus interfaces, > rather than taking an everything-open application and closing it down. I sympathize with this wish. Its much better to start from a completely locked down environment and then open up only what is required, as this is much more secure than going from open to closed by slowly removing things. Its so easy to forget something. I've hacked up some simple tool to let me run something with a /usr from a runtime. It would be simple to modify it so that it sees nothing of the host (be it filesystem or dbus daemon). However, for it to work at all it needs an X connection (which is inherently unsafe) and to slowly start adding dbus interfaces we need to expose it to the bus, and once it is there its not atm easy to do dbus limits on a more fine grained level. Maybe we could use the uid or selinux dbus limits to play with this? _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
