=== laza_ is now known as laza [05:49] hi there, I'm having troubles using 1-wire on Raspberry Pi 2 using latest Ubuntu Snappy Core, I did 'modprobe w1-gpio' which looks ok and adds w1 into /sys/bus, but /sys/bus/w1/devices is empty. Same hw works well under Raspbian. Are there any manuals/hints on getting it running? thanks [06:04] Good luck, zlowred; every time I ask a question here, I get nothing. :P [06:06] didn't want to dive into kernel sources... but afraid choices are only that or switching back to raspbian [06:10] zlowred, you know anything about how secure by default Snappy is? [06:12] not really worried about this as my device is supposed to run on local network [06:18] That's the question I've been asking... I'm the one that cares. XD [07:08] elopio: sure, call it with --copy to copy a file into the testbed, or pass it via --setup-commands [07:08] elopio: you can't do that on the production infrastructure of course [07:08] but locally is fine [07:31] pitti, how secure by default is Snappy, and in what ways isn't it secure by default? [07:32] Tenacious-Techhu: I'm not working on snappy, sorry; but this is a very fuzzy question, you need to get more specific [07:32] (I. e. I can't answer details about snappy) [07:34] It's not a fuzzy question. "Secure by default" is a practice in which the attack surface of a system is completely minimized at the time of initial install and startup, until the "system administrator" changes it in order to enable features. [08:04] good morning [08:05] Hello! [08:05] How secure by default is Snappy? [08:05] Tenacious-Techhu: hm i guess this question is best aked on the mailing list.. But snappy by default is very minimal.. and it requires you to enable access for applications via app armor [08:06] Being secure by default isn't necessarily about minimality; that's more about how insecure things are after they've been turned on. But thanks for the info. [08:07] i.e. installing common linux software is all about making sure it does not touch anything on the file system and figuring out what profile might be suitable for the applicatiohn [08:07] -h [08:07] you dont turn on things globally.. you do that per application.. [08:08] Right; but if I were to install everything, would those things start off turned off or not? [08:08] They should be disabled even though they've been installed. [08:10] take a lot at the security wiki page .. hmm here: [08:10] https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement [08:10] some the yaml settings have been renamed already [08:14] if you install a snap its package yaml is scanned for requires security profiles, those are then used to confine the application.. and yes if the snap contains a service that one will be started. [08:14] *required.. [08:14] note i am not one of the devs, just someone that tries to use it. [08:36] More answers than I was getting anpok. XD [09:07] good morning [09:09] Good morning! [09:09] dholbach, how secure by default is Snappy? [09:10] good morning :D [09:11] Tenacious-Techhu: https://github.com/ubuntu-core/snappy/blob/master/docs/security.md should give you a good idea [09:12] So... it's not. [09:13] ? [09:14] "If unspecified, default confinement allows the snap to run as a network client." [09:14] It's not. [09:20] ... [09:28] dholbach, do you disagree with my assessment? [09:29] kyrofa, hey, could you comment on bug #1542451? is that scope deprecated or is it going to be fixed/updated? [09:29] bug 1542451 in unity-scope-snappy (Ubuntu) "RM: unity-scope-snappy" [Critical,Triaged] https://launchpad.net/bugs/1542451 [09:30] willcooke, ^ just fyi, since our team was assigned to reply on it [09:31] thanks seb128 [09:31] * willcooke subscribes [09:32] yw [09:32] willcooke, you should get emails through desktop team assignement [09:32] hrm [09:32] * willcooke searches [09:33] in spam [09:33] od [09:33] d [09:34] Anyone else have anything to say about whether Snappy is secure by default? [09:53] Good morning all! Happy Monday, and happy Chinese New Year! 😃 [10:04] dholbach, do you disagree with my assessment? === vrruiz_ is now known as rvr [10:37] Hi, I got a short question can i start other snaps from my snap? [10:42] noizer, good luck getting your question asked. [10:43] noizer, hi. No, you can't [10:43] it breaks confinement, essentially [10:43] beuno, is Snappy secure by default? [10:44] Tenacious-Techhu, I think that's been answered already [10:44] No, it hasn't; they just pointed at documents. But if you would be so kind as to elaborate, that would be very helpful. [10:44] beuno hmm will there be something to start an other app later? [10:44] it seems like you are fishing for something, I'd prefer you to ask specific questions [10:45] I am looking for a linux distribution that is secure by default. [10:45] Tenacious-Techhu, maybe you need to expand on what secure to you means? [10:46] "Secure by default" means that all installed software starts with defaults that prevent it from being insecure. [10:46] noizer, it's not currently on our radar, given it breaks out of confinement. Can you expand a bit on what you're trying to acheive? [10:47] It is my impression that, allowing software to be a network client by default goes against that security paradigm. Is that consistent with your perspective on the issue? [10:47] Tenacious-Techhu, I read through your previous comments on apps that can access the network makes them insecure [10:48] So your conclusion would be that it isn't? [10:48] beuno We are making a product where people can make snaps for it. This product needs able to start applications just like the webdm or something [10:48] Tenacious-Techhu, we don't plan on locking down Snappy by default to that extent, Internet of Things without the Internet part is just "things" :) [10:48] Any one experience the same situation with two ubuntu-core packages installed. [10:49] The default username and password are ubuntu. === beowulf_ is now known as beowulf [10:49] snappy list -v Name Date Version Developer ubuntu-core 2016-01-28 7 ubuntu* ubuntu-core 2016-01-28 7 ubuntu [10:49] noizer, ah, I see. So, we will have special permissions you can request in order to use the same APIs webdm uses [10:49] Well yes, but you also don't want your unwatched "thing" to start running software the user didn't explicitly approve.\ [10:49] Malware installed on an IoT device shouldn't be allowed network access by default. [10:50] Tenacious-Techhu, we do capture that a device uses the network, and there are scenarios where you might be able to lock it down further and/or inspect what snaps have requested network access [10:50] That would only allow dealing with the problem after-the-fact. [10:50] beuno where can i find the webdm api? [10:50] A piece of software should have to explicitly specify if it wants network access, and be granted that approval. [10:51] noizer, it's WIP, but, here it is: https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md [10:51] Tenacious-Techhu, we might be able to provide a bit further down the line an option to set stricter policies [10:51] but it is unlikely going to be the default [10:52] can webdm starts an application? [10:52] beuno [10:52] noizer, I think it either can now or it will in the near future [10:53] the command line and webdm are both moving to the internal rest api [10:53] beuno, that does little good when a device is already out in the field, waiting to be preyed upon. [10:53] Better to handle it now. [10:53] Issue: after update of ubuntu-core package with command "sudo snappy update ubuntu-core" we end up with two simular versions of ubuntu-core. [10:54] thanks for the help beuno :D [10:54] Bughunter, sorry, I don't understand the issue [10:54] what's going on? [10:54] Tenacious-Techhu, if you are concerned about that, there is a ufw snap that allows you to firewall the whole device by default and thus have full control over network accesses [10:54] Strange things is, why update with simular version. And why is it impossible to remove the duplicate package? [10:55] Tenacious-Techhu, end users don't understand security and will just approve everything. Additionally, most devices that will ship will require them to have internet access *and* won't have a UI for the user [10:55] ogra, that would only be an improvement if that firewall were installed by default on all versions of Snappy. [10:55] no, it wouldnt [10:55] Additionally, it would still be insufficient for meeting the criteria of "secure by default". [10:55] Tenacious-Techhu, so, if you want to ship a device that is further locked down, you can with Snappy [10:55] it would mean the everyone who uses a device behind a firewall already would have to set it up [10:56] we aren't planning on shipping devices locked down that much [10:56] Yes, and that is my objection. [10:56] Don't. [10:56] Bughunter, sorry, I don't understand the problem. Why update with similar versions? [10:56] Tenacious-Techhu, ok, noted [10:56] but you are free to create your own gadget snap that pulls in ufw in your default install [10:57] Devices should ship as secure by default, period. Otherwise, they're just going to be exploited under the watch of people who don't know any better. [10:57] * ogra_ would say thats up to the device manufacturer [10:57] Now, wy does snappy update ubuntu-core at al with the same version. Seems version checking is bugged? [10:57] Tenacious-Techhu, that's one way to look at it if you're not actually shipping devices to users, yes [10:57] And as such, Snappy should start out that way, so that developers are starting from a state as correct as possible. [10:58] Tenacious-Techhu, we disagree [10:58] i just perfomed this command: snappy update ubuntu-core. [10:58] Yes, I know. [10:58] I encourage you to take the security of IoT devices more seriously. [10:58] Bughunter, is this 15.04 or 16.04/rolling? [10:58] *developers* shoudl start as easy as possible .... *manufacturers* should start as safe as possible with pre-defined services [10:59] Tenacious-Techhu, I think you're misguided. I understand why locking down the network makes it more secure, however, it also makes it useless to users [10:59] as a default [10:59] you can go and buy a dell ip gateway with snappy preinstalled ... you will find that this is differently secured than our developer images [10:59] I would expect snappy to update only when there is a later version of the ubuntu-core package. Instead it downloads and install the same packages. Thats odd. [10:59] It is up to the developers to unlock it, and up to third party software to request that network access be unlocked. [11:00] If network access is allowed to any third party software that doesn't specify a specific request, it's going to be a nightmare. [11:00] Think ill search the snappy-devel@lists.ubuntu.com list for answers. Sheers. [11:00] You'll get a bunch of trojans that call home and such. [11:00] and what do they tell "home" ? [11:01] an app cant really see anything outside of its own box [11:01] Whatever that software was written to. :P [11:01] apart from thinks like CPU architecture and some minor info+ [11:01] *things [11:01] apps cant access the OS [11:01] Well no, but the minute one of those pieces of software uses an exploit on an embedded system to gain more access, they can tell them who knows what. [11:02] You're leaving open an unnecessary security hole that will be a problem later when an exploit for that embedded system is discovered. [11:02] apps cant exploit the system either ... they are checked what they du when uploaded to the store [11:02] And it may go unpatched while the device sits wherever the naive users put it. [11:02] *do [11:02] Who says the thing was installed from the store? [11:03] well, then you are on your own [11:03] From what I could tell, what I read said anything that was installed had network privileges by default. [11:03] you would have to scp and manually snappy install though [11:03] Installed from the store or not. [11:03] via ssh [11:03] for which you have the key [11:03] The point is, it's an unlocked door. [11:03] so that an administrator mistake [11:03] not snappys fault [11:04] The end user will NEVER be an administrator! [11:04] That's the point! [11:04] its an unlocked door if you gave some evil guy your ssh key, yes [11:04] Lock ALL the doors, and make the devs decide which doors to open, and which not to open. [11:04] Tenacious-Techhu, i don't understand [11:04] Tenacious-Techhu, what's the point you're trying to make [11:05] ? [11:05] That way, everyone knows whose responsibility it is when malware gets on the device. [11:05] well, you know who has the ssh key ... so you know who leaked it [11:05] That's not what I'm saying. [11:05] ogra_, if ssh is running the device was in developer mode :-) [11:05] Allowing software network privileges by default is an unlocked door. [11:06] (and to be honest, i wouldnt expect ssh to be enabled on enduser devices .... but again, thats up to the vendor) [11:06] Tenacious-Techhu, to do exactly what ? [11:06] A door that should have never been left unlocked to begin with. [11:06] Every door that's left unlocked is security that could have prevented disaster. [11:06] Tenacious-Techhu, yozur app runs under confinement, it cant see anything outside of its own system space [11:06] Tenacious-Techhu: I believe they are talking about network-client [11:06] all it could do would be to exploit its own data [11:06] You guys need to stop assuming that the rest of the security is going to work. [11:07] Lock ALL the doors. [11:07] which is not unlocked network.. [11:07] Assume each one is the thing that is going to keep the bad guys out. [11:07] Yes. [11:07] The software should have to request network access, and the system should be able to deny it. [11:07] Tenacious-Techhu, request to whom? [11:07] Tenacious-Techhu, and which system? [11:08] To the system that is currently allowing that by default. :P [11:09] Tenacious-Techhu, can you describe exactly how you think things work now, and how you think they should work? [11:09] https://github.com/ubuntu-core/snappy/blob/master/docs/security.md [11:09] If unspecified, default confinement allows the snap to run as a network client. [11:09] Bad. Very bad. [11:10] Default should allow absolutely nothing at all. [11:10] i'm five seconds away from assuming you're trolling [11:11] so, by default, the device isn't useful for anything? [11:11] Not until the developers building software for that device specifically unlock it, yes. [11:11] beuno, either that, or they think we should manually review every app that requests network-client [11:11] right [11:11] Everything should be locked until a developer unlocks it. [11:12] Accountability should be squarely placed on the developer's shoulders. [11:12] Tenacious-Techhu, I think your argument is technically sound, not particulary novel, but sound. It just isn't practical when you actually think about users [11:12] Third party software that makes it onto the device however it may should be able to be soundly rejected, if required. [11:13] When I think about users, I think about some teenage girl whose boyfriend slipped a webcam snooper onto her outdated router. [11:14] Unless a piece of software has been whitelisted, or someone has entered an administrator password to allow that software, it should be denied. [11:14] Just because it's found on the device, that doesn't mean it's legitimate software. [11:14] And so it shouldn't be granted network access. [11:15] snappy devices won't be outdate, they auto-update [11:15] Don't assume where they will be installed. [11:16] if you want to lock down the device further and know how to administrate a device, you can [11:16] If it is on some local network, and not on the internet, it won't update. [11:16] But it can still do damage there. [11:16] This is not about what I want to do. [11:16] This is about what any IoT OS should do by default. [11:17] To keep the users safe, the onus for unlocking access should be on the software developers. [11:17] Tenacious-Techhu, by default, you won't be able to install software that doesn't have a chain of certs behind it [11:18] of assertions [11:18] Maybe not, but once it's on the device, how it got there doesn't matter anymore, does it? [11:18] enabling that software to be on that particular device, and asserting it has been made by who it says it's been made, and etc [11:19] Tenacious-Techhu, the snap won't work unless it has the assertions [11:19] You don't get to justify leaving one door unlocked just because the others are. [11:19] You have to lock all of them, because you don't know which one is going to keep the system safe. [11:20] you don't get to tell me what i have to do [11:20] especially when i try to explain why what you think is a problem isn't, and when i've tried to explain that what you think is a solution isn't [11:21] and have ignored or dismissed those points [11:21] Oh? So if your neighbor left your front door open, you wouldn't want me to tell him to shut it? [11:22] I am not dismissing your points out of hand. [11:22] Tenacious-Techhu: no better analogon would be.. the keys for your house are all opening the door of your house without coming with an extra letter telling you that the keys of your house unlock your doors [11:22] I am dismissing them because they are insufficient. [11:22] Tenacious-Techhu, you're saying the neighbour should have to write "i can open the front door" before they can open the front door [11:23] Tenacious-Techhu, that's all you're saying [11:23] No, you misunderstand, anpok. [11:23] that an app dev needs to explicitly write "i can use the network" before they can use the network [11:23] and that that will somehow stop malware [11:23] It is not what the app dev writes... [11:24] It is what the system decides when receiving that request that matters. [11:24] Rather than granting that access by default, it has the chance to reject it. [11:24] Tenacious-Techhu, so three options: either always grant that request, always reject it, or always have somebody manually audit it [11:25] And right now, you are auditing those requests, except by default. [11:25] Tenacious-Techhu, which of those do you think is sane? [11:25] I'm just saying audit that one too. [11:25] Tenacious-Techhu, we are not auditing all requests, only those that we consider have real security implications [11:26] Yes, but internet access DOES have real security implications. [11:26] Tenacious-Techhu, explain [11:27] Tenacious-Techhu, give me an example, even if it's contrived, in which *just* being a network client has security implications for a sandboxed app [11:28] Someone could find an exploit on the poorly maintained, widely deployed IoT device, write a piece of trojan malware for it, get a bunch of naive idiots to install it, and then when the server it dials home to says "go", it explodes. [11:28] Whereas, if it had to request internet access to begin with, it could be rejected, and thus, never could be installed in the first place. [11:30] Tenacious-Techhu, how could it be rejected? [11:31] The request for internet access would be denied by the existing mechanisms that deny other things in non-default circumstances. [11:42] My recommendation is to assign network access, even as a client, to a specific request, and not a default one. That way, it can be denied, just as any other specific request can be. [11:42] Tenacious-Techhu, as I said an hour ago, noted [11:43] Well, fair enough then. [11:43] Go to a Homeland Security conference some time. [11:49] ogra_: argh, no loadkeys in 15.04 Core image! Do you know off hand how to switch to my sweet french kbd layout? :) [11:51] didrocks, i dont, actually :) [11:52] even if loadkeys was there we wouldnt have the keymaps [11:52] ogra_: do you know who would have any idea on this? :p [11:52] * ogra_ tends to always use ssh so i dont run into this ;) [11:56] ogra_, where does uboot go in the 16.04 images? [11:56] didrocks, i guess they shoudl be part of some UI snap in the end ... [11:56] ogra_: yeah [11:56] beuno, on disk ? in what snap ? you have to be more precise ;) [11:56] ogra_, heh, yeah, in what snap [11:56] gadget [11:57] (talking about all-snaps here ... system-image builds still use the 15.04 setup) [11:57] ogra_, and that's the plan going forward, right? [11:57] yeah, all-snaps [11:57] right [11:57] thanks ogra_ [12:04] ogra_ Hello, I'm trying to use UWSGI in a snap but i got following error: error removing unix socket, unlink(): Read-only file system [core/socket.c line 198] [12:05] but this is some permission issue. If you have any idea how I can solve that [12:05] noizer, what's in the audit logs? [12:06] where can i find the audit logs Chipaca? [12:06] noizer, sudo journalctl | grep audit [12:06] yeah, looks like the socket is created in some dir outside of your box [12:06] noizer, there's probably a better way, but that one works :-) [12:06] * ogra_ prefers syslog :) [12:07] oooh ok ogra_ first i will try to change the path of my sock maybe that will hep [12:08] Chipaca then i will share my log [12:08] noizer, use $TMPDIR ;) [12:08] in the ini of the socket? [12:08] (ini of uwsgi) [12:09] if that respects the environment vars, yes [12:09] otherwise /tmp/something should work [12:09] yeah [12:09] /tmp/foo.sock [12:09] noizer, it's a private tmp, fwiw [12:10] what a luck Tenacious-Techhu is gone now [12:10] * ogra_ bets that would be the next discussion ;) [12:10] hahah xD [12:31] Chipaca and ogra_ thx this error is fix. I think so xD. now the next error [13:17] jdstrand: hey [13:17] jdstrand: around? [13:17] Chipaca ogra_ do you now something about this error? lock engine: pthread robust mutexes [13:19] oooh sorry thats the issue Bad system call [13:19] might be seccoomp related [13:19] secoomp?? [13:19] right, check with ubuntu debug [13:20] *seccomp [13:20] err [13:20] snappy-debug, sorry [13:20] robust mutex are used internally to implement parts of the stdlib [13:20] they should be allowed by seccomp [13:20] (perhaps they are not) [13:20] right [13:20] thats why i asked to check it :) [13:20] hey ogra_ :) [13:20] yo [13:21] busy week ahead [13:21] two of them :) [13:21] that's quite true [13:21] ogra_ what do you mean with ubuntu debug [13:21] snappy-debug was what i meant [13:22] it ships a tool to check the logs for seccomp denials [13:22] ok and how can i test that because im nog familiar with it [13:22] (i forgot the new name, it used to be called sc-logresolve in 15.04) [13:22] ogra_ I'm using 16 (xenial) [13:22] install the snappy-debug snap and run sc-logresolve ... IIRC it tells you the new name [13:23] then run whateve it tells you [13:23] ok i will check it out [13:24] snappy-debug failed to install: can not open /tmp/snappy-debug230025468: cannot open snap: unknown header: "!\ndebian-binar" [13:24] tried to install it dammed [13:24] is that a bug? [13:25] jdstrand, ^^^ hasnt that been updated to the 16.04 format yet ? [13:25] noizer, try snappy install snappy-debug/edge [13:25] if that gets you the same error it hasnt been updated yet (and thats a bug, yes) [13:26] hmmm same error [13:26] yeah, thats a bug then [13:26] ogra_ should I file it or?? [13:27] yeah, i'm unsure against what exactly though ... file it against the snappy project itself for now [13:28] this project ? https://bugs.launchpad.net/ubuntu/+source/snappy [13:28] nop, see the channel topic [13:29] ("/ubuntu/+source/snappy" would be the snappy package in ubuntu ... not the project) [13:30] ok sorry xD my mistake [13:30] now I will file it now. But how can we debug it then? [13:31] i guess you have to ask tyhicks or jdstrand ... i dont know how you can get seccomp messages without the tool [13:31] (or even if you can) [13:32] ogra_ ok i will ask them [13:34] tyhicks and jdstrand Hi i wanted to use UWSGI in xenial but i had some errors. ogra_ said to me its something with the seccomp can we debug it without snappy-debug? (I'm using xenial for my development) [13:36] Good morning [13:36] ogra_ they online? or can kyrofa help me? [13:36] Good morning [13:37] noizer, perhaps not yet (US timezone ?) [13:37] sergiusens, what are you doing here ? isnt is a holiday in arg. ? [13:37] ok [13:39] Hey seb128 the scope is out-of-date (using the webdm API instead of the snappy API) and not being used since Personal isn't being used. And as you see on the bug, it sounds like the golang updates have broken it. I think it will probably be updated eventually, but it doesn't make sense to put in the effort right now for something no one is using :) [13:39] ogra_, auto connect; good bye ;-) [13:39] enjoy ! [13:39] :) [13:40] ogra_, it's almost 11 and I just got up; I started the day perfectly :-) [13:40] * sergiusens waves [13:40] :D [13:40] kyrofa, I expect some people are going to want pocketpc or unity8 desktops to be able to install snaps, even if there is no personal image [13:40] ogra_, I believe seccomp denials go into syslog as well [13:41] willcooke, ^ do you know? [13:41] kyrofa, oh, right [13:41] seb128, good question [13:41] ogra_, snappy-debug just parses syslog [13:42] yeah [13:43] ogra_ are there some other things that i can test? [13:43] seb128, kyrofa - yes, I would expect that people would want to install snaps in a U8 session on a desktop. But, it's probably not a priority. Let me see what I can find out. [13:43] noizer, as kyrofa said, check syslog for seccomp lines [13:44] ow sorry [13:45] how can i do that ogra_ sorry not familiar with some logging of linux [13:45] its a text file :) [13:45] /var7log/syslog [13:45] bah [13:45] ooh dammed [13:45] /var/log/syslog [13:45] :D [13:45] ty [13:46] run tail -f /var/log/syslog ... in one terminal ... in another terminal start your app/service/whatever ... and see what it logs ... watch for seccomp lines then [13:46] (or just search for former seccomp lines without monitoring live ... as you like) [13:50] ogra_ that is what i got when im started my application [13:50] http://pastebin.ubuntu.com/14993207/ [13:50] willcooke, yeah, please let me know. I can talk to alecu again, see if we should give it a higher priority if that's true [13:50] noizer, syscall=282 is blocked then [13:51] noizer, now run: scmp_sys_resolver 282 [13:51] that tells you which function it is [13:53] its the bind method [13:55] now the bind method is that from the ubuntu snappy? or from my uwsgi? [13:56] noizer, binding to a port, probably. You're using Snappy 16.04 right? What capabilities are you providing to your service/binary? [13:59] kyrofa yea i'm using Snappy 16.04. what do you mean by the capabilities of my binary? [13:59] noizer, pastebin your YAML real quick [13:59] ok [14:00] but now its not a service I start it from command line (bash file) [14:00] noizer, alright [14:00] He isnt at the moment a network service if you mean that [14:00] I will add something to it [14:01] kyrofa does you need then my Yaml file? [14:03] kyrofa how can i sea if uwsgi is running then? In normal ubuntu then you can see it with ps -A but in snappy i don't know that [14:03] noizer, yeah let me take a look. But yeah, you need to give it permission to bind to a port [14:03] noizer, yeah you can still use ps [14:03] Ok awesome [14:04] My snap is now building with the network-service. but now an other question seccomp what does it do with snappy? [14:05] noizer, ahh, so much [14:05] noizer, snappy has an excellent confinement story, utilizing a number of technologies to get there [14:06] kyrofa can i find some information of the complete build of snappy [14:06] noizer, it uses apparmor to make sure the .snap can only play in its own space on the filesystem, seccomp filters to make sure it can only call a whitelist of syscalls, as well as cgroups [14:07] noizer, so that one little network-service capability you added results in a different profile being used for apparmor and seccomp [14:10] noizer, what do you mean by "complete build?" [14:10] oooh ok dem so a nice system Snappy [14:10] How snappy is builded [14:10] So i know more about the underlaying things [14:11] noizer, ah, that's outside of my purview. But here's an overview of the security side of things: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement [14:14] kyrofa ok I will read this. Looks very intresting :D [14:21] kyrofa I tried now with ps -A but dont see anything running [14:22] noizer, probably died then. If it gets a seccomp denial it's always fatal [14:22] will it be in the syslog? [14:22] * kyrofa has a flashback to having to modify the mysql code so it wouldn't die [14:23] Does i need do some command to start the services? [14:23] noizer, not sure what you mean [14:25] no uwsgi can run now :D awesome [14:25] noizer, so it works? [14:26] normally yes thanks for you help :D awesome support here :D === nyx_ is now known as kjar [14:28] noizer, very good! [14:28] yay [14:28]