내 블로그다

cut -d: -f5 /etc/passwd | sort | uniq -c

초보자를 위한 unix에서 따옴

sort 옵션

-b: 앞에 붙은 공백 무시

-d: 사전순으로 정렬

-f: 단어의 대소문자 무시

-n: 산술적인 순서로 정렬

-r: 정렬 순서를 역순으로

초보자를 위한 Unix에서 따옴

원격에서 작업하다 보면 여러창을 보고 싶을때가 많습니다.

이럴때 보통 여러개의 터미널을 띄워서 사용 합니다.

그런데 창을 여러개 띄우고 왔다 갔다 하려다 보면 클릭하기도 귀찮고 헤깔리기도 하죠.. 후후.

이럴때 screen 명령을 사용 해보면 많은 도움이 될것입니다.

screen 은 한 터미널로 한번만 로그인 한후에 여러 쉘과 프로그램을 사용할 수 있습니다.

또한 세션관리 기능도 지원 한답니다.

그래서 screen 을 종료하고 심지어 터미널까지 로그아웃하고 종료 하여도 세션이 유지 되고 있습니다.

다음에 다시 터미널로 로그인후 screen으로 세션을 불러와서 다시 이전 작업을 이어서 할 수 있습니다.

nohup 으로 프로그램을 실행 시킬 필요도 없겠죠.. 훗..

이제 nohup 은 꼭 필요 할때만 사용하시고 screen 을 애용해보면 어떨까요..?. 하하.

또한 문서작업이나 텍스트 작업 프로그래밍 작업시 screen 과 vim을 함께 사용하면 좋은 궁합이 될것입니다.

여러분도 꼭 한번 사용 해보시라고 권해 봅니다.

(참고 : screen 은 일종의 가상 터미널 내지는 가상 콘솔이라고 보면 될 것 같습니다.)

그럼 screen 명령에 대한 설명을 시작 합니다.

1. 쉘모드 명령어

  screen

   : screen 을 시작 하는 기본 명령입니다.

   : 기본 세션명으로 시작합니다.

  screen -S 세션명

   : -S 다음에 주는 세션명으로 시작합니다.

  screen -list

   : -list 옵션을 주고 실행하면 이전에 작업했었던 screen 리스트가 있으면 세션명과 함께 리스트를 보여줍니다.

  screen -R 세션명

   : 이전에 세션이 있을 경우 -R 다음에 오는 세션명으로 이전 작업을 불러옵니다.

   : -R 다음에 세션명을 주지 않았을 경우에는 이전 세션이 한개만 있을 경우 그 작업을 불러옵니다.

   : 이전 작업이 여러개 있을 경우에는 이전 작업 리스트를 보여줍니다.

   : 이 경우에는 원하는 세션명을 주고 시작 하면 되겠죠. ^__^

2. screen 실행후 명령어

  screen 실행후의 명령어는 Ctrl-a로 시작합니다:

Ctrl-a, c       : (create) 새로운 쉘이 생기면서 그 쉘로 이동

Ctrl-a, a       : 바로 전 창으로 이동

Ctrl-a, n       : (next) 다음 창으로 이동

Ctrl-a, p       : (previous) 이전 창으로 이동

Ctrl-a, 숫자    : 숫자에 해당하는 창으로 이동

Ctrl-a, '       : 창번호 또는 창이름으로 이동 ( ' => 싱글 쿼테이션 )

Ctrl-a, "       : 창번호를 보여준다. ( " => 더블 쿼테이션 )

Ctrl-a, A       : 현재 창의 title을 수정

Ctrl-a, w       : 창 리스트 보여주기

Ctrl-a, esc     : Copy 모드로 전환. Copy 모드에서는 vi의 이동키로 이동을 할 수 있다.

Crtl-a, [         커서 이동을 할 수 있고 특정 블럭을 복사하는 기능으로 사용한다.

                 먼저 시작 위치에서 space 바를 누르고 끝 위치에서 space 바를 누르면 해당 부분이 buffer로 복사된다.

Ctrl-a, ]       : buffer의 내용을 stdin으로 쏟아 넣는다.

                 이 기능은 vi의 입력모드에서 사용하면 유용하다.

