web-dev-qa-db-ja.com

freeIPAでSELinuxに制限されたユーザーにSudoアクセスを許可する

freeIPA を使用して、RBAC、HBAC、Sudoルール、および数百の仮想マシンのドメインのSELinuxユーザーマッピングを定義しています。複数のチーム（開発者、データベース管理者、システム管理者、管理者など）へのアクセス。

現在、これらのマシンのSELinuxポリシーはtargetedに設定されており、これらのシステムをstrictで実行するために、unconfined_uSELinuxユーザーを削除する可能性について考えています。ポリシー。

そのための要件の1つは、エンドユーザーがunconfined_uからstaff_uに「降格」されたという事実をエンドユーザーに透過的にすることです。問題は、SudoがSELinuxユーザーマッピングと相互運用する方法にあります。いくつかの事実：

  1. 制限されたSELinuxユーザーを使用したいが、それでもSudoを使用できるようにしたい場合は、staff_uを使用する必要があります。これはSELinuxユーザーです SETUID実行可能ファイルにアクセスできます） 。

  2. ユーザーがシステムにログインすると、SELinuxユーザーマッピングが割り当てられます。 SELinuxユーザーがsu（unconfined_u）またはSudo（unconfined_u、staff_u）を実行できる場合でも、そのマッピングは変更されません。

  3. SudoのSELinux Specには、現在、定義されたtypesおよびrolesでコマンドを実行する機能が含まれていますが、userを指定する可能性もありません。詳細については、 ここ を参照してください。

  4. この展開に関係するマシンはすべてfreeIPAクライアントであり、それらのSudoポリシーはfreeIPAによって管理されますが、フォールバックとして提供されるpuppet管理されカスタマイズされた/etc/sudoersファイルもあります。 freeIPA障害の場合。

この問題を解決するための最初の試みは、変更されていないsudorulesへのstaff_uアクセスを許可するために必要なルールを含むポリシーモジュールを作成することでした。ポリシーは無期限に拡大する可能性があり、最終的にあなたがしていることはポリシーに穴を開けることであるため、このアプローチは間違っていることが証明されています。

したがって、これまでのところ、これらの事実に対処する方法は、sudorulesを書き直して、適切なSELinuxユーザーに切り替えるためのrunconの呼び出しを明示的に含めることでした。したがって、通常の開発者は実行する必要があります。 、 例えば：

$ Sudo -u jboss runcon -u sysadm_u jboss_cli.sh

これには、既存のすべてのsudorulesを変更する必要があり、ユーザーが通常の実行方法を変更する必要があるという欠点があります。したがって、質問は次のとおりです。

  • Runas_Spec定義でSELinuxユーザーを明示的に定義する方法はありますか？
  • sudoersで不可能な場合、freeIPAでsudoruleをSELinuxユーザーマッピングに定義またはバインドすることは可能ですか？

このシナリオを検討してください。

# ipa sudorule-show services_4_operators_3
  Rule name: services_4_operators_3
  Description: Operator Level 3 access to service management commands
  Enabled: TRUE
  User Groups: operators_3
  Host Groups: all-hosts
  Sudo Allow Command Groups: services
  Sudo Option: type=sysadm_t, role=sysadm_r

# ipa sudocmdgroup-show services
  Sudo Command Group: services
  Description: commands for services and daemons management
  Member Sudo commands: /sbin/service, /sbin/chkconfig

私が試してみると：

$ Sudo service sshd status
Sudo: unable to open /var/log/Sudo-io/seq: Permission denied

 time-> Wed Sep 11 09:57:30 2013 
 type = PATH msg = audit（1378886250.584：46644668）：item = 0 name = "/ var/log/Sudo-io/seq "inode = 154 dev = fd：0c mode = 0100600 ouid = 0 ogid = 1168000009 rdev = 00：00 obj = unconfined_u：object_r：var_log_t：s0 
 type = CWD msg = audit（1378886250.584：46644668）：cwd = "/ home/some_user" 
 type = SYSCALL msg = audit（1378886250.584：46644668）：Arch = c000003e syscall = 2 success = no exit = -13 a0 = 7fff2e7ab970 a1 = 42 a2 = 180 a3 = 0アイテム= 1 ppid = 2374 pid = 2442 auid = 1168000009 uid = 1168000009 gid = 1168000009 euid = 0 suid = 0 fsuid = 0 egid = 1168000009 sgid = 1168000009 fsgid = 1168000009 tty = pts0 ses = 6459 comm = "Sudo" exe = "/ usr/bin/Sudo "subj = staff_u：staff_r：staff_Sudo_t：s0-s0：c0.c1023 key =" access "
 type = AVC msg = audit（1378886250.584：46644668）：avc：denied {read write} for pid = 2442 comm = "Sudo" name = "seq" dev = dm-12 ino = 154 scontext = staff_u：staff_r：staff_Sudo_t：s0-s0：c0.c1023 tcontext = unconfined_u：object_r：var_log_t：s0 tclass = file

