내 블로그다

1. 타바타 se라고 풀업, 푸쉬업, 싯업, 스콰트 

http://functionalmovement.co.kr/cross/bbs/board.php?bo_table=7_1&wr_id=21798

2. 다양한 방법

 http://tinylab.tistory.com/10

3. 타바타 풀업 8세트 + 타바타 스쿼트 8세트

http://www.3wcrossfit.com/cross/bbs/board.php?bo_table=10_1&wr_id=207

정리하다 보니 http://www.3wcrossfit.com/cross/index.php 여기의 왼쪽 메뉴에 맨몸 DailyWod가 있었구나;;;;

subject는 일반적으로 정보가 object사이에서 흐르게 하거나, system 상태를 변경시키게 하는 사람, 프로세스 혹은 디바이스같은 형태를 가진 active entity이다.

SELinux에서 subject는 일반적으로 active process이고 그와 관련된 security context를 가지고 있다. 하지만 한 프로세스는 context에 의존적인 object라고 부를 수 있다. 예를 들어

1. 동작중인 프로세스(즉 active entity)는 subject이다. 그 이슈는 동작중인 프로세는는 object들 사이에 정보가 흐르게 하고 system의 상태를 변경시킬 수 있다.
2. 프로세스는 또한 object라 부를 수 있다. 그 이유는 각각의 프로세스는 관련된 process라고 부르는 object class를 가지고 있기 때문이다. 이 object가 되는 프로세스는 policy가 동작중인 프로세스한테 어떤 권한을 허락하는지 정의한다.

위에 대한 예시는 Allowing a Process Access to Resource 섹션에서 볼 수 있다.

/.....

SELinux는 security server가 사용하는 모든 프로세스(또는  subject)와 object를 연관짓기 위해 security context를 필요로 한다. security server는 어떠한 접근이 policy에 의해 허가되는지 금지되는지 판단하기 위해 security context를 사용한다.

또한 security context는 "security label"또는 간단히 라벨이라고 알려져 있는데, 이 label이란 용어는 context에 따라서 많은 라벨의 타입이 있어서 조금 혼란스러울 수도 있다(다른 context임?)

SELinux에서 security context는 SELinux user와 역할(role), type 식별자, 그리고 MCS/MLS security level을 다음과 같이 정의하는 가변길이 문자열이다.

아래를 주목하자:

1. subject에 관한 접근 허가의 결정은 security context의 모든 구성요소를 이용한다.
2. object에 관한 접근 허가의 결정은 security context의 모든 구성요소를 이용한다. 하지만

a) user는 system_u라고 불리는 특별한 user에 설정되거나 생성하는 process의 SELinux user id에 설정된다. (로깅을위한 목적으로 사용되는 것 외에 어떠한 실제 목적이 없다?)

b) 규칙(role)은 security 결정하고 관련이 없다. 그리고 규칙(role)은 항상 object_r의 특별한 SELinux 내부 규칙에 설정된다.;;;??

따라서 object에 있어선, type(그리고 MLS에서 level)이 오직 유일하게 접근 결정과 관련있는 security field이다.

system_u와 object_r의 예는 라벨링을 한 후, ls -Z 명령어를 치명 다양한 디렉토리의 file system에서 볼 수 있다. 

아래의 예시는 프로세스들과 디렉토리들, 그리고 파일들에 대한 security context의 예이다.(policy는 MCS, MLS을 지원하지 않는다. 따라서 level field는 없다)

Process Security Context의 예

Object Security Context의 예:

TE 도메일으로의 접근을 더욱 세밀히 제어하기 위해서 SELinux는 role-base access control(RBAC)를 이용한다. 이 특징은 SELinux의 사용자로 하여금 한 개 이상의 역할(role)들과 연관되게하고, 그 역할들은  한개 이상의 domain type과 대응된다. (RBAC 다이어그램을 보라). GNU/Linux 사용자는 RBAC 기능의 일부가 아닌것에 주목할 필요가 있다. GNU/Linux 사용자는 SELinux만의 command를 이용하는 SELinux 사용자에 속한다. 다음을 참고하라.

• semanage login - GNU/Linux 사용자들로써 SELinux user를 관리한다.?
• semanage user - SELinux 사용자들로써 역할을 관리한다.?

Role Based Access Control 다이어드램은 어떻게 기본적인 loadable modules을 이용하여 SELinux 사용자와 역할이 연관되어지는지 보여준다. 그 loadable module은 Volume 2에 설명되어있는 간단한 message filter exercise를 형성한다.

