Forbidden sqlite3 system call

[Jamie Strandboge]

On 11/23/2015 10:08 AM, Simon Stürz wrote:
> $ sudo snappy-debug.security scanlog
> 
> = Seccomp =
> Time: Nov 23 12:35:33
> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1307 comm="guhd"
> exe="/apps/guhio.sideload/IGKUccPPYHOe/usr/bin/guhd" sig=31 arch=40000028
> 207(fchown32) compat=0 ip=0x765fe836 code=0x0
> Syscall: fchown32
> Suggestions:
> * don't copy ownership of files (eg, use 'cp -r --preserve=mode' instead of 'cp
> -a')
> * adjust program to not use 'fchown32'
> 
> The strange thing: this code works on all systems (Debian Wheezy, Jessie and
> Ubuntu 12.04 - 15.10 amd64, i386, armhf) except Ubuntu Core. :(
> 
> So I tried to create the db file using QFile, changed the permissions (in the
> code) before calling the sqlquery command, everything worked until....
> query.exec(...) -> bad system call.
> 
> What could cause this behaviour?
> The suggestion: "adjust program to not use 'fchown32'" would mean: not using
> sqlite3 for me...? That is not an option currently.
> Is there anybody else using sqlite3 + Qt in a snapp?
> Is there a possibility to use security templates or app armor to solve this issue?
> Why it is forbidden to call a fchown32() in the own snapp app data path? I
> understand that the call should be unnecessary, but forbidden?
> 
Currently we do not allow the the chown family of syscalls. This is because at
present snappy does not support the concept of per-app uids and so all services
run as root. Since when creating files in the app's writable path the files will
already have proper ownership (ie, 'root') and there is no reasonable uid/gid to
give to chown, there is no need to chown anything. From later in this thread
code was shown that the fchown is being called unconditionally when the process
is running as root-- this behavior should be fixed in sqlite to only chown the
file when it needs to change.

This would fix a small inefficiency in sqlite while at the same time fixing it
to run on snappy. Note to Ubuntu developers, this sounds like something very
upstreamable and also something that Ubuntu could carry as a delta to ease
snapcrafting until upstream/Debian accepts the patch.

In the meantime, to workaround this issue on rolling images until your code no
longer uses chown, you can provide an override and do something like this in
your yaml:

services:
  - name: guhd
    ...
    syscalls: [ fchown32 ]

On 15.04 systems, I suggest installing the app then simply adding 'fchown32' to
/var/lib/snappy/seccomp/profiles/..._guhd_... (there are other ways to
workaround fchown32 in your snappy packaging on 15.04, but since this is
intended as a temporary workaround, editing the seccomp filter directly is easier).

Hope this helps.

PS - 16.04 should support the concept of seccomp argument filtering, at which
point we can consider chowns to uid 0 as part of the policy generation to ease
porting to snappy.

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-app-devel/attachments/20151127/a41f1ac0/attachment.pgp>