Page MenuHomeVyOS Platform

migrate operator accounts to admin accounts and remove the option to setup an operator account
Closed, ResolvedPublicFEATURE REQUEST

Details

Difficulty level
Easy (less than an hour)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

hagbard changed the task status from Open to In progress.Apr 4 2019, 9:28 PM
hagbard triaged this task as Normal priority.
hagbard changed Difficulty level from Unknown (require assessment) to Easy (less than an hour).

Migration script will be in the next rolling release (vyos-1x). Since level admin is the only level, I think it can be removed from the options tree entirely and set automatically in the config.

Looks like the option level can be removed entirely.

set system login user testuser authentication plaintext-password spassword

uid=1003(vyos) gid=100(users) groups=100(users),4(adm),6(disk),27(sudo),30(dip),107(vyattacfg),110(frrvty)
uid=1004(testuser) gid=100(users) groups=100(users),4(adm),6(disk),27(sudo),30(dip),107(vyattacfg),110(frrvty)

For now I left the option in vyatta-cfg-system for the conversion of existing operator accounts.

looking at this from a security perspective i would keep level admin, but block users of operator.. then any user is not automatically getting more privileges without the admin notice it….

I agree, however (https://blog.vyos.io/the-operator-level-is-proved-insecure-and-will-be-removed-in-the-next-releases) :
[...]
in the next releases that feature will be removed and operator level users will be converted to admin
[...]

That's why I did the conversion, otherwise we would announce something and do then something different.
You can still set "... level admin", if not set at all user is admin, if set ... well it's the only option left to set anyway and should be quite clear.
But you bring up a good point, I think I need to update the documentation as well.

That is easy.. if level admin is set, the user is propagated into the config.. if the admin don't set it, the user is not propagated, and the user will not be able to login ..

I don't like doing things like this on an existing feature that could have a security impact based on a blog post that the admin might or might not have read....

As a workaround for this it could be implemented a "disable" flag on the users that replace the level operator flag in migration.. the result id the same, the operator user is then rendered unusable until the admin acknowledges that the user should have more privileges...