SELinux 사용자는 사용자의 클래스나 그룹과 동일시 되어질 수 있다. 예를들어 Referene policy에는 user_u라는 일반적인 사용자와 staff_u와 sysadm_u라는 특별한 사용자가 존재한다. 또한 system_u라는 GNU/Linux 사용자와는 절대 연관되어질 수 없는 user가 있는데, 이것은 시스템 프로세스들과 시스템 object들과 같은 특별한 식별자들과 연관되어진다.

http://blog.naver.com/yyg1368?Redirect=Log&logNo=60134644249

이 글은 python 카테고리로 가야할까...

SELinux는 MAC를 시행하기 위해서 Type Enforcement란 독특한 스타일을 사용한다. SELinux에 한해서 그것은 모든 subject와 object는 그들과 연관된 type 식별자를 가지고 있고, 그것들은 policy에 적힌 rule을 시행하기 위해 사용된다.

SELinux Type Identifier는 간단한 가변길이 문자열이다. 그것은 policy 안에서 정의되고 security context과 연관되어 진다. 이것은 또한 policy를 만드는데 사용되는 대부분의 SELinux Language statement와 rule에서 사용되어지고, security server에 적재될 때 policy를 시행할것이다.

Type Identifier(이하 type)은 모든 subject와 object와 연관되기 때문에, 때때로 그 type이 실제로 어떤 것과 연관되어지는지 구분하기가 어려울 수도 있다(모든 Type Identifier는 "_t"로 끝나지만, 이것도 딱히 도움이 되진 않는다). 결국 어떻게 그것들이 policy에서 배치되는지와 어떻게 그것들이 SELinux에서 사용되는지 이해를하는 수 밖에 없다.

기본적으로 만약 Type Identifier가 subject를 참조하는데 사용되었으면, 그것은 GNU/Linux process나 domain(혹은 domain type)을 가리키고 있을 것이다. 만약 Type Identifier가 object를 참조하는데 사용되어진다면, TI는 object의 object type(즉 file type)을 명시하고 있을 것이다.

SELinux가 subject를 domain type에 연관된 active process라고 인식하고 있으면, SELinux Type enforcement domain의 범위는 굉장히 넓어진다. 예를 들어, Building a Basic Policy섹션에 있는 간단한 policy에서, system의 모든 프로세스들은 unconfined_t domain으로 돌아가고, 따라서 모든 프로세스들은 "of type unconfined_t"가 된다. (그 의미는 기본적인 리눅스 DAC policy상으로는 모든지 할 수 있다는 뜻이다)

오직 간단한 policy에서 구현된 추가적인 policy들일 때만(loadable module에 의한), 그 범위들은 한정되어질 수 있다. 예를 들어 독립적인 domain에 속하는 외부 게이트웨이(ext_gateway_t)가 있으면, 그것은 어떤 unconfined_t 프로세스들에 의해서도 간섭을 받지 않는다(gateway processs가 그 domain에 들어가거나 그 domain으로 변경되었을 경우만 뺴고). 이 시나리오는 대부분의 user space process들이 unconfined_t 도메인에서 돌아가는 Red Hat Fedora의 표준의 "targeted" policy와 비슷하다. (하지만 그 policy가 Reference Policy에 의해 제공되는 policy들과 같지는 않다. Reference policy는 수년동안 발전되어 왔고, 나름의 영역에 국한적으로 발전해왔다.)

제약

TE 환경에서 subject가 object를 접근할 수 있는 권한을 얻으려면 "allow" rule을 이용해야 한다. 예를 들어,

추후에 더 자시히 설명할 것이지만, 이것은 unconfined_t domain에서 돌아가는 process가 ext_gateway_t domain으로 변경하는 권한을 가지고 있다는 것을 의미한다. 하지만 policy 작성자가 이것을 더욱 제약하고 소스 도메인의 규칙이 타켓 도메인의 규칙과 같을때만 발생될 수 있게 만들 수도 있다. 그렇게 하려면 constrain 지시어를 적어야 한다.

이것은 process transition이 오직 소스 규칙이 타겟 규칙과 동일할때만 발생되도록하는 것을 의미한다. 그러므로 제약은 한 개 이상의 권한이 만족되어야하는 조건이 된다. (즉 RE 규칙에 부과적인 제약이 포함된다). 이것의 예는 Contraint Statement 섹션에서 찾아볼 수 있다.

