Replacing Postinst Scripts

[robert_joslyn at selinc.com]

> In answering people's question wrt confinement on snappy I recall three
> reasons people give in favor of snappy supporting these types of
> system users:
>
> 1. people are porting a traditional app to Ubuntu Core. I think this is
>    what Robert is getting at-- he is using traditional applications that
>    don't necessarily (yet) understand the snappy world and so certain
>    code modifications need to be made to disable an assumed-to-be-there
>    system user

This is it exactly. I'm porting a few existing applications that fit well 
with the Snappy concept, but I don't want to have to modify all of the 
components of my application to do so. Modifying my internal code can be 
done (hopefully with minimal changes!), but I don't want to start digging 
into Postgres source or other large projects just to get them to work in 
Snappy. I think it would be best to try and minimize the number of changes 
required to get existing applications up and running.

> 2. we've stated that confinement shouldn't get in the way of apps
>    within the same snap being able to share data, communicate with
>    each other, etc. If we consider a really thick snap like a LAMP
>    stack, developers may be concerned about 'in-snap security' such as
>    their webserver getting cracked and an attacker overwriting files
>    in their database, etc.
> 3. Related to '2', some people may want to code for defense in depth
>    and want to drop privileges to augment the security snappy provides.

This is describes my situation well. Even with AppArmor and the other 
isolation features, it will be hard to throw away the existing user/group 
model. It's great that Snappy is adding additional isolation layers, but I 
don't want to give up my existing security structure that allows me to 
maintain that "defense in depth" concept. 

> Opting into per-app system users via yaml could ease porting
> efforts and/or snapcrafting certain applications. These users
> could also be a mechanism for developers to address '2' as well,
> but alternatively we could refine our thoughts on 'in-snap
> security' (eg, expose yaml declarations for who can talk to what).

I think my preference, for what it's worth, is to expose a way to create 
users and allow more detailed control over in-snap security. However, I 
can certainly understand the desire to simplify the yaml and in-snap 
security controls. I think a per-snap system user would cover my present 
use case as well. For example, when I install a snap "foo", a "foo" user 
is optionally created and used to execute the services defined within that 
snap.

Thanks,

--
Robert Joslyn
Software Engineer, R&D - Automation
Schweitzer Engineering Laboratories
509-332-1890 ext. 3214