☰

SmartOS로 내보낼 때 SMF 매니페스트 구성 데이터가 손실되는 이유는 무엇입니까?

tag-icon • tag-icon solaris opensolaris smf illumos smartos
SmartOS로 내보낼 때 SMF 매니페스트 구성 데이터가 손실되는 이유는 무엇입니까?

Joyent의 Base64 1.8.1 SmartOS 이미지에서 SMF(Server Management Facility) 하에서 서버 프로세스를 실행하고 있습니다.

SmartOS에 대해 잘 모르는 사람들을 위해 KVM이 포함된 IllumOS의 클라우드 기반 배포판을 제공합니다. 그러나 본질적으로 이는 Solaris와 유사하며 OpenSolaris를 상속합니다. 따라서 SmartOS를 사용해 본 적이 없더라도 ServerFault에 대한 Solaris 지식을 활용하고 싶습니다.

내 문제는 권한이 없는 사용자가 자신이 소유한 서비스를 다시 시작할 수 있도록 허용하고 싶다는 것입니다. 저는 RBAC를 사용하고 인증을 추가하고 /etc/security/auth_attr해당 인증을 내 사용자와 연결하여 이를 수행하는 방법을 알아냈습니다 .

그런 다음 서비스의 SMF 매니페스트에 다음을 추가했습니다.

<property_group name='general' type='framework'>
  <!-- Allow to be restarted-->
  <propval name='action_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
  <!-- Allow to be started and stopped -->
  <propval name='value_authorization' type='astring'
    value='solaris.smf.manage.my-server-process' />
</property_group>

그리고 이것은 가져올 때 잘 작동합니다. 권한이 없는 사용자는 자신의 서버 프로세스를 다시 시작하고 중지할 수 있습니다(자동화된 코드 배포를 위한 것입니다).

그러나 SMF 매니페스트를 내보내면 이 구성 데이터가 사라집니다. 해당 섹션에 표시되는 것은 다음과 같습니다.

<property_group name='general' type='framework'>
  <property name='action_authorization' type='astring'/>
  <property name='value_authorization' type='astring'/>
</property_group>

왜 이런 일이 일어나는지 아는 사람이 있나요? 내 구문이 잘못된 건가요, 아니면 단순히 SMF를 잘못 사용하고 있는 건가요?

답변1

svccfg(1M)이 깨졌기 때문에 내가 깨뜨렸습니다.

2007년에 저는 적절한 권한이 있는 사용자만 읽을 수 있는 중요한 정보를 포함할 수 있는 속성 그룹을 허용하는 기능을 SMF에 추가했습니다. 아이디어는 "read_authorization" 속성을 속성 그룹에 추가할 수 있고 권한이 없거나(기본적으로 루트) 해당 속성에 의해 명명된 권한 중 하나를 소유하지 않은 사람은 누구나 속성의 값을 읽을 수 없다는 것입니다. 그룹에서. 이는 아래에 통합되었습니다.이 커밋이며 (적어도) Sun ZFS 저장소 제품에서 LDAP 비밀번호와 같은 항목을 저장하는 데 사용됩니다.

해당 작업의 일환으로 우리는 이러한 값을 읽을 수 있는 권한이 있는 사용자라도 서비스 상태를 내보내거나 SMF 저장소의 아카이브를 생성하여 실수로 해당 값을 노출하지 않도록 하고 싶었습니다. 그래서 모든 속성 값을 명시적으로 내보내는 svccfg의 내보내기 및 아카이브 명령에 '-a' 플래그를 추가하고 읽기 보호된 항목을 제외하도록 기본값을 변경했습니다.

불행하게도 이 제한은 올바르게 적용되지 않습니다. 이 경우 값이 있는 "일반" 속성 그룹에서 선택된 몇 가지 속성을 제외한 모든 속성 내보내기를 거부합니다. 나머지는 현재 보고 있는 것과 같은 값 없이 내보내집니다. 불행하게도 -a 옵션을 사용하는 것은 여기서 도움이 되지 않습니다. 왜냐하면 우리가 관련 지점에 도달할 때쯤에는 여러분이 그것을 통과했다는 것을 아는 데 필요한 컨텍스트가 더 이상 없기 때문입니다. 이러한 값을 노출하기 위해 이 플래그가 필요한지 여부에 대해 의문을 제기하는 것도 공평합니다. 서비스 상태 변경을 허용하는 인증의 ID는 실제로 민감하며 공격자에게 유용합니다. 내가 이 글을 쓸 당시 내 마음속에 있었던 것은 의심할 여지가 없으며, 명시적으로 원하지 않는 한 다른 사람의 관점에서 이를 제한하는 것이 합리적입니다. 그러나 이전 버전의 S10에서는 내보낸 XML과 아카이브에 이를 포함했기 때문에 확실히 호환되지 않는 변경이었습니다. 그 일로 화를 낸 것은 용서받을 수 있습니다. 그러나 여기서 실제 문제는 문제의 속성 그룹이 "일반"인 경우 -a가 작동하지 않는다는 것입니다. 어떻게 당신이 이걸 처음으로 친 사람인지 모르겠어요.

이 문제는 해당 페이지(여기)에서 확인할 수 있습니다.. 그동안 생성된 XML에 속성 값을 수동으로 추가하여 이 문제를 해결하는 것을 고려할 수 있습니다. 필요한 경우 svcprop(1)을 통해 읽을 수도 있습니다. 사과드립니다. 이 질문에 관심을 가져주신 Deirdre Straughan에게 감사드립니다.

관련 정보