Re: [Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-25 Thread Seth Arnold
On Tue, Feb 25, 2020 at 04:21:05PM -, Balint Reczey wrote: > This is a temporary key and it is indeed available to everyone being > able to run curl on the system: > https://www.reddit.com/r/aws/comments/85vkq6/question_about_accesskeyid_secretaccesskey_in/ > > The package does not change the

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-20 Thread Seth Arnold
This new version of ec2-instance-connect is significantly better, thanks for all the work. I was wrong about the dedicated user: using the ec2-instance-connect user is definitely an improvement. My one specific concern: - AWS_SECRET_ACCESS_KEY (and the ability to get one) appears to be available

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-19 Thread Seth Arnold
The hex encoded version of the key is also passed to openssl: $ echo abcdef0123456789 | /usr/bin/od -A n -t x1 | /bin/sed ':a;N;$!ba;s/[\n ]//g' 616263646566303132333435363738390a $ aa-decode 616263646566303132333435363738390a Decoded: abcdef0123456789 # Sign a message with a given key # sign [

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-18 Thread Seth Arnold
That's got to be my one super-power -- asking a question and finding out that no, I didn't find a bug, but by asking the question someone *else* spots a bug. How about this? # Derive a sigv4 signing key for the given secret # get_sigv4_key [key] [datestamp] [region name] [service name] getsigv4ke

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-14 Thread Seth Arnold
Is the postrm script missing a systemctl daemon-reload? ==> postrm <== #!/bin/sh set -e #DEBHELPER# case "$1" in purge|remove|abort-install|disappear) deb-systemd-helper purge ec2-instance-connect # Delete system user deluser --system --quiet ec2-instance-connect

Re: [Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2020-02-10 Thread Seth Arnold
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 -, Christian Ehrhardt  wrote: > > > - the service should not run as root, use PrivateTmp and maybe a few > > > other systemd service isolat

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2019-11-07 Thread Seth Arnold
I've been reminded that set -o pipefail is not perfect. I'm going to quote from the excellent bash faq: http://mywiki.wooledge.org/BashFAQ/105 > though with pipefail in effect, code like this will sometimes cause an > error, depending on whether the output of somecmd exceeds the size of the > pipe

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2019-11-07 Thread Seth Arnold
If this is going to be addressed via code changes rather than a rewrite, I'd like to suggest the following order: - remove all evals - add set -o pipefail to help catch errors in pipelines - add set -u to help catch unset variables - replace /tmp/sigline with mktemp -d Thanks -- You received th

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2019-08-14 Thread Seth Arnold
** Attachment added: "shellcheck.txt" https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1835114/+attachment/5282470/+files/shellcheck.txt ** Changed in: ec2-instance-connect (Ubuntu) Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned) -- You received this

[Cloud-init-dev] [Bug 1835114] Re: [MIR] ec2-instance-connect

2019-08-14 Thread Seth Arnold
At a high level I'm concerned about several parts of this tool's design: - First, it puts an incredibly high level of trust in the metadata service. This may make sense in the context of executing on the Amazon platform, but is positively dangerous outside the Amazon platform. It's extremely