Web infrastructure/Policy

Revision as of 19:36, 19 August 2011

The policies on this page are aimed at administrative use of the system.

Shell Access

There are no firm guidelines for access to infrastructure systems. We operate a validated trust approach and require consensus from a number of members of the IT team to grant access.

There are multiple levels of trust:

• No shell access : This is the norm. Very few people have shell accounts to any systems. There must be an extremely compelling reason to provide shell access.
• Shell user : When granted, access will normally be at this level. These users are given access to IT Private bugs if requested.
• VM root : In exceptional cases for highly trusted people with significant sysadmin knowledge we will provide root access to a virtual machine. Having root access means you take direct responsibility for the security of the machine.
• Superadmin : The superadmin team is the core IT team - invitation only :)

SSH Keys

Access is provided via ssh keys and not passwords.

Users are expected to take security of ssh private keys very seriously.

• Private keys are strictly private to an individual. If they are disclosed to anyone, under any circumstances please let IT know AT ONCE. It's easy to change them.
• You should have a dedicated ssh key for use for meego.com access
• ssh keys must be protected by a strong pass phrase (ssh-agent and ssh-add makes this un-noticeable)
• ssh keys use must be confirmed before every use (ssh-add -c). This is usually a simple pop-up from ssh-askpass
• ssh private keys must never be checked into a git repo which could compromise them
• ssh public keys must never be obtained from a git repo which could lead to loose access controls
• Onward access from the jump host is by tunnel - no ssh or agent-forwarding
• The comment on your public key should be descriptive, such as an email address, as much as your pet name is funny, its not to the point.
• If you use a mobile device(phone, tablet, etc) please consider using a separate key for that device and not accessing critical infrastructure with that mobile device directly.

If you have any problems with implementing any of these rules then please talk to one of the IT team - they want you to get it right and will do their best to help you. (And it may help to know that they too will have struggled with ssh once upon a time!)

If you think you need an exception to a rule (eg group access, password access, unattended/cron access etc) then we'll be glad to help solve the problem you face. It's much better to get help to implement a secure solution than to "just" do something to make it work.

The following snippet can be usefully added to your .ssh/config

Host *.meego.com
    User <USER>
    IdentityFile ~/.ssh/id_rsa_meego
    ServerAliveInterval 60
    ForwardAgent no

Host access.meego.com
    ProxyCommand none

Host *.in.meego.com
    ProxyCommand ssh -q access.meego.com netcat %h 22

Notes:

• The strong passphrase means that if your computer is stolen then the attacker won't be able to use your key to access your account.
• The askpass confirmation means that if a man-in-the-middle attack is attempted then your agent should prompt you when you didn't just establish a connection. If this happens then refuse the request.
• Agent forwarding means a compromised jump host would be able to spoof an onward connection as your account

Bugs

(repeated from IT team contact section).

The MeeGo IT team have 2 bug products: MeeGo IT Private and MeeGo IT. We use the private one for bugs which discuss secure or confidential information; sometimes we'll make a public bug private or a private bug public. The criteria are not well defined but in general we don't discuss specifics of our installation in public. Whilst we do not operate "security through obscurity", nor do we claim to be infallible - limiting information means that when we make errors, the information is less likely to leak and the window that we have to rectify the error without discovery should be larger.