su world가 실행 가능한 이유는 무엇입니까?

su world가 실행 가능한 이유는 무엇입니까?

여러 사용자가 원격으로 로그인하는 헤드리스 서버가 있습니다. 다른 사용자는 sudoers 파일에 없으므로 통과할 수 없습니다 sudo. 그러나 권한이 su있으므로 -rwsr-xr-x루트 비밀번호를 무차별 대입하려는 시도를 막을 수는 없습니다.

사용자가 루트 비밀번호를 알고 있다면 어쨌든 시스템이 손상될 수 있다고 주장할 수도 있지만 저는 그렇지 않다고 생각합니다. OpenSSH는 다른 사용자가 서버에 물리적으로 액세스할 수 없도록 PermitRootLogin no구성 되어 있습니다. PasswordAuthentication no내가 아는 한, 전체 실행 권한은 /usr/bin/su사용자가 내 서버에서 루트 액세스 권한을 얻으려고 시도할 수 있는 유일한 방법입니다.

나를 더욱 혼란스럽게 만드는 것은 그것이 작동하지 않는 것 같다는 것입니다. su아무것도 하지 않고 그냥 달릴 수 있게 해주지만 sudo su불편하지는 않습니다.

내가 뭔가를 간과했나요? su단지 역사적인 이유로 공연을 할 수 있는 세계의 허가가 있습니까? 이 권한을 제거하면 아직 경험하지 못한 단점이 있습니까?

답변1

뭔가를 놓쳤어요일카츄의 답변문제는 루트로 승격시키는 것은 단지 하나의 특정한 용도일 뿐이라는 것입니다 su. su의 일반적인 용도는 다른 사용자의 로그인 계정으로 새 쉘을 여는 것입니다. 그 다른 사용자할 수 있다root(아마도 가장 일반적으로), 그러나 su다음과 같이 가정하는 데 사용될 수 있습니다.어느로컬 시스템에서 확인할 수 있는 ID입니다.

예를 들어 사용자로 로그인하여 보고 되었지만 재현할 수 없는 문제를 jim조사하려는 경우 사용자로 로그인 하여 문제를 일으키는 명령을 실행하려고 할 수 있습니다.mikemike

13:27:20 /home/jim> su -l mike
Password:(I type mike's password (or have him type it) and press Enter)
13:27:22 /home/mike> id
uid=1004(mike) gid=1004(mike) groups=1004(mike)
13:27:25 /home/mike> exit  # this leaves mike's login shell and returns to jim's
13:27:29 /home/jim> id
uid=1001(jim) gid=1001(jim) groups=1001(jim),0(wheel),5(operator),14(ftp),920(vboxusers)

-l옵션을 사용하면 전체 로그인( 페이지 su당)을 시뮬레이션하게 됩니다 .man

그러나 위의 작업을 수행하려면 mike비밀번호를 알아야 합니다. 액세스 권한이 있으면 sudo비밀번호 없이도 로그인할 수 있습니다 mike.

13:27:37 /home/jim> sudo su -l mike
Password:(I type my own password, because this is sudo asking)
13:27:41 /home/mike>

요약하자면, 실행 파일의 권한이 su표시된 것과 같은 이유 su일반 도구시스템의 모든 사용자가 사용할 수 있습니다.

답변2

역사적으로(GNU가 아닌 unice에서는) 그렇지 않았거나 적어도 "wheel"이라는 그룹에 속해 있고 허용되었는지 수동으로 확인했습니다 su. su당시 액세스 제어에 대한 RMS의 아이디어로 인해 GNU 버전은 그렇지 않았습니다. 다시 실행 이제 이 기능은 다음과 같습니다.

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

이에 대한 자세한 정보는 "wheel group rms" 또는 이와 유사한 것을 검색하여 찾을 수 있습니다.

답변3

그러나 권한이 su있으므로 -rwsr-xr-x루트 비밀번호를 무차별 대입하려는 시도를 막을 수는 없습니다.

예. 일반적인 Linux 시스템을 가정하면 pam_unix.so모듈은 실패한 인증 시도를 약 2초 정도 지연시키지만 동시 시도를 막을 수 있는 것은 없다고 생각합니다.

실패한 시도는 물론 기록됩니다.

Aug 16 22:52:33 somehost su[17387]: FAILED su for root by ilkkachu

비밀번호를 모니터링하는 시스템이 있는 경우 무차별 비밀번호 크래킹이 로그에 눈에 띄게 표시되어야 합니다. 신뢰할 수 없는 로컬 사용자가 있는 경우 이 작업을 수행해야 할 수도 있습니다. 로컬 전용 권한 상승 취약성은 신뢰할 수 없는 로컬 사용자가 시도할 수도 있으며 원격 권한 상승보다 더 일반적입니다.

나를 더욱 혼란스럽게 만드는 것은 그것이 작동하지 않는 것 같다는 것입니다.

물론 유용합니다. root비밀번호를 알고 있으면 레벨을 올릴 수 있습니다.

su아무것도 하지 않고 그냥 달릴 수 있게 해주지만 sudo su불편하지는 않습니다.

sudo su약간 중복됩니다. 다른 사용자로서 프로그램을 실행할 수 있도록 설계된 두 개의 프로그램을 사용할 필요는 없습니다. 하나만 있으면 충분합니다. 쉘을 실행하려면 sudo -ior sudo -s(또는 등)을 사용하세요.sudo /bin/bash

내가 뭔가를 간과했나요? 세계가 su를 처형하도록 허락한 것은 단지 역사적인 이유 때문인가요?

찾다. 글쎄요, 모든 시스템에 sudo대안이 있는 것은 아니며, 여러분이 이를 역사적이라고 생각하실지 모르겠습니다.

이 권한을 제거하면 아직 경험하지 못한 단점이 있습니까?

실제로는 아닙니다. 제가 아는 바는 아닙니다. 나생각하다일부 시스템은 su특정 그룹(" wheel")의 구성원만 실행할 수 있도록 설정되어 있습니다. sudo원하는 경우 이 작업도 수행할 수 있습니다( chown root.sudousers /usr/bin/sudo && chmod 4710 /usr/bin/sudo) .

또는 필요하지 않은 경우 하나 또는 두 프로그램을 모두 삭제할 수 있습니다. 하지만 데비안에서는 패키지와 함께 제공되므로 전체 패키지를 제거하는 것은 아마도 좋은 생각이 아닐 것입니다 su. login(이렇게 짝을 이루고 login함께 su있는 것은 조금 역사적인 것 같습니다.)

답변4

su는 누구나 실행할 수 있도록 전 세계적으로 실행 가능해야 합니다. 많은 시스템에서 비밀번호를 제공하여 다른 사용자로 변경하는 데 사용할 수 있습니다.

누군가가 루트 비밀번호를 무차별 대입하는 것이 걱정된다면 이 기능을 비활성화할 수 있습니다. (해시를 무효화하므로 주어진 비밀번호와 일치할 수 없습니다)

합의가 있는지는 모르겠지만 루트로 직접 로그인할 수 있다는 것 자체가 보안 문제라고 생각합니다.

관련 정보