По какой-то причине я не могу выполнить su для получения root-прав от пользователя без полномочий root:
[rilindo@kerberos ~]$ /bin/su -
-bash: /bin/su: Permission denied
Запуск вывода из /var/log/audit/audit.log либо возвращает следующее:
[root@kerberos tmp]# cat /tmp/audit
type=AVC msg=audit(1319322088.937:68012): avc: denied { execute } for pid=9794 comm="bash" name="su" dev=dm-0 ino=1048659 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319322088.937:68012): arch=c000003e syscall=59 success=no exit=-13 a0=26a7df0 a1=26c9b30 a2=269efa0 a3=18 items=0 ppid=8435 pid=9794 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=4454 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1319322088.944:68013): avc: denied { getattr } for pid=9794 comm="bash" path="/bin/su" dev=dm-0 ino=1048659 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319322088.944:68013): arch=c000003e syscall=4 success=no exit=-13 a0=26a7df0 a1=7fff26b200d0 a2=7fff26b200d0 a3=18 items=0 ppid=8435 pid=9794 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=4454 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1319322088.944:68014): avc: denied { getattr } for pid=9794 comm="bash" path="/bin/su" dev=dm-0 ino=1048659 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319322088.944:68014): arch=c000003e syscall=4 success=no exit=-13 a0=26a7df0 a1=7fff26b200b0 a2=7fff26b200b0 a3=18 items=0 ppid=8435 pid=9794 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=4454 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
Это приводит к этому решению от audit2allow:
[root @ kerberos tmp] # cat / tmp / audit | audit2allow
#============= user_t ==============
#!!!! This avc is allowed in the current policy
allow user_t su_exec_t:file { execute getattr };
[root@kerberos tmp]#
Или этот вывод:
type=AVC msg=audit(1319334064.195:39047): avc: denied { read open } for pid=6067 comm="bash" name="su" dev=dm-0 ino=1048587 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319334064.195:39047): arch=c000003e syscall=59 success=no exit=-13 a0=eecbd0 a1=eecbf0 a2=ec7720 a3=18 items=0 ppid=2857 pid=6067 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts8 ses=2 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1319334064.200:39048): avc: denied { read } for pid=6067 comm="bash" name="su" dev=dm-0 ino=1048587 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319334064.200:39048): arch=c000003e syscall=21 success=no exit=-13 a0=eecbd0 a1=4 a2=0 a3=18 items=0 ppid=2857 pid=6067 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts8 ses=2 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1319334064.200:39049): avc: denied { read } for pid=6067 comm="bash" name="su" dev=dm-0 ino=1048587 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:su_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1319334064.200:39049): arch=c000003e syscall=2 success=no exit=-13 a0=eecbd0 a1=0 a2=43 a3=18 items=0 ppid=2857 pid=6067 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts8 ses=2 comm="bash" exe="/bin/bash" subj=user_u:user_r:user_t:s0 key=(null)
type=AVC msg=audit(1319334064.208:39050): avc: denied { rlimitinh } for pid=6069 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1319334064.208:39050): avc: denied { siginh } for pid=6069 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=AVC msg=audit(1319334064.208:39050): avc: denied { noatsecure } for pid=6069 comm="setroubleshootd" scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1319334064.208:39050): arch=c000003e syscall=59 success=yes exit=0 a0=944aa0 a1=9447e0 a2=943010 a3=1 items=0 ppid=6068 pid=6069 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1319334064.369:39051): avc: denied { write } for pid=6069 comm="setroubleshootd" name="rpm" dev=dm-0 ino=655363 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1319334064.369:39051): arch=c000003e syscall=21 success=no exit=-13 a0=1405430 a1=2 a2=0 a3=9 items=0 ppid=6068 pid=6069 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1319334064.370:39052): avc: denied { write } for pid=6069 comm="setroubleshootd" name="rpm" dev=dm-0 ino=655363 scontext=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:rpm_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1319334064.370:39052): arch=c000003e syscall=21 success=no exit=-13 a0=1405430 a1=2 a2=0 a3=5 items=0 ppid=6068 pid=6069 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="setroubleshootd" exe="/usr/bin/python" subj=system_u:system_r:setroubleshootd_t:s0-s0:c0.c1023 key=(null)
При этом audit2allow предлагает следующее:
#============= setroubleshootd_t ==============
#!!!! The source type 'setroubleshootd_t' can write to a 'dir' of the following types:
# var_log_t, setroubleshoot_var_lib_t, setroubleshoot_var_run_t, setroubleshoot_var_log_t, var_lib_t, var_run_t, root_t
allow setroubleshootd_t rpm_var_lib_t:dir write;
#============= system_dbusd_t ==============
allow system_dbusd_t setroubleshootd_t:process { siginh rlimitinh noatsecure };
#============= user_t ==============
allow user_t su_exec_t:file { read open };
Как ни странно, он переключается между двумя сообщениями всякий раз, когда я пытаюсь загрузить новую политику, следующим образом:
[root@kerberos tmp]# cat /tmp/audit2 | audit2allow -M local
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i local.pp
Попытка использовать опцию обновления возвращает следующее:
[root@kerberos tmp]# semodule -u local.pp
libsemanage.get_direct_upgrade_filename: Previous module local is same or newer. (No such file or directory).
semodule: Failed on local.pp!
Следует отметить следующее:
В системе изначально не было включено selinux. Проблема началась после того, как я включил selinux:
изначально это была проблема с использованием sudo su -, которая во время устранения неполадок привела к этой проблеме.
На новых хостах, которые я построил после этого, по умолчанию был включен selinux - и у них не было этой проблемы, что означало, что что-то не было включено правильно, когда я возвращаю SELinux к «принудительному» для исходного сервера.
Вот разрешения и возможности для команды su:
[root@kerberos tmp]# getfacl /bin/su
getfacl: Removing leading '/' from absolute path names
# file: bin/su
# owner: root
# group: root
# flags: s--
user::rwx
group::r-x
other::r-x
[root@kerberos tmp]# ls -laZ /bin/su
-rwsr-xr-x. root root system_u:object_r:su_exec_t:s0 /bin/su
[root@kerberos tmp]#
как ни странно, в какой-то момент мне пришлось выполнить su с точным путем, даже если он находится на моем пути. Также любопытно, что если я вхожу в систему как root, а затем su как обычный пользователь, я могу использовать команду su:
[root@kerberos tmp]# su - rilindo [rilindo@kerberos ~]$ su - Password: [root@kerberos ~]#
Некоторое направление приветствуется.
Ваша проблема в том, что вы работаете в домене user_t как root.
user_t не имеет доступа к su.
Измените своего пользователя на пользователя staff_u, чтобы он исчез.
semanage login -a -s staff_u -r s0 rilindo
Также обратите внимание, что su сам по себе не поможет вам в этом отношении, поскольку вы используете тип Staff_t, который не будет делать все, что вы хотите.
Чтобы исправить это, отредактируйте sudoers и добавьте к нему своего пользователя, например:
rilindo ALL=(ALL) ROLE=sysadm_r TYPE=sysadm_t ALL
Теперь вы можете выполнить sudo su - и проблем не возникнет!