Ctrl-a, :(콜론) : 명령행 모드로 전환

Ctrl-a, d       : (detach) 현재 작업을 유지하면서 screen 세션에서 빠져나옴

                 세션이 종료 되지 않습니다.

Ctrl-a, x       : lock screen

아래 부분은 창을 나눠서 사용하는 명령입니다.

Ctrl-a, S       : (split) 창을 나눔 (region)

Ctrl-a, Tab     : 다른 region으로 이동

Ctrl-a, Q       : 현재 region을 제외한 나머지 숨기기

그리고 마지막 명령으로 세션을 완전히 빠져 나오는 명령입니다.

exit : screen 의 쉘상에서 exit 를 치고 엔터를 하면 세션이 완전히 종료 됩니다.

이상 위의 명령어 들만 알고 있으면 screen 사용시 불편하지 않게 screen 을 사용 할 수 있을 겁니다.

참 고

다른 사용자 분들의 의견을 보면 screen 화면을 2, 3 개정도 띄우고 사용하는게 가장 적당하다고 합니다.

4개 이상 띄우고 사용하다보면 불편하다고 하네요.

여러분들은 어느정도가 적당한지 한번 사용해보시고 판단 하시기 바랍니다.

기타 더욱 자세한 내용을 아시고 싶으시면 man 페이지나 /usr/doc/screen 을 참고하시기 바랍니다. 

참고 : KLTP( http://kltp.kldp.org/ )

      리눅스 사랑넷 ( http://linux-sarang.net )

작성 : 이우정

[출처] [리눅스] screen 사용법|작성자 내생애마지막다이어트

http://calmroad.blog.me/100134061027

http://blog.naver.com/powerhw?Redirect=Log&logNo=80122288366

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 섹션을 보라)

소개

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에 관해 더 자세히 들여다 본다

sudo adduser givenname.family –force-badname

또는 

sudo adduser username

관리자 권한 추가

sudo gpasswd -a username admin

adduser와 useradd는 다르다. 차이점은 까먹음. 인터넷 뒤지면 나오겠지

[옵션]

출처: 초보자를 위한 UNIX

[사용 예]

AND 조건

find . -name "찾는파일명*" | xargs grep '찾는 문자열1'  |  grep '찾는 문자열2'

OR 조건

find . -name "찾는파일명*" | xargs grep '찾는 문자열1'  OR  grep '찾는 문자열2'

find . | xargs egrep 'aaa|ddd'  (AIX)

find . | xargs grep 'aaa\|ddd' (Linux)

출처:http://blog.naver.com/dodo7777?Redirect=Log&logNo=90040225445

find 의 -perm 옵션은 보통 3가지 mode 를 사용합니다.

-perm mode

-perm -mode

-perm /mode

 mode 는 정확하게 mode 가 매치되는 것만

-mode 는 mode 를 포함하고, 추가적인 퍼미션이 있는 것만

/mode 는 mode 에서 한개 bit라도 매치되는 것이 있으면

아래의 예들을 실행해 보시면 이해에 도움이 되실 겁니다.

하나의 임시 디렉토리 속에 아래 명령으로 모든 가능한 퍼미션을 만들고 테스트 해보세요.

for i in $(seq 0 7); do for j in $(seq 0 7); do for k in $(seq 0 7); do  touch ${i}${j}${k}; chmod ${i}${j}${k} ${i}${j}${k}; done; done; done

아래는 서로 결과가 같고, 퍼미션이 0700인 것만 찾습니다.

find . -perm u rwx

find . -perm u=rwx

find . -perm 0700

find . -perm 700

아래는 서로 결과가 같고, 퍼미션이 0020인 것만 찾습니다.

find . -perm g w

find . -perm g=w

find . -perm 0020

find . -perm 020

find . -perm 20

아래는 서로 결과가 같고, 퍼미션이 0500 보다 더 많이 허용된 것을 찾습니다.

find . -perm -u rx

find . -perm -u=rx

find . -perm -0500

find . -perm -500

아래는 서로 결과가 같고, 퍼미션 0771 의 각 권한(rwxrwxrwx) 중 한 개 이상의 권한이 같은 것을 찾습니다.

find . -perm /u rwx,g rwx,o x

find . -perm /u=rwx,g=rwx,o=x

find . -perm /u=rwx,g=rwx,o x

find . -perm /0771

find . -perm /771

아래와 같이 !을 붙일 때 찾을 수 있는 퍼미션의 예상은

find . ! -perm /u rwx,g rwx,o x -ls

-------rw-

--------w-

----------

-------r--

입니다.

참조하세요 ^^

추가질문에 대한 답변

 -perm -2 -o -perm -20 

-o 는 or 의 의미입니다.

-perm -2 또는 -perm -20 입니다.

other 가 writable 이상이거나 또는 group 이 writable 이상인 것을 의미합니다.

즉, other 또는 group 에 실행권한이 있는 파일을 의미합니다.

같은 의미지만 반대로 이야기 하면, 실행권한이 user 에게만 있거나 아예 없는 파일을 제외한 파일을 의미합니다.

만약,

find ../ ! -user mylin \( -perm 2 -o -perm -20 \) -exec {} \; 이라면

상위 디렉토리의 하위로 소유자가 user가 아니고 other나 group 에 실행권한이 있는 파일을 찾아서 실행한다

는 의미가 됩니다.

해당 글은 지식스폰서가 활동 기간 (04년~08년 6월 종료)중에 작성한 글 입니다.

지식스폰서가 작성한 답변은 본문 내 자기소개 및 출처란의 실명, 상호명, URL표시를 허용합니다.

출처란에 표시된 정보가 지식iN 운영원칙에 위배되는 음란성, 불법성, 청소년 유해사이트 등으로 변질된 경우는 허용이 되지 않습니다.

*.sh 파일에서 choosecombo 문자열 찾기

find -name '*.sh' -print | xargs grep 'choosecombo' $1

다양한 파일 찾기 옵션

-name

-user

-group

-perm

퍼미션으로 찾기

ex) find -perm 777 

