the case of a sandboxed server application

the case of a sandboxed server application

[Nils Gillmann]

How do we handle applications which absolutely need to write in
their data folders?

Is there some case like psyced which I could refer to for
packaging and service creation later when I package psyced, or is
this a first one for psyced?

Psyced comes with its own sandbox, and it needs this access.
The following chatlog is posted with permission, and any input on
how to do this (currently low priority) packageset would be
welcome, or some packages I could look at to compare.

If it's not possible with guix currently, I think we need to fix
it as psyced will not be the only software behaving like this as
a security feature.

2016-04-01 10:33:27	lynX	[10:02] ng0 sagt: lynX: urgh. can you include some statement like that git checkout is now the prefered method and future tarball releases are unlikely or whatever on the psyced.org
2016-04-01 10:33:27	lynX	[10:02] ng0 sagt: website? seems like guix wants this.
2016-04-01 10:33:27	lynX	[10:03] psyced already uses git for updates (see psyced -u)
2016-04-01 10:33:27	lynX	[10:03] its only the first install.sh thati'm not sure is ready to go to trash
2016-04-01 10:33:27	lynX	[10:03] and install.sh only works from tarball
2016-04-01 10:33:27	lynX	[10:04] my last test install i did from psyconf only
2016-04-01 10:33:27	lynX	[10:04] thus the recent edits of psyconf
2016-04-01 10:33:27	lynX	[10:05] a packaged psyced should not run install.sh methinks.. that's for starting from zero knowledge
2016-04-01 10:33:27	lynX	[10:06] and it stems from the days when servers were using sun or irix

2016-04-01 10:39:28	ng0	I would also have to come up with a solution for a psyced system configuration and service in guixsd because it just can't use psyced -u the way it normaly does
2016-04-01 10:40:11	lynX	that's easy, just run psyconf after git pull
2016-04-01 10:41:17	ng0	how if you(the service user) will have no write access to the directories (at least from what I know in theory from guix, I might be wrong about this)
2016-04-01 10:41:51	ng0	psyconf will have to be part of sys config
2016-04-01 10:43:35	lynX	i presume git pull also runs as admin, no?
2016-04-01 10:43:50	lynX	both are safe to run as root
2016-04-01 10:49:04	ng0	it's not about being safe to run, the store just can't be altered. put the config in a writeable location, good, but /gnu/store/ just won't work. if it is part of the
2016-04-01 10:49:04	ng0	systemconfig and it can be changed through it, it will work. otherwise it has to live in for example /etc/psyced/config instead of
2016-04-01 10:49:04	ng0	/gnu/store/hashp-syced-version/opt/psyced/config
2016-04-01 10:50:12	ng0	i have no idea how webservers are configured here at the moment, but I assume it's a combination of both
2016-04-01 10:50:43	lynX	the config goes into /etc/psyc usually
2016-04-01 10:50:57	lynX	and that is for the admin to edit manually... which eans you can generate it
2016-04-01 10:51:14	lynX	the stuff in /opt needs to be writeable because psyced is a sandbox
2016-04-01 10:51:23	lynX	you can put it in /var if that sounds better to you
2016-04-01 10:51:40	lynX	but psyced cannot be read-only .. and its not a bug, its a feature
2016-04-01 10:51:45	ng0	oh. so then just the psyced -u will be broken and if there's a systemservice it can go into either manual file option (/etc/psyc/) or systemservice (/gnu/store/ location
2016-04-01 10:51:47	lynX	psyced runs in a sandbox
2016-04-01 10:52:09	lynX	if you install psyced into /var, then psyced -u isnt broken
2016-04-01 10:52:52	ng0	hm.. i have to learn more about both psyced and guix to know if this is okay, but i assume just putting things outside of the store will not work
2016-04-01 10:53:12	lynX	where do tools put their logs?
2016-04-01 10:53:16	lynX	and data?
2016-04-01 10:53:19	ng0	/var/log/
2016-04-01 10:53:26	ng0	datafiles into store
2016-04-01 10:53:37	lynX	consider psyced source as data
2016-04-01 10:54:20	lynX	you could also do something with symlinks to only make data, place and log writable
2016-04-01 10:54:25	ng0	i could install some software which behaves the same way and see how it was decided upon to do
2016-04-01 10:55:17	lynX	dont know of other sandboxed servers
2016-04-01 10:55:34	lynX	android emulator maybe

2016-04-01 11:15:13	ng0	irc servers don't act similar?
2016-04-01 11:16:19	lynX	irc servers have no state
2016-04-01 11:16:53	lynX	and they have no sandbox

2016-04-01 11:18:46	ng0	to my knowledge, something which behaves like psyced is not packaged at this point.
2016-04-01 11:21:39	lynX	see stuff that does chroot.. although psyced doesnt really chroot

2016-04-01 11:27:04	lynX	or does guix presume all software to be bug free ;)
2016-04-01 11:27:49	lynX	you can completely hack a psyced and still not get access to unix prompt... merit of a sandbox
2016-04-01 11:27:57	lynX	if you hack an ircd, you are root
2016-04-01 11:29:25	lynX	we never had a security incident in.. er.. almost 30 years of lpc server service
2016-04-01 11:32:11	ng0	:) no idea.. core devs might have an idea on this. may I send some of the logs or summary via email to the list if I need further input on how to handle psyced?

2016-04-01 11:33:52	lynX	what list?
2016-04-01 11:34:14	ng0	guix-dev mailinglist, if I need more input from for example ludovic
2016-04-01 11:34:37	lynX	you mean chat logs?
2016-04-01 11:34:58	ng0	snippets of it, describing how psyced works.
2016-04-01 11:35:14	ng0	or just not sending it and just describing what you described
2016-04-01 11:35:16	lynX	yup


-- 
ng
personal contact: http://krosos.sdf.org
EDN: https://wiki.c3d2.de/EDN