On: Vulnerability scanner for Linux and FreeBSD

[mordocai]

"Vuls doesn't support SSH password authentication. So you have to use SSH key-based authentication. And also, SUDO with password is not supported for security reasons. So you have to define NOPASSWORD in /etc/sudoers on target servers."

No thank you.

[wyldfire → mordocai]

"What does God want with a starship?"

NOPASSWORD is pretty sane for remote access, my objection would be to any sudo escalation at all on the target.

    > What Vuls Doesn't Do 
    > 
    > Vuls doesn't update the vulnerable packages.

...ok, so please just stick to stuff like unprivileged sha1sum/dpkg/rpm/stat etc.

If vuls absolutely needs some superuser privilege, it makes sense to grant some limited privs via setcap bits (though this would mean it would probably lose the "agentless" feature).

[kotakanbe → mordocai]

SUDO with Password via ssh is technologically possible.

http://askubuntu.com/questions/470383/how-to-avoid-prompt-pa...

But there is a problem with sudo with password via ssh.

For example...

  userA .... 'watch w' on serverA
  userB ... 'ssh serverA echo sudopassword | sudo -S command'

userA can steal of root password on ServerA because plain sudo password is displayed by w command.

So, I disable -ask-sudo-password for security reasons. https://github.com/future-architect/vuls/pull/148

I recommend to define minimum commands in /etc/sudoers on target servers.

  CentOS, RHEL
    vuls ALL=(root) NOPASSWD: /usr/bin/yum, /bin/echo

  Ubuntu, Debian
    vuls ALL=(root) NOPASSWD: /usr/bin/apt-get, /usr/bin/apt-cache

 Vuls can scan without root on FreeBSD and Amazon Linux.

[Perixoog → mordocai]

Alternatively - pam_ssh_agent_auth

[mordocai → Perixoog]

I was complaining more about the sudo part. Probably should have just had that in the quote.

[LukeShu → mordocai]

I think you misunderstood Perixoog's comment. Sudo uses PAM to ask for the password. pam_ssh_agent_auth is a PAM module that uses ssh-agent authentication instead of a password. Perixoog is saying that instead of setting NOPASSWORD, you could configure pam_ssh_agent in /etc/pam.d/sudo, and have it use the pre-existing SSH authentication as the "password", instead of having it prompt for a password.

But the part I'm concerned about is that they seem to think that having password-less sudo is a security win.

[Perixoog → LukeShu]

Yes, and yes.

The pam module requires you to forward a remote connection to your ssh agent - when you connect to a compromised server your attacker can authenticate to other machines as you.

An ssh key for root is simpler and safer.

[smhenderson → LukeShu]

But the part I'm concerned about is that they seem to think that having password-less sudo is a security win.

I thought they were saying they don't want people's passwords. People reuse them, naive people giving up an actual root password, etc.

Not sure they mean always using NOPASSWORD is good for security.

[LukeShu → smhenderson]

Sure, giving the password to an application is a mess. Because if the application is compromised, the attacker now has the application's sudo password (ie, the vuls user's password, not the root password), and that's a bad deal. But just having it NOPASSWORD wide open is strictly worse. A knee-jerk reaction is to avoid passwords because it's another attack surface that can be broken open, but in this case just getting rid of it is strictly worse. With SSH, disabling password auth is turning the locked door into a solid brick wall. With this, NOPASSWORD is taking the door off the hinges because you are afraid of someone picking it.