맨뒤에 -ls

 -size n  or -size -nc 

파일 크기로 찾기

ex) find -size -100

ex) find -size  1000c

같은 옵션 중복 사용가능

ex)find -size  50 -size -100

2>/dev/null/

권한없는 것들 출력안하기

[출처] 리눅스 파일 찾기 옵션2(유용한 옵션 편)|작성자 polpoipol

http://tksssch29.tistory.com/search/selinux

http://www.centos.org/docs/5/html/Deployment_Guide-en-US/index.html

http://www.linuxtopia.org/online_books/getting_started_with_SELinux/

http://www.linuxtopia.org/online_books/writing_SELinux_policy_guide/index.html

http://selinuxproject.org/page/Main_Page

http://www.freetechbooks.com/the-selinux-notebook-the-foundations-t785.html

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/

좋다!!

• sudo vim /etc/udev/rules.d/70-android.rules
• 다음을 입력
• SUBSYSTEMS==“usb”, ATTRS{idVendor}==“1004”, ATTRS{idProduct}==“61fc”, MODE=“0666”
• (idVendor와 idProduct는 lsusb 명령어로 확인할 수 있음)
• sudo chmod a r /etc/udev/rules.d/70-android.rules
• usb 뺐다 꼽고, adb devices 치면 인식됨이 보인다

1. 필요 tools: vim, ctags, cscope

2. 손볼 files: ~/.vimrc, ~/.vim/plugin/cscope_maps.vim(이건 web에서 download), /usr/bin/mkcscope.sh

2. 설치: (sudo) apt-get install vim, ctags, cscope(또는 (sudo) yum install vim, ctags, cscope)