Defaultsでlog_outputを使用しているため、次のようになります。

# ll -dZ /var/log/Sudo-io
drwx------. root root system_u:object_r:var_log_t:s0   /var/log/Sudo-io/

このAVC拒否を「修正」しようとすると、次の理由により、前述の無限ポリシーモジュールが生成されます。

allow staff_Sudo_t var_log_t:file { open read write lock create };
allow staff_Sudo_t var_log_t:dir { write add_name create search };

このような権限を有効にすると示されるように、これは偽の問題です。

$ Sudo service sshd status
env: /etc/init.d/sshd: Permission denied

 time-> Wed Sep 11 11:00:53 2013 
 type = PATH msg = audit（1378890053.185：46646934）：item = 0 name = "/ etc/init.d/sshd" inode = 5490 dev = fd：01 mode = 0100755 ouid = 0 ogid = 0 rdev = 00：00 obj = system_u：object_r：sshd_initrc_exec_t：s0 
 type = CWD msg = audit（1378890053.185：46646934）：cwd = " /"
type=SYSCALL msg = audit（1378890053.185：46646934）：Arch = c000003e syscall = 59 success = no exit = -13 a0 = 7fffc0829862 a1 = 7fffc0829578 a2 = 607030 a3 = ffffe000 items = 1 ppid = 6715 pid = 6720 auid = 1168000009 uid = 0 gid = 0 euid = 0 suid = 0 fsuid = 0 egid = 0 sgid = 0 fsgid = 0 tty = pts2 ses = 6459 comm = "env" exe = "/ bin/env" subj = staff_u：sysadm_r：sysadm_t：s0-s0：c0.c1023 key =（null）
 type = AVC msg = audit（1378890053.185：46646934）：avc：denied {execute} for pid = 6720 comm = "env "name =" sshd "dev = dm-1 ino = 5490 scontext = staff_u：sysadm_r：sysadm_t：s0-s0：c0.c1023 tcontext = system_u：object_r：sshd_initrc_exec_t：s0 tclass = file

最終編集

ようやく中期的な解決策を採用しました。 IPAサーバーを次のように構成しました。

$ Sudo -u dsastrem ipa config-show
  Maximum username length: 32
  Home directory base: /home
  Default Shell: /bin/rbash
  Default users group: ipausers
  Default e-mail domain: company.com
  Search time limit: 2
  Search size limit: 100
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: FALSE
  Certificate Subject base: O=COMPANY.COM
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash
  SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Default SELinux user: guest_u:s0
  Default PAC types: MS-PAC

そして、いくつかのRBACをSELinuxユーザー（staff_u）にバインドする、これに類似したいくつかのSELinuxユーザーマッピングを定義しました。

$ Sudo -u dsastrem ipa selinuxusermap-find
---------------------------
X SELinux User Maps matched
---------------------------
  ....

  Rule name: semap_operators_3_mad
  SELinux User: staff_u:s0-s0:c0.c1023
  HBAC Rule: operators_3_access
  Description: SELinux user mapping for MAD level 3 operators
  Enabled: TRUE

  ....
----------------------------
Number of entries returned X
----------------------------

私のSudoルールは次のようになります。

  Rule name: services_4_operators_3
  Description: Operator Level 3 access to service management commands
  Enabled: TRUE
  User Groups: operators_3
  Host Groups: all-hosts
  Sudo Allow Command Groups: services
  Sudo Option: role=unconfined_r

unconfined_uを完全に排除したかったので、これは私の最終目標ではありませんが、全体的なセキュリティが少し強化されるため、これは良い一歩です。もちろん、マシューの答えは正しいです。staff_uはSudoオプションを介してより高い特権ドメインに移行できるはずだからです。しかし、system_uがunconfined_uを置き換えるために完全に装備されていないという問題がまだあります。おそらくそうすることを意図していないからでしょう。

sudoselinuxfreeipa
4
dawud

sysadm_rとしてstaff_uの役割に移行できることをご存知ですか？

たとえば、次のように機能します。

myuser  ALL=(ALL)   TYPE=sysadm_t ROLE=sysadm_r PASSWD: ALL

これにより、（ほぼ）制限なしのルートとして実行できることを実行できます。

ああ、最後のヒントです。 suの使用は、RBACでは少し注意が必要です（さまざまな場所に移動するために多くのことを行います）。代わりに、多くのrunuserオーバーヘッドなしで同じことを行うsuコマンドを使用できます。

私は実際にそのようなsudoersでのsuの使用を制限しています。

%wheel   ALL=(ALL)   TYPE=sysadm_t ROLE=sysadm_r NOPASSWD: ALL, ! /bin/su

デフォルトでは、SELinuxポリシーはSudo遷移が必要なシグナルを管理することを許可しないためです。本当に人々はおそらくとにかくSudo -iを使うべきです。

私は通常、悪い習慣からSudo su -を実行することを好む人々（私のように！）の2文字の代替として、runuserをruにハードリンクします。

3
Matthew Ife