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
** 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
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
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
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
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
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
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 [
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
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
10 matches
Mail list logo