3. setup

 3.1. ctags setup

       source code가 있는 project folder로 이동하여 다음의 command 입력

       -> ctags *(현재 directory의 모든 소스의 tags 정보 만들기)

       -> ctags -R(현재 directory의 하위 모든 소스에 대해 tags 정보 만들기. 두번째 것만 해 줘도 될 것 같다.)

       .vimrc 파일에 tags 설정

       -> vi ~/.vimrc

       -> 'set tags=SOURCE_DIR/tags' 입력, wirte&quit

 3.2. cscope setup

       /usr/bin director 밑에 mkcscope.sh파일을 만든다.('chmod 755 mkcscope.sh'로 permission change)

       mkcscope.sh 파일에 아래 내용 추가

       =============== mkcscope.sh script ================

       #!/bin/sh

       rm -rf cscope.out cscope.files

       find ./ -name '*.c' -o -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.s' -o -name '*.S' > cscope.files

       cscope -i cscope.fils

       ===================================================

       위 script는 간단하게 현재 하위 파일의 모든 파일 중에서 *.c, *.cpp, *.cc, *.h, *.s, *.S 등 cscope로 분석 가능한

       소스 파일들을 찾아서 cscope.files라는 list 파일을 만든 후에 cscope -i cscope.files를 실행해서 cscope.out database를

       생성하는 script이다.

       -> cd SOURCE_DIR

       -> mkcscope.sh

       Database 파일(cscope.out) build가 끝나면 Ctrl d 키로 빠져나옴.

 3.3. vim setup

       ~/.vimrc file에 아래 set values 추가

       ================== cscope setting ==================

       set csprg=/usr/bin/cscope

       set csto=0

       set cst

       set nocsverb

       if filereadable("./cscope.out")

       cs add cscope.out

       else

       cs add SOURCE_DIR/cscope.out

       endif

       set csverb

       =====================================================

설정 끝.

4. Usage

 4.1. vim 실행 후 source 내에서 symbol 찾기

      - 찾으려고 하는 symbol위에서 'Ctrl \,s'(Ctrl 역슬레쉬 입력하고 그냥 s)를 입력하면 symbol로 빠르게 이동하거나 리스트가 보여짐. 

      - 리스트가 보여질 경우 number key로 선택

      - Ctrl t 하면 이전 line으로 back

      - Symbol 위에서 'Ctrl-spacebar s'하면 vim 창을 분활하여 symbol로 이동(입력기에서 'Ctrl space'가 입력 모드 전환으로 설정되어 있으면 

      - 당연히 안되고 한글을 쓰려고 하니, 입력기에서 'Ctrl space'를 삭제. 한글키가 먹어줌으로 필요 없음)

 4.2. vim command line에서 찾기 명령어

      - cscope 명령어 사용(or cs로 typing)

         ex) :cs(cope) f(ind) [querytype] STRING

               * querytype

                  s: symbol

                  g: definition

                  d: function called by this function

                  c: function calling this function

                   t: text

                   f: this file

                   i: include file

      - cscope 명령 대신 scscope(or scs)를 사용하면 가로로 창이 분할되어 symbole을 찾음.

[출처] ctags, cscope 설치 및 사용법|작성자 노랑무우

===================================================================

vimrc 설정

===================================================================

"cscope 설정

set csto=0

set cst

set nocsverb

if filereadable("./cscope.out")

 cs add cscope.out

else 

 cs add /usr/src/linux/cscope.out

endif

set csverb

"tag list

"set tags =/work/android/tags

set tagbsearch

===================================================================

redo: ctrl + r

undo: u

* smbclient //ip/jinnydown

* 서비스 확인

   # smbclient -L //ip -I ip -U smbuser

* 접속

   # smbclient //ip/public -I ip -U smbuser

$ sudo smbpasswd -a userID (ex. sudo smbpasswd -a jinnydown)

:%s/old/new/g

%s: substitute

g globally (파일 전체에서)

출처: http://overegoz.tistory.com/659