Johan Paul <[email protected]> writes: > From an app developer's PoV the security system shouldn't be any more > difficult than what Android, iOS or Windows Phone provide; in the end some > configuration file deployed along side the app where the developer > announces what privileges (s)he needs. It should be up to the user to allow > or disallow this. > > Aeges was horrible from the developer's PoV and it also got in the way of > the user. >
aegis also suffers from bad design and implementation solutions (issues with scripting, overall complexity, security holes, NIH parts), bad reputation of solutions based on it (e.g. unreliable, slow and dangerous dpkg-wrapper) and absence of reliable maintainers. Brief and readable review of linux kernel security support can be found here https://lwn.net/Articles/517384/. Basically for cryptography Mer can use QCA, it allows to use misc. backends. There are multiply MAC solutions, some useful links and reviews: http://en.wikipedia.org/wiki/Linux_Security_Modules http://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison SELinux is ordinary considered as very advanced and relatively complex solution while it is actively maintained and used in e.g. RedHat/Fedora AppArmor is used by Canonical in Ubuntu, maintained by 'em, relatively simple Tomoyo ressembles AppArmor (same path-based rules) Nor AppArmor, nor Tomoyo do not need fs xattrs MeeGo used SMACK for it I do not know is anybody maintaining it. Also, SMACK requires userland programs modification (still ?) Tomoyo has successor: http://caitsith.sourceforge.jp/, rationale http://i-love.sakura.ne.jp/tomoyo/CaitSith-en.pdf here one can find how chackra linux project going to choose MAC solutions: http://chakra-project.org/bbs/viewtopic.php?id=5185 Comparision (y.2009) between selinux, grsecurity, apparmor in a good style (features, pros&cons): http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html apparmor vs selinux comparison: http://elinux.org/images/3/39/SecureOS_nakamura.pdf - denis > > -- > Johan > > > > On Tue, Dec 11, 2012 at 11:32 PM, Hillel Lubman <[email protected]> wrote: > >> The problem with Aegis was inability to actually fully control it even >> when user had super privileges (sudo). This took away control from the user >> to those who were able to sign the binaries. While in theory something like >> Aegis can be good (i.e. granular security for various aspects), in the end, >> user should be able to take control over it or override it when needed >> (given that user escalated access rights with something like sudo and etc.). >> >> Hillel. >> >> >> >> On Tue, Dec 11, 2012 at 4:24 PM, Jussi Sainio <[email protected]> wrote: >> >>> On 11.12.2012, at 15.51, David Greaves wrote: >>> >>> > It is about time we started to discuss security and privacy in the Mer >>> context. >>> > >>> > Mer is aimed at device vendors and there will be different concepts and >>> > implementations of security technologies in the layers above (and >>> below) Mer. >>> > >>> > Given the initial set of builds on Mer includes Nemo, Plasma Active and >>> now >>> > Sailfish I think it makes sense to include issues around "apps" as well >>> as >>> > things like network access or data encryption. >>> > >>> > Rather than re-invent their wheels I'll ask if we have any thoughts or >>> > requirements from our downstreams already? >>> >>> Great! I think this is a very important issue. It pays to look around for >>> existing solutions and gather the best things from various worlds, and then >>> some. Here are some thoughts I discussed about on #jollamobile today, >>> further elaborated: >>> >>> >>> Apps, User point of view: >>> >>> If a random app is downloaded from a random source, it must not be let to >>> fetch contacts or photos directly. The user must be aware of this and asked >>> beforehand. Then, it's the fine art of choosing a usable level what should >>> be asked and how often. I think the level on iOS is about right for most >>> users, "This app wants to use your photos/contacts/calendar/location >>> [Allow] [Don't allow]". (Methinks there could be even an [Advanced...] >>> button.) Also, it was discussed on the IRC channel that the Android >>> solution "Allow all/none at install time" is a very inadequate level. >>> >>> As suggested on the IRC channel, "the trick is not to stand in the way of >>> the user, but to stand in the way of the data octopuses". If the user >>> trusts an app for good, they must be able to give (and remove) permanent >>> permissions for it. Therefore, there must be a 'registry' which takes into >>> account what right have already been given to a specific app. Then you can >>> do basic "always allow" or "ask me every time" kind of stuff. >>> >>> While the Android "Allow all/none" solution is "rubbish", Android >>> documents do provide some insightful aspects (and also technical solutions) >>> that have to be taken into account [1]. >>> >>> >>> Apps, Technical point of view: >>> >>> Regarding the filesystem, I think that one clean solution would put all >>> private data under a specific unix group/ACL privilege. When an app wants >>> to use something from a private data directory (such as calendar, photos, >>> contacts), it must ask for increased ACL privileges to read that >>> directory/file. This solution would still allow nice and clean filesystem >>> access for the user (all privileges in a terminal, for example), but when >>> an app is launched, by default, some of the permissions are dropped before >>> exec()ing the binary, and then they are later granted by the user or by the >>> registry via a library. >>> >>> It was suggested on the channel that Unix credentials are not enough. I >>> agree, that not everything is a file on Unix anymore, so a credential >>> system has to give rights other aspects to the system as well, such as TCP >>> sockets and "make a call over GSM". These have to be thought out, what is >>> the best practice to achieve this without making developer's (and user's) >>> life too annoying. >>> >>> It was also suggested on the channel that Nokia/MeeGo Aegis should be >>> fairly close solution. In my opinion, Aegis design seems to be fairly >>> complex. I'm not an expert on Aegis, so it might have its inner beauty that >>> I don't comprehend. I'm not sure if Aegis is open source, at least I >>> couldn't find the source code quickly. Unlike in the stock Harmattan Aegis >>> configuration, user access to true, full root privileges should not be >>> restricted. But at least the documentation gives some pointers, what was >>> taken into account in MeeGo. [2] >>> >>> >>> Data encryption: >>> >>> I think most data should be encrypted, inaccessible after a boot-up, >>> encrypted using a device pass code (if used). As default, a lock screen >>> should ask this same pass code, but it does not necessarily have to drop >>> the encryption key from memory, to allow programs to use their data while >>> running in background. >>> >>> If multi-user is to be supported, then the user's pass codes should be >>> able to unlock the device. >>> >>> >>> Refs: >>> >>> [1] http://source.android.com/tech/security/ >>> [2] >>> http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Harmattan_security.html >>> >>> Cheers, >>> --jussi >>> >>> >>
