-a Automatically repair the file system. No user intervention is
necessary. Whenever there is more than one method to solve a
problem, the least destructive approach is used.
-A Use Atari variation of the MS-DOS filesystem. This is default if
dosfsck is run on an Atari, then this option turns off Atari
format. There are some minor differences in Atari format: Some
boot sector fields are interpreted slightly different, and the
special FAT entries for end-of-file and bad cluster can be dif-
ferent. Under MS-DOS 0xfff8 is used for EOF and Atari employs
0xffff by default, but both systems recognize all values from
0xfff8...0xffff as end-of-file. MS-DOS uses only 0xfff7 for bad
clusters, where on Atari values 0xfff0...0xfff7 are for this
purpose (but the standard value is still 0xfff7).
-d Drop the specified file. If more that one file with that name
exists, the first one is dropped.
-f Salvage unused cluster chains to files. By default, unused clus-
ters are added to the free disk space except in auto mode (-a).
-l List path names of files being processed.
-r Interactively repair the file system. The user is asked for
advice whenever there is more than one approach to fix an incon-
sistency. This is the default behaviour.
-t Mark unreadable clusters as bad.
-u Try to undelete the specified file. dosfsck tries to allocate a
chain of contiguous unallocated clusters beginning with the
start cluster of the undeleted file.
-v Verbose mode. Generates slightly more output.
-V Perform a verification pass. The file system check is repeated
after the first run. The second pass should never report any
fixable errors. It may take considerably longer than the first
pass, because the first pass may have generated long list of
modifications that have to be scanned for each disk read.
-w Write changes to disk immediately.
-y Same as -a (automatically repair filesystem) for compatibility
with other fsck tools.
If -a and -r are absent, the file system is only checked, but not
repaired.
- 삼성의 경우 S6, S6 edge 단말에서 안드로이드 5.1 이상부터 적용 예정('15.6 ~ '15.7)
3가지 모드 지원
1. Guest mode
- 정보 및 데이터는 세션이 유지되는 동안 일시적으로 저장됨
- LG G플렉스, 및 G2, G3 모델의 4.x 버전에서 이미 Guest 모드 지원
(G4의 경우 통신사에 따라 지원 여부 달라짐)
2. Profile mode
- APP 과 Service 접근 제한 가능
- 아이들에게 핸드폰을 빌려줄 때 과금 위험 서비스나, 숨기고 싶은 app에 제한을 둠으로 보호 가능
3. User mode
- 모든 app과 서비스 제공
- 새로운 google id를 추가함으로 main user와 별개로 서비스 가능
(예를 들어 pc에 usb를 연결할 경우, 해당 로그인 된 정보만 출력 가능)
multi-user 특징
1. The Owner라 불리는 main user는 새로운 user를 만들고 수정하고, 지울 수 있다.
(create, edit, remove)
The Owner -------------> user1, user2, user3
2. User를 생성할 때 unrestricted, restricted를 설정할 수 있다.
(restricted user의 경우 허용된 app에만 접근 가능)
3. User들 간의 데이터는 분리되어 서로의 데이터를 보지 못한다.
4. OS의 setting은 분리 될 수 있고 공유 할 수도 있다.
5. 하나의 User만 화면에 활성화 할 수 있지만 3개의 다른 user까지 동시에 background로 프로세스 실행 가능
(예를 들어 email과 같은 경우 background로 계속 실행하게끔 할 수 있음)
생성 원리
- OS 레벨에서 다음과 같이 변경사항이 구현됨
- Sandboxing에 이용되는 appId와 사용자 id가 생성되는 데 이를 각각 appId, userId라고 부른다.
- userID
00: Device Owner
-10000: null user
<nn>: secondary userID로 만약 main user 이외 User1이 생성된다면 userId는 10을 갖게 되고 User2는 11로 생성
User의 list는 /data/system/users/userlist.xml에 저장됨
- appId와 userId를 연결하여 sandbox를 허용할 수 있는 UnixUID를 얻을 수 있으며, 이를 통해 메모리, 프로세스, 저장공간을 분리할 수 있다.
예를 들어 Owner와 User1이 있다고 가정했을 때, 같은 앱을 실행한다고 가정한다. appID는 12345일 때 Owner process UID의 경우 0012345가 되고 User1의 경우 1012345를 갖게 된다. 그러므로 app은 독립적인 메모리와 process를 갖게 된다.
- 각각의 설치된 app의 정보는 /data/user/userID/packageName에 저장이 되지만 apk는 여전히 /data/app에 유지
보안 관점에서 봤을 때의 multi-user mode
1. Secondary user의 앱과 설정 우회 가능
- Owner는 새롭게 추가되는 User의 app접근이나 OS setting을 제한할 수 있지만 이것에 대한 추가적인 안정장치 없음
app의 경우 XML file에 app list를 추가함으로 app을 숨기는 데 수정할 경우 숨김 app을 볼 수 있음
제한 설정 같은 경우 Setting app 자체적으로 메뉴항목을 숨김. 그러나 VPN setting이나 mobile data setting, backup 등의 setting 숨김을 우회하는 방법이 있음. 이를 막을 수 있는 통합 프레임워크 메커니즘이 없음
Wi-Fi의 문제가 있는데 User1이 악의적인 AP를 통해 모든 데이터를 가로챌 수 있도록 구성 가능
2. Background tasks 활용
- User1의 app을 background로 실행시켜놓고 Owner가 단말을 사용할 때 알아차리기 힘듦
악의적으로 User1이 background에서 악성 app을 실행시켰을 때 Owner 사용자는 위치 정보, key logging 등의 공격을 받을 수 있음
(휴대폰을 종료하기 전까지 프로세스는 계속 돌 수 있으며 immortal 악성 app 또한 가능함)
3. 공유된 app code 활용
- 위의 생성원리에서 app code는 공유된다고 하였는데 이를 통해 악의적 행동 가능
Owner의 설정에서 알 수 없는 출처의 앱 다운로드 금지를 하였더라도 User1에서는 기능 해제 후, 다운로드 했을 때 app code는 공유 됨 -> 기본적으로 android는 sandbox에 설치된 동일한 개발자에 대해 permission을 공유함
