Are there processes and methods documented on how to run custom Ubuntu computers (from install to every day usage) for banks and other businesses that do not want users to download binaries from possibly insecure locations?

So that apt-get, update etc happen from only a few trusted internet or intranet locations?

Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software... so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.

Aim is to be secure, use Ubuntu or a flavour, allow deveopers and other sudo users to be as productive as possible. (And reduce dependence on Windows and Mac computers)

.2. And the IT folks can dicate policy to users so they can't do some actions like share a folder, even if sudo user? A complete solution?

  • 7
    If you give them root access for sudo apt-get, then you better put a good firewall outside the system.
    – muru
    Jan 16, 2017 at 7:33
  • 2
    To play devils advocate a little here, how do you ensure that the software in Ubuntu's repositories is "trusted"? If your organization doesn't review any of those packages or repositories, it could be argued that you're already installing untrusted software :) Also unless you block Internet access or white-list specific sites, it's pretty trivial for a technical user to bypass this kind of restriction, just download the deb(s) manually and install... Jan 16, 2017 at 18:19
  • 2
    Once they have root, they can install untrusted binaries obtained via an USB stick. Or download them. Or send them by e-mail to themselves. Keeping a developer with root access from installing all the software they want is basically impossible. Jan 16, 2017 at 19:37
  • 3
    I'm voting to close this question as off-topic because this is a request for consultancy, not a simple Q-A for which this site is designed. Therefore the question is too broad to be handled here and off-topic!
    – Fabby
    Jan 16, 2017 at 20:48
  • 1
    A carefully crafted sudoers file should do, deployed by any mass management system ensuring only Company allowed things are done. This makes the questions option based or too broad (both match). flagged for closure for opinion based. (insurance broker sysadmin here, I've chosen a path in many, hence the opinion based flag)
    – Tensibai
    Jan 16, 2017 at 21:11

3 Answers 3


Setup your own debian repository proxy within your intranet.

Customize the ubuntu installation so that your debian repository proxy is the only entry in /etc/apt/sources.list.

Et voila: you have full control about the software installed on your clients (as long as no user has super user permissions).

Update : Added this after the first answer. These users are support, novice users of systems and developers of the bank software... so some of them need sudo privileges. Is there a ready way to monitor them so that any exceptions are caught quickly (like adding the sources list) but other actions like installing stuff from known repos goes unreported.

In your custom installation you can modify the /etc/sudoers file so that your users are allowed to run sudo apt update and sudo apt install but no other command starting with apt. Of course, you also have to restrict sudo bash (or any other shell).

  • 3
    As long as no user has super user privileges, they can't install any software anyway.
    – Byte Commander
    Jan 16, 2017 at 9:04
  • I edited the question.
    – tgkprog
    Jan 16, 2017 at 9:34
  • @ByteCommander that's true, but what if you want to add one more "trusted site" in addition to the initial list? Would you prefer to run a script to update /etc/apt/sources.list on all 10'000 clients or just modify this file on a few apt caches? Jan 16, 2017 at 9:40
  • 5
    @TimothyTruckle if you really have 10000 clients, then you also have a management system like Puppet around, and adding it to all of them is trivial
    – muru
    Jan 16, 2017 at 9:44
  • users can get access to a shell if sudo apt update reports a file conflict
    – Ferrybig
    Jan 16, 2017 at 21:18

In almost every shop I've seen so far, developers had full access to development machines, but these machines only had access to the Internet and to the source code repository.

Source code is checked in and compiled on trusted machines (which the developers usually don't have or need administrative permissions on), and then from there deployed to test systems that have access to the internal network.

Whether these machines are used by the developers or a separate test team is up to your organization -- but generally the boundary between trusted and untrusted machines is between separate machines, with the interface between them verifiable (such as source code commits).

Front desk employees get no administrative privileges, ever. When we deployed Solitaire to all of these machines, complaints about this policy pretty much ceased.

  • Good tip. A few pass times (game apps), and maybe a company wide social space (wiki, chat, forum, votes) that is open for 1-2 hour a day.
    – tgkprog
    Jan 27, 2017 at 7:21

This is a very good question, but it's answer is very difficult.

First, in order to start off @Timothy Truckle has a good starting point. You would run your own apt repo where your security team could verify every package. But that's just the start.

Next you would want to implement groups. You would aim to have users be able to do the things they need to without much help from support. But in banking you really want things locked down. In fact in many corporate structures you want to lock things down. So granting normal users sudo privileges at any level is probably out.

What you would probably do is set things so that certain groups didn't need elevated permissions to do their jobs.

Again, in most corporate environments installing software is something that can get you fired, so that's a no no. If you need software you call IT and they do it for you, or there's a requisition chain or some such.

Ideally you would never need a normal employee to install anything or ever need elevated permissions.

Now for Developers the question is a bit different. Maybe they need to install and maybe they need sudo. But their boxes are on the "danger network" and can NEVER connect directly to critical systems.

IT/Support staff will need sudo. But you can limit sudo access by command, or process (paperwork) or other means. There can be whole volumes about things like the "2 eyes principal" and how to implement it. But audit logs exist and can be configured to meet most needs.

So, back to your question. Timothy Truckle's answer is 100% correct, but the premise for your question is off. Securing a Linux OS is a lot more about choosing the settings that is needed for your specific use case, and less about a general idea how to secure things.

  • well stated answer Jan 17, 2017 at 0:19
  • I worked for an american IT supplier where they disabled Windows 7 UAC out of the box in the installation images (they also had Linux images) and all my coworkers were admins on their machines and had root privileges to many machines from different customers storing also financial information. It's not that there weren't any security measurements in place, but how should I put it… by any means you are correct and I'd prefer it your way if I was in charge, but do you have actual experience or is it just wishful thinking?
    – LiveWireBT
    Jan 17, 2017 at 0:31
  • Many many years of actual experience. The OP asked about banking and in banking as well as many corporate structures there are regulations, both contractual and legal that need to be met. Usually you start (or finish) by meeting those obligations.
    – coteyr
    Jan 17, 2017 at 1:20
  • Thank you. Yes we are not a bank, but need and follow security like one, cause if sensitive data. i used the word bank as its a familiar use case.
    – tgkprog
    Jan 17, 2017 at 8:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.