Re: Security of confined user/application and access to video group

2017-06-07 Thread Germano Massullo
Il 07/06/2017 09:22, Lennart Poettering ha scritto:
> On Tue, 06.06.17 17:44, Germano Massullo (germano.massu...@gmail.com) wrote:
>
>> 2017-06-06 14:40 GMT+02:00 Lennart Poettering :
>>> Note sure what "boinc-client" does, but if this isn't turstworthy then
>>> it probably shouldn't be able to get access to "video".
>> boinc-client is the client side version of BOINC (Berkeley Open
>> Infrastructure for Network Computing). You can use your computers to
>> help scientific research of many different projects. You can think
>> about it as a music player, the projects as the music discs, and the
>> working units as disc tracks.
>> Since working units are closed source software we always considered
>> them not trustworthy, therefore they always runned confined as much as
>> possible
> If so, this sounds like a great candidate for using systemd's
> sandboxing functionality. Things like  CapabilityBoundingSet=,
> PrivateTmp=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=,
> ProtectKernelModules=, ProtectControlGroup=, SystemCallFilter=,
> SystemCallArchitectures=, RestrictAddressFamilies=,
> RestrictNamespaces=, RestrictRealtime=, ...
>
> See systemd.exec(5) for more information.
>
> Lennart
>
Thank you, I will consider systemd sandboxing too
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Security of confined user/application and access to video group

2017-06-07 Thread Lennart Poettering
On Tue, 06.06.17 17:44, Germano Massullo (germano.massu...@gmail.com) wrote:

> 2017-06-06 14:40 GMT+02:00 Lennart Poettering :
> > Note sure what "boinc-client" does, but if this isn't turstworthy then
> > it probably shouldn't be able to get access to "video".
> 
> boinc-client is the client side version of BOINC (Berkeley Open
> Infrastructure for Network Computing). You can use your computers to
> help scientific research of many different projects. You can think
> about it as a music player, the projects as the music discs, and the
> working units as disc tracks.
> Since working units are closed source software we always considered
> them not trustworthy, therefore they always runned confined as much as
> possible

If so, this sounds like a great candidate for using systemd's
sandboxing functionality. Things like  CapabilityBoundingSet=,
PrivateTmp=, ProtectSystem=, ProtectHome=, ProtectKernelTunables=,
ProtectKernelModules=, ProtectControlGroup=, SystemCallFilter=,
SystemCallArchitectures=, RestrictAddressFamilies=,
RestrictNamespaces=, RestrictRealtime=, ...

See systemd.exec(5) for more information.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Security of confined user/application and access to video group

2017-06-06 Thread Germano Massullo
2017-06-06 14:40 GMT+02:00 Lennart Poettering :
> Note sure what "boinc-client" does, but if this isn't turstworthy then
> it probably shouldn't be able to get access to "video".

boinc-client is the client side version of BOINC (Berkeley Open
Infrastructure for Network Computing). You can use your computers to
help scientific research of many different projects. You can think
about it as a music player, the projects as the music discs, and the
working units as disc tracks.
Since working units are closed source software we always considered
them not trustworthy, therefore they always runned confined as much as
possible

>> ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile
>
> If this file is not supposed to survive a daemon restart it really
> should be placed in /run somewhere.
>

I will take care of this.

>> Group=video
>
> I have the suspicion you should better
> use SupplementaryGroups=video than Group=, [...]

I will not use any of them, as soon as possible I will start
investigating on using udev/ACLs on dri/render to solve the GPU
detection problem.

Thank you for clarifing my dubts Lennart
Have a nice day!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Security of confined user/application and access to video group

2017-06-06 Thread Lennart Poettering
On Tue, 06.06.17 11:48, Germano Massullo (germano.massu...@gmail.com) wrote:

> Hi there, I am the co-maintainer of boinc-client [1].
> boinc-client runs as a service, and both it and its working units run as
> 'boinc' user and they are confined by SELinux.
> Recently, I investigated to figure out why boinc-client, while running
> as a service, could not detect videocard for GPU calculus. In order to
> fix this problem I had to add Group=video to boinc-client systemd unit file.
> I have not yet pushed such change to boinc-client Fedora git, because I
> would like to ask you if this can cause a breach into boinc-client
> confinement. I mean, I am wondering if a process that can have access to
> videocard, could for example read what you are doing on your machine,
> the passwords you copy and paste, etc.

The "video" group is pretty broad, it covers video4linux, DRM and related, DVB,
even some firewire stuff. Giving a service access to the local display
hardware means you possibly grant access to reading backing the screen
contents, and giving a service access to the v4l devices means the
service can film the user.

Note sure what "boinc-client" does, but if this isn't turstworthy then
it probably shouldn't be able to get access to "video".

> ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile

If this file is not supposed to survive a daemon restart it really
should be placed in /run somewhere.

> Group=video

I don't know your package, but I have the suspicion you should better
use SupplementaryGroups=video than Group=, as the latter chooses the
group your service creates files as, and the former only grants access
to additional resources.

But then again, you probably shouldn't do all this at all, unless your
service shall be able to film your users.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Re: Security of confined user/application and access to video group

2017-06-06 Thread Germano Massullo
Ah, forget the line
Environment=LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64
since it is needed only for my system
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


Security of confined user/application and access to video group

2017-06-06 Thread Germano Massullo
Hi there, I am the co-maintainer of boinc-client [1].
boinc-client runs as a service, and both it and its working units run as
'boinc' user and they are confined by SELinux.
Recently, I investigated to figure out why boinc-client, while running
as a service, could not detect videocard for GPU calculus. In order to
fix this problem I had to add Group=video to boinc-client systemd unit file.
I have not yet pushed such change to boinc-client Fedora git, because I
would like to ask you if this can cause a breach into boinc-client
confinement. I mean, I am wondering if a process that can have access to
videocard, could for example read what you are doing on your machine,
the passwords you copy and paste, etc.
What do you think about?

Best regards

For convenience I attached boinc-client unit file

=
[Unit]
Description=Berkeley Open Infrastructure Network Computing Client
Documentation=man:boinc(1)
After=network-online.target

[Service]
Type=forking
Nice=10
User=boinc
WorkingDirectory=/var/lib/boinc
ExecStart=/usr/bin/boinc_client --daemon --start_delay 1
ExecStop=/usr/bin/boinccmd --quit
ExecReload=/usr/bin/boinccmd --read_cc_config
ExecStopPost=/bin/rm -f /var/lib/boinc/lockfile
IOSchedulingClass=idle
Environment=LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64
Group=video

[Install]
WantedBy=multi-user.target
=

[1]: https://admin.fedoraproject.org/pkgdb/package/rpms/boinc-client/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org