Revision history [back]
 | 1 | initial version | posted 2014-02-12 13:26:05 +0200  |
Roundtable discussion: Application Security
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
- POSIX security
- AppArmor and the likes
- complete sandboxing
- containers
- 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"
If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!
| | 2 | No.2 Revision |
Roundtable discussion: Application Security
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
securitysecurity (but... no security) - POSIX
securitysecurity (a good starting point) - AppArmor and the
likeslikes (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 - containerssandboxing (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
If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!
| | 3 | retagged |
Roundtable discussion: Application Security
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