Roundtable discussion: Application Security [answered]
asked 2014-02-12 13:26:05 +0300
This thread is intended as a follow-up to the community roundtable discussion about AppSec at FOSDEM 2014:
It is both the interest of Jolla and the developer community and users to have increased application security. The main point of this discussion is to find a way to deliver a reasonable level of Application Security without compromising usability for everyone.
Security is in multiple levels:
- ... (forgot)
- ... (forgot)
- what Apps have access to
- App <-> OS communication (hardware/services?)
- App <-> App communication
Here are the most prominent ideas that came up:
- no additional security (but... no security)
- POSIX security (a good starting point)
- AppArmor and the likes (but they are file-based only)
- SELinux (more for limiting the root user, not really about app security, plus, everyone just turns it off)
- complete sandboxing (too inefficient?)
- containers (too much overhead?)
- apps having different UIDs and being in different cgroups, communicating via DBUS to other apps and/or system, this being secured by policykit (which is part of systemd these days)
Some other points of interest:
- the (dis-)advantages of on-demand security popups vs pre-init security pop-ups
- the flexibility of "security policies"
- NOTE: most of the app security, is actually something for mer/nemo
Could SELinux approach help here?
sjtoik ( 2014-02-13 09:02:57 +0300 )editah, this was talked about too, i remember now, but no, it might help in some way, but it's only filebased, any kind of inter-app communication and it's more meant to limit the root users
AL13N ( 2014-02-13 10:18:50 +0300 )editAL13N, SELinux is much wider than just file access. Inter-app communication is done through any kind of sockets and shared memory and is equivalently covered by SELinux. DBus access is protected by SELinux as well.
There is nothing in SELinux that is really about root users only. I wonder where your misinformation comes from. Perhaps this visual guide to SELinux policy enforcement might help to clear up misunderstandings? http://opensource.com/business/13/11/selinux-policy-guide
abbra ( 2014-02-16 12:11:27 +0300 )edit@AL13N, just read link by @abbra above and ask someone from osso/maemo/meego oldies in Jolla team to go through contacts and pull from closet SELinux experiments made for N900 and N9, they should fit you perfect if you can't find anyone - ask @abbra or me.
silpol ( 2014-02-16 21:19:03 +0300 )editI wonder whether it has been considered to create a very strict JavaScript API for app development? Say, devs create an app in pure QML and JS, and any OS or hardware functionality is accessed through API methods provided by the system? Keeping apps in their bounds, and even adding fine-grained permission control would be a piece of cake, JS would guarantee loads of potential app developers and getting started against a fixed set of API methods would be easy. Not sure whether this is feasible with regards to the technology stack, but I'd love it pretty much :)
tokaru ( 2014-02-16 22:25:17 +0300 )edit