cloud-init-dev team mailing list archive

[Seth Arnold <1835114@xxxxxxxxxxxxxxxxxx>]

I'm sorry that I have not yet returned to review the new version; this
is written without having read the new changes.

On Mon, Feb 10, 2020 at 11:33:27AM -0000, Christian Ehrhardt  wrote:
> > > - the service should not run as root, use PrivateTmp and maybe a few
> > > other systemd service isolations
> >
> > I've forwarded this recommendation, too:
> > https://github.com/aws/aws-ec2-instance-connect-config/issues/14
> >
>
> Thanks for forwarding, but IMHO it needs to be resolved before promotion.
> I'm sure security would prefer having that as well - @sarnold - opinions on
> this detail?

I'm less sure: I also have the instinct to run new services in new user
ids but this authentication mechanism will allow (or forbid) logins root
privileges. If it is compromised it can grant root privileges. If it is
broken it can prevent legitimate users from gaining root privileges when
needed. It's very nearly root-equivalent regardless of how it runs.

Using a different user account increases the complexity, which this
service already has in spades.

However, a different user account may limit what resources are silently or
invisibly used by the service, which may limit future complexity growth.

> If "it will only be on EC2" would be a hard fact we can rely upon it would
> not need the majority of pre-checks at all.

I'm concerned about system images being shared amongst private and public
clouds, or different public clouds, or between public clouds and local
development. I know those checks are burdensome but I would rather have
them than not.

If this service runs elsewhere it may represent an instant remote code
execution mechanism.

Thanks

-- 
You received this bug notification because you are a member of cloud-
init Commiters, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1835114

Title:
  [MIR] ec2-instance-connect

Status in ec2-instance-connect package in Ubuntu:
  Incomplete

Bug description:
  [Availability]
  ec2-instance-connect is in the Ubuntu archive, and available for all supported releases. It is available on all architectures despite only being useful on Amazon EC2 instances.

  [Rationale]
  This package is useful on Amazon EC2 instances to make use of a new feature:
  Instance Connect; which allows storing SSH keys for access online in the Amazon systems. These SSH keys are then retrieved to be used by the system's SSH service, collated with pre-existing keys as deployed on the system.

  Installing the package enables the use of Instance Connect on an
  instance.

  [Security]
  This is a new package, and as such has no security history to speak of.

  [Quality Assurance]
  The package consists in a few shell scripts that are difficult to test by
  themselves due to the high reliance on Amazon's Instance Connect service;
  which is online and limited to use on Amazon instances.

  Given that it's a new package, there are no long-term outstanding bugs in
  Ubuntu or Debian. The package is only maintained in Ubuntu at the moment.

  This package deals with special "hardware"; it is only useful on Amazon
  instances, and its support is required as a default deployment on such
  instances when deployed with Ubuntu.

  [UI Standards]
  Not applicable. This service is command-line only and has no configuration options.

  [Dependencies]
  There are no special dependencies to speak of.

  [Standards Compliance]
  This package has been thoroughly reviewed by a few Canonical engineers, there are no standards violations known.

  [Maintenance]
  This package is to be owned by the Ubuntu Foundations team.

  [Background Information]
  This is Amazon-specific, as previously mentioned.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1835114/+subscriptions