What are the security concerns of the following scenario? (this is one of those crazy ideas that someone will try, and maybe a it's a good idea, and maybe it's a terrible idea...)
You have Rails app at example.com, and an action at https://example.com/admin/update_app
This action has the following requirements:
It requires https (and redirects if not on https)
It requires admin access
The action displays a page with a form that says "Repository password: [ ]"
This field is filtered out of the server logs, the same way that authentication to the site is filtered out, via the log filtering mechanism in Rails (i.e. this method)
This action does the following
You put your code repository password in the field and hit "Submit"
The action starts a shell script which pulls the latest updates from the stable branch of your code repository, and applies them to the site (unless repository authentication fails, in which case it stops all further steps)
The web server is restarted
An email is sent to the admin saying something simple like, "App update complete"
Don't send the password. The app could be compromised and trojaned or the filtering could fail. Instead, grant the web app read-only access to the repository via a separate account or public access.
Don't restart the server if there are no changes. Then the action is secure even without access control: unless the developer has authorized the update by updating the stable branch, nothing happens. If the stable branch is not so stable, create a separate production branch for this.
Stop the webserver before doing the update. The app might not be secure or safe to use as a mix of files from different versions.
Make sure the web server doesn't serve any metadata files left by the VCS.
Well, this all remind me re-invented capistrano deploy on server through git repository.
Only problem that:
1) what if it will be conflicts during merge(point 2)?
2) what if webserver will not restart correctly(point 3)?
3) What if branch in your repository is not so stable(point 2)?
Related
Is it possible to trigger a server update via Capistrano on the actual deployment server, so it fetches updates rather than them being pushed to it?
Our customer's server config is locked down from external access, so can't push an update to it (but it can get to the interwebs, so could see a repository somewhere)
I can't believe I'm inventing something new here, so is it possible to visit and admin page in the app to find an update is available and stop/update/restart the server? What do other people do?
Just to finally close this off, we solved this eventually by moving the project tot gitlab.com and using a gitlab-runner to poll for deployments - thus, pulling updates, not having them pushed.
I'm hosting a project on my Jenkins server. That project has a GitHub repo and I have it set up so it automatically builds new commits. In order for that to work, I need to input credentials for a github account that has full access to the repo.
The problem is, that if I want him to add his login info to the credentials list, I'd have to give him acces to all credentials on the server (I don't want that).
I tried using the credentials under "{username}" > "Credentials", but those didn't show up in the project setup (even with 100% access to everything on the server).
Is there a way for the user to store his credentials and use them for the project without giving him full access to all credentials on the server?
Add the user's credentials under Global security and then allow project based Matrix Authorization Strategy per project as shown:
I found the answer in this mailing list entry:
In short: You need to
install and activate the Authorize Projects Plugin,
enable "run as specific user" strategy in global security settings,
enable this for the project in question.
This allows you to use the credentials for this specific user.
Enabling ssh-agent is the final step to make this work conveniently.
I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:
Start the msi in the per-machine context.
During the client stage of the installation ask for the user name and password.
During the server stage of the installation:
a) create the user
b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
c) change back to the admin context and install and configure the service to be run under the user account
I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?
I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.
The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.
It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.
I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:
<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>
It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.
On my Jenkins build server, I want to set an Authentication Token so that only users that know the token can fire off builds. (As described here.)
This doc page says that it should be configurable under my job's "Build Triggers" configuration.
However, my server has no such fields, and I'm running the latest version (1.546). Mine looks like this:
.
As you can see, this doesn't really look like the docs say it should.
How can I set this token?
You're missing the Trigger builds remotely (e.g., from scripts) Build Trigger:
This is only visible with Security enabled. To get this option from a freshly downloaded 1.546 WAR, I changed Configure Global Security from Anyone can do anything to at least Logged-in users can do anything. For ease/speed of testing, under Security Realm I selected Jenkins’ own user database and Allow users to sign up:
You can go to http://Jenkins-IP/jobs/me/configure to check and change your API access token. Also check whether the user you intend to use has necessary permissions to execute the builds in Manage Jenkins>Configure Global Security
Each jenkins user gets an authentication token - applicable since version 1.426 (more).
You can see yours, provided you are logged in your jenkins server, at http://your.jenkins.server/me/configure
(press 'show API token' button)
Then you can copy and paste it in your scripts (e.g. see here for an example usage).
Here is what I've done so far.
Grabbed the Repository URL from AppHarbor
In bitbucket, I configured the AppHarbor service to use that token.
For the project, I entered the same name of the application I used in AppHarbor (I have no idea what a slug is)
I saved the settings
I granted apphb read permissions in Access Management
I pushed to bitbucket. I even created a dummy changeset to make sure it would get a new push
In AppHarbor, I clicked on "Build URL" and it tells me that my URL was succesfully copied to the clipboard.
I followed the guide to the letter (well, with the exception of the slug, so I'm expceting that is the issue).
Steps to Follow and what gets filled in where:
On BitBucket:
Apphb needs read access to the repository (if it's private)
Go to admin
Add Service: AppHarbor
Token is the UglyValue from the "authorization=UglyValue" part of the build url
Project Name is the last part of the url when looking at that application on AppHarbor. So https://appharbor.com/applications/slug-is-here would use "slug-is-here"
Then you are good to go. You can get more complicated than that (like branches and whatnot) but that's the basic setup.