Drop privs

[mveytsman]

We run as root right now.

We should be running as an appcanary user.

The problem is that we need to make sure that we'll always have read access to Gemfile.lock and whatever other files we need to monitor. No way of knowing what permissions those files have a priori, and making appcanary a user with read permission of everything kind of defeats the purpose...

@phillmv and I were talking about doing a symlink hack before we drop privs, but I wonder if there's an easier way.

@MacLeodMike, @ghedamat your feedback would be appreciated.

[MacLeodMike]

I'm not sure if it's our job to worry about it. The user specifies the file in agent.conf, and in the documentation we should make it clear that the appcanary needs read access to the files. Default umask on most systems is 022, so unless they're going around chmod'ing things to 600 it's probably gonna work out fine without anyone having to think about it.

I recommend just putting in some logic to throw an nice big error when you can't read all the files specified in agent.conf and call it a day. Everyone understands that your docroot has to be readable by your webserver user. No reason they can't figure out that Gemfile.lock needs to be readable by appcanary.

[mveytsman]

I think it's common to chmod your app directories to 600 and chown to some app user. This is because there can be things like db passwords in there.

I know I do it when I provision servers for rails.

We want to minimize friction as much as possible.

One option I'm thinking of is that creating an app user is optional. If you care enough to add our user to your web group, you can add a unprivileged user and make our app run as it...

[MacLeodMike]

I'll believe you that it's common practice, but recursively setting the perms on an app directory to 700 and owned by the app server seems silly to me when the app server is by a wide margin the largest attack surface on the host. Any successful exploit of your service will find the attacker on the system as the app server user, and thus with full access to the db passwords anyway.

It just strikes me as a step that needlessly complicates routine administration and forces you to run primarily as the root user on the host, while not really being relevant to the most likely threats.

Again, if it's common practice then we should plan for it. But I personally just wonder if there's something I'm missing 'cause it seems like the kind of thing where there was an influential blog post about it and now everyone does it without really questioning it anymore.

[ghedamat]

I tend to agree with @MacLeodMike (hi btw :) )

also if you plan to monitor other parts of the system like the installed packages and other services it might become harder. (by default system packages won't be an issue on ubuntu/debian at least)

maybe creating an appcanary user is the way to go, but as @MacLeodMike says it should be the users responsibility to give the right read permissions.

not well thought idea: we get the install script to create the appcanary user but we leave it to the client to change the init script to opt in for running the service not as root? if they do so they also need to add the appcanary user to all the right groups.

also to my knowledge lots of other daemons run as root (see monit), I know we don't need that level of permission but..