Типовий випадок використання пароля групи

Я перевірив більш ніж півстолітнього досвіду Unix і ні мої колеги, ні я ніколи не встановлювали пароль для групи ( sgі gpasswd). Що може бути типовим випадком використання групового пароля чи він є майже лише через історичні причини?

Я теж ніколи не бачив, щоб ця функція була використана, навіть не один раз. Більшість SA навіть не знають, що цей об'єкт існує. Переглядаючи сторінку чоловіка дляgpasswd була ця примітка:

Примітки про групові паролі

  Group passwords are an inherent security problem since more than one 
  person is permitted to know the password. However, groups are a useful 
  tool for permitting co-operation between different users.

Чому вони існують

Я думаю, що вони були природною ідеєю наслідувати модель користувача, яка має паролі, і це сенс дублювати цю модель справи також групам. Але на практиці вони насправді не в чомусь корисні.

Ідея з груповим паролем полягає в тому, що якщо вам знадобиться отримати доступ до певної групи (тієї, до якої ви не входили в список членів), ви можете це зробити за допомогою newgrpкоманди та отримати виклик пароля, щоб отримати доступ до цих альтернативних груп.

Велика проблема з ними полягає в тому, що існує лише один пароль для кожної групи, таким чином, змушуючи людей ділитися цим єдиним паролем, коли декілька людей вимагають доступу до цієї однієї конкретної групи.

Групи

Більшість середовищ, з якими я стикався, зазвичай ставлять людей до вторинних груп, а потім надають цим групам доступ до файлів у файловій системі, і це задовольнило майже все використання, яке потрібно мати.

судо

З появою sudoдодаткових дозволів можна в міру необхідності роздавати групам, що ще більше підриває будь-які випадки використання, які, можливо, надали паролі групи. Якщо вам потрібно було дозволити користувачам отримати більше дозволів, було набагато простіше створити ролі, sudoа потім просто дозволити там ім’я користувача або групу, в якій вони знаходилися, дозволи отримати там дозволи, щоб вони могли виконати певну задачу.

ACL

Нарешті, можливість створення списків контролю доступу (ACL) дійсно дала останній шматочок гнучкості, який модель користувача / групи / інші дозволи не могла забезпечити окремо, відкинувши будь-яку можливу потребу в групових паролях до невизначеності.

Ось практичне використання групових паролів, які я реалізував для себе на своєму робочому сервері, оскільки в журналах вказано, що мій обліковий запис був змушений (або могла бути атака зі словника).
Я використовував ssh-keygenі з puttygenповагою генерував пари ключів для використання зі своєї робочої станції та домашнього комп’ютера. Ключ, який я використовую вдома, вимагає пароль. Я додав обидва відкриті ключі до .ssh/authorized_keys, створив групу marionetteз паролем і без членів. Як корінь я visudoдодав наступні рядки.

Cmnd_Alias      SUDOING = /bin/bash, /usr/bin/sudo -i
%marionette     ALL=NOPASSWD:SUDOING

Я відключив пароль свого облікового запису, ви ніхто не зможе ввійти в нього таким чином. Зараз я входжу лише за допомогою моїх ключів, і введення групи, захищеної паролем, newgrp marionetteдозволяє мені отримати root sudo -i.
Без цього NOPASSWD:варіанту буде потрібно пароль вашого облікового запису користувача. Якщо він відключений, а цієї групи немає NOPASSWD, ви не зможете sudo -i. Він також зажадає пароль вашого облікового запису користувача, якщо у вашому списку команд немає /bin/bashабо іншої оболонки, якою використовується ваш root за замовчуванням.

Незважаючи на те, що це робить шлях до десанту на кілька кроків довше, це додає хорошого рівня безпеки. Якщо ви вирішите зробити так, щоб усі ваші облікові записи були такими, створіть один локальний обліковий запис із привілеями пароля та sudo, але забороняйте йому входити в ssh /etc/ssh/sshd_config, додаючи щось на зразок:

DenyUsers root caan
DenyGroups root daleks

Це необхідно для локального доступу у випадку, якщо ви перевстановились та забули створити резервну копію ключів доступу.

Я ніколи не бачив випадку використання цього пароля. І це приблизно 20 років досвіду * nix.

Єдиний варіант використання, який мені спадає на думку, - це встановити його на "!" - заблоковано, тому ніхто, не будучи членом цієї групи, не може змінити на нього newgrpкоманду.

Якщо я переглянув / etc / group на SLES або / etc / gshadow у системах, що базуються на RedHat, це здається "типовим" випадком використання. SLES навіть не намагався створити тіньовий механізм для цього пароля.

Дозвольте запропонувати використати випадок.

Спершу дозвольте сказати, що ми настільки звикли до терміна "користувач", що навіть не думаємо про це. Але "користувач" насправді не є користувачем . Наприклад, вдома у нас є три комп’ютери - ноутбук моєї дружини, мій ноутбук і звичайний настільний комп’ютер. Коли я використовую ноутбук дружини, я входжу з її обліковим записом користувача. Коли вона використовує мій ноутбук, вона входить із моїм обліковим записом користувача. Якщо комусь потрібен робочий стіл, він використовує один загальний обліковий запис. Ми бачимо, що те, що комп'ютерна система називає «користувачем», насправді не є користувачем, а робочим процесом - сукупністю заходів.

Ось питання: Чому я не можу займатися більше ніж однією діяльністю - однією для кожної іншої роботи, яку я маю? Я можу. На своєму робочому комп’ютері я створив (експериментально) багато різних користувачів, щоб я міг зосередитись на поточному завданні. Я розміщую всіх цих користувачів в одній групі, щоб я міг отримати доступ до своїх файлів, не маючи, яким користувачем я зараз користуюся.

То де ж gpasswd підходить до цього?

Поведінка Ubuntu за замовчуванням полягає у створенні спеціальної групи для кожного користувача.

Що робити, якщо ми вирішимо думати про ці основні групи як користувачів і думати про користувачів системи як робочі процеси ?

Чим цим новим користувачам потрібен пароль для входу, правда? Ось місце gpasswd. Мені все-таки потрібно розібратися, як увійти в групу (до цього моменту я знаю, що ви можете перемикати групи з gpasswd, якщо ви вже увійшли в систему).