policy 언어에는 MLS과 같은 분야를 지원하기 위해 많은 다양한 contraint statement가 존재한다. (Constraint Statement와 MLS Statements 섹션을 보라)

우측하단 AS 클릭

내 글은 4월 11일에 있음

대한통운: 접수번호 

http://efestival.yonhapnews.co.kr/efestival/v/index.jsp?vgnextoid=7f4adb73e95a0110db73e95a01102907010aRCRD&vgnextchannel=d70857ac13e2a010VgnVCM1000005106010aRCRD

http://www.gntour.go.kr/Tours/sub.jsp?Mcode=30104

http://squat.co.kr/

소개

SELinux는 다수의 GNU/Linux 배포판에 빌트인 된 최초의 Mandatory Access Control (MAC)이다. 원래 SELinux는 Utah University Flux팀과 US Department of Defence의 Flux Advanced Security Kernel(FLASK) 개발로부터 시작되었다. 그 개발은 NSA에 의해 강화되고, 또한 오픈 소스로 릴리즈됨으로써 더욱 강화되었다. SELinux의 개발에 관한 히스토리는 Flux와 NAS 웹싸이트에서 찾을 수 있다.

다음에 오는 각 섹션은 SELinux의 요소들에 관해 설명할 것이다. 그리고 대강의 논리적은 순서에 따라 기술되었다.

Note: SELinux가 설치될 때, 세개의 잘 정의된 디렉토리가 참조된다. 두 개는 최신버전에서 다음과 같이 변경되었다.

SEAndroid에서 위 디렉토리들은 존재하는가? 다른 디렉토리로 바뀌지 않았나?

SELinux는 유용한가?

Linux 에서 SELinux의 유용성을 보는 다양한 관점들이 있다. 이 섹션에서는 SELinux가 어디에 좋은지 또한 왜 좋지 않은지에 관한(그런것들을 목적으로 만들어지지 않았으므로..) 간단한 관점들을 소개한다.

SELinux는 Multi-Level Security(MLS)가 요구되는 군대 또는 보안 시스템을 위한 것만은 아니다. "Type Enforcement(TE)" 기능을 사용하면서, 어플리케이션들은 domain에 담겨딜 수 있고, "nutshell"이란 곳 안에서 실행되는데 최소의 권한이 주어진다. 

MLS가 뭐지?

1. SELinux가 Enable되면, policy는 어떤 자원과 연산이 그들에게 허락될지 정의한다. (즉 SELinux는 policy에 의해 허락되지 않은 access는 방어?한다). 이것이 SELinux가 왜 "Mandatory Access Control(MAC)"라 부를는지에 대한 이유이다.
2. 보안 규칙 또는 요구사항에 의해 만들어진 Policy 디자인, 구현 그리고 테스트는 매우 중요하다. 그렇지 않으면 안정성에 매우 불안전하게 된다.
3. SELinux는 어플리케이션을 'domain'이라는 것에 가두고, 작업에 필요한 최소한의 권한을 허용한다. 어플리케이션이 네트워크나 다른 어플리케이션이 접근권한을 요청할때는, 그에 대한 접근권한이 충족되어져 있어야만 한다. (적어도 어떤 interaction이 허락되어지는지와 어떤 것이 막혀야하는지는 알고 있어야 한다)
4. 어플리케이션이 policy에 허락되지 않는 무언가를 하려하면, SELinux는 그 행위를 막는다.
5. 어플리케이션이 policy에 의해 허락된 무언가를 실행하면, SELinux는 고의적이던 아니던 데미지를 입을 가능성이 있다. 예를 들어 한 어플리케이션이 모든 파일이나 데이터베이스를 삭제할 권한을 가지고 있다면, 바이러스나 나쁜 유저가 그 권한을 획득했을 때, 같은 행위를 저질러버릴 수 있다. 그러나 좋은 소식은 policy가 어플리케이션과 데이터를 세밀하게 제어했을 경우, 모든 데이터는 안전할 수 있다.
6. 로그인 세션은 그들의 도메일에 속할 수 있다. 이것은 오직 그들이 실행하는데 필요로하는 권한만을 그들에게 주어질 수 있다.(즉, admin이나 sales 스탭이냐, HR이냐에 따라 다르게 권한을 줄 수 있다). 이 점은 데이터의 데미지를 최소화로 제한할 수 있다.
7. X-Windows같은 어떤 어플리케이션은 일반적으로 모든 data에 관해 접근을 원하기 때문에 권한을 세밀하게 주기가 어려울 수도 있다. SELinux는 sandboxing 서비스를 이용하여 그와같은 문제를 해결할 수 있다.
8. SELinux는 메모리 릭이나 버퍼 오버런과 같은 문제를 멈출 수는 없다.(왜냐하는 SELinux는 그 문제를 해결하기 위해 만들어지지 않았기 때문). 하지만 그 문제를 작게 억제할 수는 있다.
9. SELinux는 모든 virus나 malware를 막을 수는 없다.(왜냐하면 합법적인 일반 유저에 의한 virus/malware 설치도 매우 다양하게 나타나기 때문이다). 그러나 그것들이 가져올 데미지의 범위를 제한할 수는 있다.
10. SELinux는 커널 약점을 극복할 수는 없다. 하지만 그 약점에 의한 피해를 제한할 수는 있다.
11. 유저가 관련 권한을 가지고 있다면, audit2allow와 같은 툴로 SELinux policy를 추가하는 것은 매우 쉽다. 그러나 권한을 추가한다는 것은 security hole을 만들 수도 있다는 사실을 기억해야 하고, 그래서 추가할 rule이 정말로 필요한 것인가는 정확히 알아야 한다.
12. 마지막으로, SELinux는 security policy에 의해 허락된 어떤 것도 막을 수 없다. 따라서 policy의 정확하고 좋은 디자인이 중요하다.

