Forbidden sqlite3 system call

[Simon Stürz]

On 2015-11-27 15:41, Jamie Strandboge wrote:
> 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.
Thanks a lot! This really helps me to understand what's going on! :)
I'll let you know if I'm making any progress.

Cheers,
Simon

> 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.
>
sounds great!