커널쪽 컴파일 하면서 많은 mk 파일들로 꼬여서 알수 없는 에러가 발생하는데
그럴 때는 파일을 하나에 여러 옵션을 적어주어 필요 없는 파일을 줄임으로서
해결이 가능하다.
포팅 후에는 대부분 labeling 작업과 policy 작업이다.
파일 시스템이 만들어 질 때 labeling은 file_contexts를 잘 정의하면 되고
정의가 되었는데도 제대로 레이블링이 안될 때에는 init.rc에 restorecon을
이용한다. boot 전이라면 recovery쪽 시작 파일들을 점검해서 다시 레이블링을 해
주어야 한다.
system running 상황에서는 패키지 매니저에서
인스톨 타임 때 제대로 레이블링을 못하거나
키 값이 등록이 되어 있지 않는 경우가 있다.
패키지 매니저와 연관된 부분을 건들지 않으면 프레임웍쪽 selinux feature는
문제를 일으킬 소지가 없다. 키 값은 apk에서 뽑아서 등록해 주면 된다.
모든 라벨링이 된 상태에서는 allow rule을 정하는 것이 일이다.
allow rule은 안드로이드 시스템에 정통한 1명이 만드는 것이 바람직 하다.
그 외에는
로그를 정리해 주는 사람이 따로 있어야 하고 SEAndroid로 막을 수 있는
보안 관련 부분을 조언해 주는 사람도 필요하다.
회사에서 관련일을 하면서 여러가지 엉뚱한 경우가 있었는데
1. SELinux를 너무 만만하게 보고 마켓 앱을 무작정 받아서 관련 룰만 열어주는 실수.
2. 관계 부처에 탑재 사실을 알지 지도 않아서 3일 이상 부서 전체가 해당 모듈 이상점을
분석했더니 결국 SELinx 문제.
3. 모듈에 대한 파악이 제대로 되지도 않은 상황에서 새로운 관련 모듈 탑재.
4. 그 모듈들이 보안에 위배 되지는 나중에 밝혀지는데도 별다른 대책이 없는.
기타 여러가지 상황들을 보고 또 관련해서 직언을 서슴치 않았지만.
대한민국 관리자드은 엔지니어들이 하는 말을 조금만 듣고 나면 자신이 설계자가
된양 행동하는 행동거지 때문에 삐뚤삐뚤 쌓아올려진 소프트웨어는 나중에 결국
무너지고 만다.
그러나 어느 정도 실패를 경험하고 나면 다시 처음으로 돌아와서 loose한 룰을
만들고 필요없는 모듈은 넣지 않는 등의 행동들을 하지만. 책임 소재는 없다.
적어도 자신이 밀고 나간게 삐뚤어 졌으면 책임 정도는 져야 하는데.
그래서 생각했다. 아 이 회사에서는 저 정도는 년차 동안은
회사 생활을 할 수 있겠구나 하고.
댓글 없음:
댓글 쓰기
국정원의 댓글 공작을 지탄합니다.