다음은 SELinux과 관해 유용한 연습을 제공해 줄 수 있다.

• Apache 버서와 SELinux에 관한 토론은 처음엔 부정적으로 보일 수 있다. 하지만 어떤 점을 억제할 것인가는 중요한 포인트인다. 그것에 대한 초기 스터디는 다음을 참고 http://blog.ptsecurity.com/2012/08/selinux-in-practice-dvwa-test.html, 이것은 그 스터디에 관한 결과 http://danwalsh.livejournal.com/56760.html.

하지만 좋은 policy 디자인과 알려져있는 보안목표들(?)로인해 SELinux ' Apache / SELinux Plus' 서비스는 많은 보안 웹서비스를 빌드하는데 사용되어 질 수 있다(?) (http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus).

• SELinux는 SEAndroid란 이름으로 Android에 포함되어져 왔다. 아래 프리젠테이션은 SELinux가 극복할 수 있는 Android의 취약점에 관한 use-case를 제공해준다 (https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_smalley.pdf)

중요 SELinux의 구성요소들

High Level Core SELinux Component(http://taiga.selinuxproject.org/~rhaines/diagrams/1-core.png)는 SELinux의 중요 구성요소들에 관한 상위 단계에서의 관점이다. 그 구성요소들은 다음과 같이 policy의 강제를 제어한다. 

1. subject는 objec에 의해 획득되는 행위를 일이킨다???? (subject가 포함되었을 때, 파일을 읽는 것과 같은 것..???)
2. Object Manager는 파일과 같은 특정한 자원을 필요로하는 액션을 알고있고, policy rule에 의해 그 액션을 제어할 수 있다.
3. Security Server는 policy rule에 의해 object에 요청되는 action이 수행될 권한이 subject에 있는지 결정한다.
4. Security Policy는 SELinux Policy Language(http://selinuxproject.org/page/PolicyLanguage)에 따라 쓰여진다. 
5. Access Vector Cache(AVC)는 security server의 결정을 캐쉬함으로써 시스템의 성능을 높인다.

High Level SELinux Architecture(http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png)는 SELinux 환경에서 사용되는 더욱 복잡한 커널/유저스페이스/다양한 서비스 지원에 관한 view를 보여준다. 이 그림은 SELinux를 설명할때 여러번 참조될 것이다.

• 현대 SELinux의 구현상으로는, security server는 userspace에서 로딩되는 policy과 함께 커널 안에 있다. 또한 policy 로딩은 libselinux 라이브러리안에 포함된 다양한 함수에 의해 로딩된다.

Object Manager(OM) 과 Access Vetor Cache (AVC)는 다음과 같은 곳에 있다.

Kernel Space. Object Manager들은 파일/디렉토리/소켓/IPC와 같은 커널 서비스를 위해 존재하고, Linux Security Module(LSM)을 이용하는 SELinux sub-system에 있는 hook에 의해 제공된다. LSM은 LSM 섹션(http://selinuxproject.org/page/NB_LSM)에서 따로 기술될 것이다. SELinux 커널 AVC 서비스는 security server가 커널의 object manager들에게 응답하는 것을 캐쉬한다. 그러므로 향후에 있을 같은 요청에 빠르게 접근 결정을 내릴 수 있게 된다.

• userspace. object manager들은 MAC를 지원하기 위해 application 또는 서비스들로 이루어져 있고, 그것들은 "SELinux aware" 어플리케이션 또는 서비스라고 불리운다. 예를 들어 X-Windows, Gnome desktop에서 사용되는 D-bus messaging, PostgreSQL database, Name Service Cache Daemon(nscd) 그리고 GNU/Linux passwd 명령어들이 그것이다. 일반적으로 이 OM들은 SELinux library (libselinux)안에 있는 AVC 서비스를 사용한다. 그러나 그들은 AVC를 전혀 이용하지 않거나 그들의 AVC를 ???? 뭔말이냐....

• 그림의 오른쪽에 있는 SELinux security policy와 그 설정 파일들은 /etc/selinux 디렉토리 안에 있다. 이 디렉토리는 주요 SELinux 설정 파일(config)을 가지고 있고, 그 설정 파일은 로드될 policy의 이름들과 policy 로딩시의 초기 enforcement를 어떻게 할것인지에 대한 정보를 가지고 있다(SELINUX entry를 통하여..). /etc/selinux/<SELINUXTYPE> 디렉토리는 설정파일들과 함께 동작되어질 policy들을 가지고 있다 (즉, SELINUXTYPE=targeted라고 설정되면 설정파일들은 /etc/selinux/targeted에 저장된다.). 알려진 모든 설정파일들은 요 섹센(http://selinuxproject.org/page/ConfigurationFiles)에서 자세히 알 수 있다.
• SELinux는 "modular policy"를 지원한다. 즉, policy들은 한개의 커다란 policy 소스로 이루어져 있지 않고 모듈들 안에 있다는 뜻이다. modular policy는 중요한 정보(object classe들, permission 등..)를 가지고 있는 base policy와 각각의 어플리케이션 또는 서비스를 지원하는 0개 이상의 policy module로 이루어져 있다. 그 module들은 컴파일되고 링크되어 "policy store"에 저장되는데, "policy store"는 binary 형식으로 만들어져서 security server에 로딩되게 된다(그림으로는 binary policy가 /etc/selinux/targeted/policy/policy.26에 있다). policy의 종류와 그 구성은 은 요 섹선(http://selinuxproject.org/page/NB_PolicyType)에 설명되어 있다. 
• 처음 policy를 빌드하기 위해서는, policy 소스(그림의 왼쪽 위)가 필요하다. 이것은 두 가지 방법이 제공된다(세번째 방법은 CIL(Common Intermediate Language)란 개발이 끝나면 가능하다)
• SELinux Policy Language로 작성된 소스코드(http://selinuxproject.org/page/PolicyLanguage)로 부터 생성. 여기에 이 notebook에 나온 예제들이 쓰여졌는지에 관해 나와있다. 그러나 실제 policy에서는 이 예제 policy를 사용하지 말기를 권한다
• policy rule들은 정의하는데 높은 수준의 macro를 사용한 레퍼런스 policy를 이용한다. 이것은 현재 Red Hat과 Debian과 같은 SELinux 배포판들에 들어가있는 표준 방법의 policy들이다. 레퍼런스 policy는 여기에 설명되어 있다(http://selinuxproject.org/page/NB_RefPolicy)
• 소스 코드를 컴파일하고 링크고 그것을 security server로 적재하기 위해서는 다수의 tool들이 필요하다(그림의 상단에 나와있음). 그것들은 샘플 policy module을 빌드하는데 사용된다.
• policy를 관리하기 위해 시스템 관리자 권한을 enable시키려면, SELinux 환경과 Label file system은 tool들과 수정된 GNU/Linux 명령어들을 필요로 한다.
• security 이벤트가 로깅되는 것을 확신하기 위해서, GNU/Linux는 policy 위반을 적재하는 audit server를 가지고 있다. 요기서(http://selinuxproject.org/page/NB_AL) 그 security 이벤트들의 형식을 기술하고 있다.
• SELinux는 네트웤 서비스도 지원한다(http://selinuxproject.org/page/NB_Networking)

Linux Security Module and SELinux 섹션에서는 LSM/SELinux에 관해 더 자세히 들여다 본다