But an important thing must be done: you can run a script, create a start-up script and not mess with any security frameworks (like chaning mac on Harmattan) -- Marcin
2013/12/1 AL13N <al...@rmail.be> > > 2) Sandboxes are limiting, but matter. It is way more difficult to freeze > > to death or misuse iPhone than Android. That probably goes against > > Mer/Sailfish philosophy though. > > IMHO: > > Sandboxing is something that helps for security and QA, and if it's done > structurely, it might even help developing and have apps communicate with > other apps, because it might even enforce an API for each app. > > Sandboxing should not interfere with efficiency though... > > > The way i see it, if each app is closed down from the outside, but it has > a list of "services" for other apps (think DBUS, or whatnot), and it can > use other apps services, and even export a list of permissions for their > services (so that the user can inspect or even not give permission for one > of the permissions), this could help security alot. > > of course, some generic "services" and permissions could be supplied from > core apps or even system itself... > > a list of permissions and API stuff for services of each app, will also > alow other people to see what kind of communication is possible with other > apps, without even looking at their code or even documentation... > > it might even help in this way to create ideas that are original. > > plus, it will help security and find misbehaving apps... > > running as their own user in a separate cgroup is a first step, imho > (policykit could give extra access where needed), but this general > security would help for example with rpm's being emailed to sailfishos > devices... if those apps are installed, at least they will be kept > separate from the system... > > _______________________________________________ > SailfishOS.org Devel mailing list >
_______________________________________________ SailfishOS.org Devel mailing list
