CAPABILITIES

名前

説明

バージョン 2.2 以降の Linux では、 これまでスーパーユーザに結び付けられてきた権限を、 いくつかのグループに分割している。これらのグループは ケーパビリティ(capability) と呼ばれ、グループ毎に独立に有効、無効を設定できる。 ケーパビリティはスレッド単位の属性である。  

ケーパビリティのリスト

CAP_AUDIT_CONTROL (Linux 2.6.11 以降)

カーネル監査 (audit) の有効無効の切り替え、 監査のフィルタ・ルールの変更、 監査の状況やフィルタ・ルールの取得ができる。

CAP_AUDIT_WRITE (Linux 2.6.11 以降)

カーネル監査のログにレコードを書き込む。

CAP_CHOWN

ファイルの UID とGID を任意に変更する (chown(2) 参照)。

CAP_DAC_OVERRIDE

ファイルの読み出し、書き込み、実行の権限チェックをバイパスする (DAC は "discretionary access control (任意のアクセス制御)" の略である)。

CAP_DAC_READ_SEARCH

ファイルの読み出し権限のチェックとディレクトリの読み出しと実行 の権限チェックをバイパスする。

CAP_FOWNER

*

通常、プロセスのファイルシステム UID がファイルの UID に一致することが 要求される操作 (例えば chmod(2), utime(2)) における権限チェックをバイパスする。 但し、 CAP_DAC_OVERRIDE か CAP_DAC_READ_SEARCH によりチェックが行われる操作は除く。

*

任意のファイルに対して拡張ファイル属性を設定する (chattr(1) 参照)。

*

任意のファイルに対してアクセス制御リスト (ACL) を設定する。

*

ファイルの削除の際にディレクトリのスティッキービットを無視する。

*

open(2) や fcntl(2) で任意のファイルに対して O_NOATIME を指定する。

CAP_FSETID

ファイルが変更されたときに set-user-ID とset-group-ID の許可ビットをクリア しない。呼び出し元プロセスのファイルシステム GID と追加の GID のいずれとも GID が一致しないファイルに対して set-group-ID ビットを設定する。

CAP_IPC_LOCK

メモリーのロック (mlock(2), mlockall(2), mmap(2), shmctl(2)) を行う。

CAP_IPC_OWNER

System V IPC オブジェクトに対する操作に関して権限チェックをバイパスする。

CAP_KILL

シグナルを送信する際に権限チェックをバイパスする (kill(2) 参照)。これには ioctl(2) の KDSIGACCEPT 操作の使用も含まれる。

CAP_LEASE (Linux 2.4 以降)

任意のファイルに対して ファイルリースを設定する (fcntl(2) 参照)。

CAP_LINUX_IMMUTABLE

拡張ファイル属性 FS_APPEND_FL と FS_IMMUTABLE_FL を設定する (chattr(1) 参照)。

CAP_MAC_ADMIN (Linux 2.6.25 以降)

強制アクセス制御 (MAC) を上書きする。 Smack Linux Security Module (LSM) 用に実装されている。

CAP_MAC_OVERRIDE (Linux 2.6.25 以降)

MAC の設定や状態を変更する。 Smack LSM 用に実装されている。

CAP_MKNOD (Linux 2.4 以降)

(Linux 2.4 以降) mknod(2) を使用してスペシャル・ファイルを作成する。

CAP_NET_ADMIN

各種のネットワーク関連の操作を実行する。 (例えば、特権が必要なソケットオプションを設定する、マルチキャストを有効にする、 インターフェースを設定する、ルーティングテーブルを変更するなど)

CAP_NET_BIND_SERVICE

インターネットドメインの特権ポート (ポート番号が 1024 番未満) をバインドできる。

CAP_NET_BROADCAST

(未使用) ソケットのブロードキャストと、マルチキャストの待ち受けを行う。

CAP_NET_RAW

RAW ソケットと PACKET ソケットを使用する。

CAP_SETGID

プロセスの GID と追加の GID リストに対する任意の操作を行う。 Unix ドメインソケット経由でソケットの資格情報 (credential) を渡す際に 偽の GID を渡すことができる。

CAP_SETFCAP (Linux 2.6.24 以降)

ファイルケーパビリティを設定する。

CAP_SETPCAP

ファイルケーパビリティがサポートされていない場合: 呼び出し元が許可されているケーパビリティセットに含まれる任意のケーパビリティを、 他のプロセスに付与したり、削除したりできる。 (カーネルがファイルケーパビリティをサポートしている場合、 CAP_SETPCAP はこの役割を持たない。 なぜなら、ファイルケーパビリティをサポートしているカーネルでは CAP_SETPCAP は全く別の意味を持つからである。)

ファイルケーパビリティがサポートされている場合: 呼び出し元スレッドのバウンディングセットの任意のケーパビリティを 自身の継承可能ケーパビリティセットに追加できる。 (prctl(2) PR_CAPBSET_DROP を使って) バウンディングセットからケーパビリティを削除できる。 securebits フラグを変更できる。

CAP_SETUID

プロセスの UID に対する任意の操作 (setuid(2), setreuid(2), setresuid(2), setfsuid(2)) を行う。 Unix ドメインソケット経由でソケットの資格情報 (credential) を渡す際に 偽の UID を渡すことができる。

CAP_SYS_ADMIN

*

以下のシステム管理用の操作を実行する: quotactl(2), mount(2), umount(2), swapon(2), swapoff(2), sethostname(2), setdomainname(2).

*

任意の System V IPC オブジェクトに対する IPC_SET と IPC_RMID 操作を実行する。

*

拡張属性 trusted と security に対する操作を実行する (attr(5) 参照)。

*

lookup_dcookie(2) を呼び出す。

*

ioprio_set(2) を使って I/O スケジューリングクラス IOPRIO_CLASS_RT, IOPRIO_CLASS_IDLE を割り当てる (IOPRIO_CLASS_IDLE は Linux 2.6.25 より前のバージョンのみ)。

*

ソケットの資格情報 (credential) を渡す際に偽の UID を渡す。

*

ファイルをオープンするシステムコール (例えば accept(2), execve(2), open(2), pipe(2)) でシステム全体でオープンできるファイル数の上限 /proc/sys/fs/file-max を超過する。

*

clone(2) と unshare(2) で CLONE_NEWNS フラグを利用する。

*

keyctl(2) の KEYCTL_CHOWN と KEYCTL_SETPERM 操作を実行する。

CAP_SYS_BOOT

reboot(2) と kexec_load(2) を呼び出す。

CAP_SYS_CHROOT

chroot(2). を呼び出す。

CAP_SYS_MODULE

カーネルモジュールのロード、アンロードを行う (init_module(2) と delete_module(2) を参照のこと)。 バージョン 2.6.25 より前のカーネルで、 システム全体のケーパビリティバウンディングセット (capability bounding set) からケーパビリティを外す。

CAP_SYS_NICE

*

プロセスの nice 値の引き上げ (nice(2), setpriority(2)) や、任意のプロセスの nice 値の変更を行う。

*

呼び出し元プロセスに対するリアルタイム・スケジューリングポリシーと、 任意のプロセスに対するスケジューリングポリシーと優先度を設定する (sched_setscheduler(2), sched_setparam(2))。

*

任意のプロセスに対する CPU affinity を設定できる (sched_setaffinity(2))。

*

任意のプロセスに対して I/O スケジューリングクラスと優先度を設定できる (ioprio_set(2))。

*

migrate_pages(2) を任意のプロセスに適用し、プロセスを任意のノードに移動する。

*

move_pages(2) を任意のプロセスに対して行う。

*

mbind(2) と move_pages(2) で MPOL_MF_MOVE_ALL フラグを使用する。

CAP_SYS_PACCT

acct(2) を呼び出す。

CAP_SYS_PTRACE

ptrace(2) を使って任意のプロセスをトレースする。

CAP_SYS_RAWIO

I/O ポート操作を実行する (iopl(2) 、 ioperm(2))。 /proc/kcore にアクセスできる。

CAP_SYS_RESOURCE

*

ext2 ファイルシステム上の予約されている領域を使用する。

*

ext3 のジャーナル機能を制御する ioctl(2) を使用する。

*

ディスク quota の上限を上書きする。

*

リソース上限を増やす (setrlimit(2))。

*

RLIMIT_NPROC リソース制限を上書きする。

*

メッセージキューに関する上限 msg_qbytes を /proc/sys/kernel/msgmnb に指定されている上限よりも大きく設定する (msgop(2) と msgctl(2) 参照)。

CAP_SYS_TIME

システムクロックを変更する (settimeofday(2), stime(2), adjtimex(2))。 リアルタイム (ハードウェア) クロックを変更する。

CAP_SYS_TTY_CONFIG

vhangup(2) を呼び出す。

過去と現在の実装

1.

全ての特権操作について、カーネルはそのスレッドの実効ケーパビリティセットに 必要なケーパビリティがあるかを確認する。

2.

カーネルで、あるスレッドのケーパビリティセットを変更したり、 取得したりできるシステムコールが提供される。

3.

ファイルシステムが、実行可能ファイルにケーパビリティを付与でき、ファイル 実行時にそのケーパビリティをプロセスが取得できるような機能をサポートする。

カーネル 2.6.24 より前では、最初の 2つの要件のみが満たされている。 カーネル 2.6.24 以降では、3つの要件すべてが満たされている。  

スレッドケーパビリティセット

許可 (permitted):

そのスレッドが持つことになっている実効ケーパビリティの 限定的なスーパーセットである。 これは、実効ケーパビリティセットに CAP_SETPCAP ケーパビリティを持っていないスレッドが継承可能ケーパビリティセットに 追加可能なケーパビリティの限定的なスーパーセットでもある。

許可ケーパビリティセットから削除してしまったケーパビリティは、 (set-user-ID-root プログラムか、 そのケーパビリティをファイルケーパビリティで許可しているプログラムを execve(2) しない限りは) もう一度獲得することはできない。

継承可能 (inheritable):

execve(2) を前後で保持されるケーパビリティセットである。 この仕組みを使うことで、あるプロセスが execve(2) を行う際に新しいプログラムの許可ケーパビリティセットとして 割り当てるケーパビリティを指定することができる。

実効 (effective):

カーネルがスレッドの権限 (permission) をチェックするときに 使用するケーパビリティセットである。

fork(2) で作成される子プロセスは、親のケーパビリティセットのコピーを継承する。 execve(2) 中のケーパビリティの扱いについては下記を参照のこと。

capset(2) を使うと、プロセスは自分自身のケーパビリティセット を操作することができる (下記参照)。  

ファイルケーパビリティ

3 つのファイルケーパビリティセットが定義されている。

許可 (Permitted) (以前の強制 (Forced)):

スレッドの継承可能ケーパビリティに関わらず、そのスレッドに自動的に 認められるケーパビリティ。

継承可能 (Inheritable) (以前の 許容 (Allowed)):

このセットと、スレッドの継承可能ケーパビリティセットとの 論理積 (AND) がとられ、 execve(2) の後にそのスレッドの許可ケーパビリティセットで有効となる 継承可能ケーパビリティが決定される。

実効 (Effective):

これは集合ではなく、1 ビットの情報である。 このビットがセットされていると、 execve(2) 実行中に、そのスレッドの新しい許可ケーパビリティが全て 実効ケーパビリティ集合においてもセットされる。 このビットがセットされていない場合、 execve(2) 後には新しい許可ケーパビリティのどれも新しい実効ケーパビリティ集合 にセットされない。

ファイルの実効ケーパビリティビットを有効にするというのは、 execve(2) 実行時に、ファイルの許可ケーパビリティと継承ケーパビリティに対応するものが スレッドの許可ケーパビリティセットとしてセットされるが、 これが実効ケーパビリティセットにもセットされるということである (ケーパビリティの変換ルールは下記参照)。 したがって、ファイルにケーパビリティを割り当てる際 (setcap(8), cap_set_file(3), cap_set_fd(3))、 いずれかのケーパビリティに対して実効フラグを有効と指定する場合、 許可フラグや継承可能フラグを有効にした他の全てのケーパビリティ についても実効フラグを有効と指定しなければならない。

execve() 中のケーパビリティの変換

execve(2) 実行時に、カーネルはプロセスの新しいケーパビリティを次の アルゴリズムを用いて計算する：

P'(permitted) = (P(inheritable) & F(inheritable)) |
                (F(permitted) & cap_bset)

P'(effective) = F(effective) ? P'(permitted) : 0

P'(inheritable) = P(inheritable)    [つまり、変更されない]

P

execve(2) 前のスレッドのケーパビリティセットの値

P'

execve(2) 後のスレッドのケーパビリティセットの値

F

ファイルケーパビリティセットの値

cap_bset

ケーパビリティバウンディングセットの値 (下記参照)

ケーパビリティと、ルートによるプログラムの実行

1.

set-user-ID-root プログラムが実行される場合、 またはプロセスの実ユーザ ID が 0 (root) の場合、 ファイルの継承可能セットと許可セットを全て 1 (全てのケーパビリティが有効) に定義する。

2.

set-user-ID-root プログラムが実行される場合、 ファイルの実効ケーパビリティビットを 1 (enabled) に定義する。

上記のルールにケーパビリティ変換を適用した結果をまとめると、 プロセスが set-user-ID-root プログラムを execve(2) する場合、または実効 UID が 0 のプロセスがプログラムを execve(2) する場合、許可と実効のケーパビリティセットの全ケーパビリティ (正確には、ケーパビリティバウンディングセットによるマスクで除外されるもの 以外の全てのケーパビリティ) を取得するということである。 これにより、伝統的な Unix システムと同じ振る舞いができるようになっている。  

ケーパビリティ・バウンディングセット

*

execve(2) 実行時に、ケーパビリティ・バウンディングセットと ファイルの許可ケーパビリティセットの論理和 (AND) を取ったものが、 そのスレッドの許可ケーパビリティセットに割り当てられる。 つまり、ケーパビリティ・バウンディングセットは、 実行ファイルが認めている許可ケーパビリティに対して 制限を課す働きをする。

*

(Linux 2.6.25 以降) ケーパビリティ・バウンディングセットは、スレッドが capset(2) により自身の継承可能セットに追加可能なケーパビリティの母集団を 制限する役割を持つ。 スレッドに許可されたケーパビリティであっても、バウンディングセットに 含まれていなければ、スレッドはそのケーパビリティは自身の継承可能セットに 追加できず、その結果、継承可能セットにそのケーパビリティを含むファイルを execve(2) する場合、そのケーパビリティを許可セットに持ち続けることができない、 ということである。

バウンディングセットがマスクを行うのは、継承可能ケーパビリティではなく、 ファイルの許可ケーパビリティのマスクを行う点に注意すること。 あるスレッドの継承可能セットにそのスレッドのバウンディングセットに 存在しないケーパビリティが含まれている場合、そのスレッドは、 継承可能セットに含まれるケーパビリティを持つファイルを実行することにより、 許可セットに含まれるケーパビリティも獲得できるということである。

カーネルのバージョンにより、ケーパビリティ・バウンディングセットは システム共通の属性の場合と、プロセス単位の属性の場合がある。

Linux 2.6.25 より前のケーパビリティ・バウンディングセット

2.6.25 より前のカーネルでは、ケーパビリティ・バウンディングセットは システム共通の属性で、システム上の全てのスレッドに適用される。 バウンディングセットは /proc/sys/kernel/cap-bound ファイル経由で参照できる。 (間違えやすいが、このビットマスク形式のパラメータは、 /proc/sys/kernel/cap-bound では符号付きの十進数で表現される。)

init プロセスだけがケーパビリティ・バウンディングセットで ケーパビリティをセットすることができる。 それ以外では、スーパーユーザ (より正確には、 CAP_SYS_MODULE ケーパビリティを持ったプログラム) が、 ケーパビリティ・バウンディングセットのケーパビリティのクリアが できるだけである。

通常のシステムでは、ケーパビリティ・バウンディングセットは、 CAP_SETPCAP が無効になっている。 この制限を取り去るには (取り去るのは危険!)、 include/linux/capability.h 内の CAP_INIT_EFF_SET の定義を修正し、カーネルを再構築する必要がある。

システム共通のケーパビリティ・バウンディングセット機能は、 カーネル 2.2.11 以降で Linux に追加された。

Linux 2.6.25 以降のケーパビリティ・バウンディングセット

Linux 2.6.25 以降では、 「ケーパビリティ・バウンディングセット」はスレッド単位の属性である (システム共通のケーパビリティ・バウンディングセットはもはや存在しない)。

バウンディングセットは fork(2) 時にはスレッドの親プロセスから継承され、 execve(2) の前後では保持される。

スレッドが CAP_SETPCAP ケーパビリティを持っている場合、そのスレッドは prctl(2) の PR_CAPBSET_DROP 操作を使って自身のケーパビリティ・バウンディングセットから ケーパビリティを削除することができる。 いったんケーパビリティをバウンディングセットから削除してしまうと、 スレッドはそのケーパビリティを再度セットすることはできない。 prctl(2) の PR_CAPBSET_READ 操作を使うことで、スレッドがあるケーパビリティが自身のバウンディングセット に含まれているかを知ることができる。

バウンディングセットからのケーパビリティの削除がサポートされるのは、 カーネルのコンパイル時にファイルケーパビリティが有効になっている場合 (CONFIG_SECURITY_FILE_CAPABILITIES) だけである。 この場合には、 (全てのプロセスの先祖である) init プロセスはバウンディングセットで全てのケーパビリティが セットされた状態で開始する。 ファイルケーパビリティが有効になっていない場合には、 init はバウンディングセットで CAP_SETPCAP 以外の全てのケーパビリティがセットされた状態で開始する。 このようになっているのは、 CAP_SETPCAP ケーパビリティがファイルケーパビリティがサポートされていない場合には 違った意味を持つからである。

バウンディングセットからケーパビリティを削除しても、 スレッドの継承可能セットからはそのケーパビリティは削除されない。 しかしながら、バウンディングセットからの削除により、 この先そのケーパビリティをスレッドの継承可能セットに追加すること はできなくなる。  

ユーザ ID 変更のケーパビリティへの影響

1.

UID の変更前には実 UID、実効 UID、保存 set-user-ID のうち 少なくとも一つが 0 で、変更後に実 UID、実効 UID、保存 set-user-ID が すべて 0 以外の値になった場合、許可と実効のケーパビリティセットの 全ケーパビリティをクリアする。

2.

実効 UID が 0 から 0 以外に変更された場合、 実効ケーパビリティセットの全ケーパビリティをクリアする。

3.

実効 UID が 0 以外から 0 に変更された場合、 許可ケーパビリティセットの内容を実効ケーパビリティセットにコピーする。

4.

ファイルシステム UID が 0 から 0 以外に変更された場合 (setfsuid(2) 参照)、実効ケーパビリティセットの以下のケーパビリティがクリアされる: CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_LINUX_IMMUTABLE (Linux 2.2.30 以降), CAP_MAC_OVERRIDE, CAP_MKNOD (Linux 2.2.30 以降)。 ファイルシステム UID が 0 以外から 0 に変更された場合、 上記のケーパビリティのうち許可ケーパビリティセットで有効になっているものが 実効ケーパビリティセットで有効にされる。

各種 UID のうち少なくとも一つが 0 であるスレッドが、 その UID の全てが 0 以外になったときに許可ケーパビリティセットが クリアされないようにしたい場合には、 prctl(2) の PR_SET_KEEPCAPS 操作を使えばよい。  

プログラムでケーパビリティセットを調整する

1.

呼び出し側が CAP_SETPCAP ケーパビリティを持っていない場合、新しい継承可能セットは、 既存の継承可能セットと許可セットの積集合 (AND) の部分集合で なければならない。

2.

(カーネル 2.6.25 以降) 新しい継承可能セットは、既存の継承可能セットとケーパビリティ・ バウンディングセットの積集合 (AND) の部分集合でなければならない。

3.

新しい許可セットは、既存の許可セットの部分集合でなければならない (つまり、そのスレッドが現在持っていない許可ケーパビリティを 獲得することはできない)。

4.

新しい実効ケーパビリティセットは新しい許可ケーパビリティセットの 部分集合になっていなければならない。

securebits フラグ: ケーパビリティだけの環境を構築する

SECBIT_KEEP_CAPS

このフラグをセットされている場合、UID が 0 のスレッドの UID が 0 以外の値に 切り替わる際に、そのスレッドはケーパビリティを維持することができる。 このフラグがセットされていない場合には、UID が 0 から 0 以外の値に 切り替わると、そのスレッドは全てのケーパビリティを失う。 このフラグは execve(2) 時には全てクリアされる (このフラグは、以前の prctl(2) の PR_SET_KEEPCAPS 操作と同じ機能を提供するものである)。

SECBIT_NO_SETUID_FIXUP

このフラグをセットすると、スレッドの実効 UID とファイルシステム UID が 0 と 0 以外の間で切り替わった場合に、 カーネルはケーパビリティセットの調整を行わなくなる (「ユーザ ID 変更のケーパビリティへの影響」の節を参照)。

SECBIT_NOROOT

このビットがセットされている場合、 set-user-ID-root プログラムの実行時や、 実効 UID か 実 UID が 0 のプロセスが execve(2) を呼び出した時に、カーネルはケーパビリティを許可しない (「ケーパビリティと、ルートによるプログラムの実行」の節を参照)。

上記の "base" フラグの各々には対応する "locked" フラグが存在する。 いずれの "locked" フラグも一度セットされると戻すことはできず、 それ以降は対応する "base" フラグを変更することができなくなる。 "locked" フラグは SECBIT_KEEP_CAPS_LOCKED, SECBIT_NO_SETUID_FIXUP_LOCKED, SECBIT_NOROOT_LOCKED という名前である。

securebits フラグは、 prctl(2) の操作 PR_SET_SECUREBITS や PR_GET_SECUREBITS を使うことで変更したり取得したりできる。 フラグを変更するには CAP_SETPCAP ケーパビリティが必要である。

securebits フラグは子プロセスに継承される。 execve(2) においては、 SECURE_KEEP_CAPS が常にクリアされる以外は、全てのフラグが保持される。

アプリケーションは、以下の呼び出しを行うことにより、 自分自身および子孫となるプロセス全てに対して、 必要なファイルケーパビリティを持ったプログラムを実行しない限り、 対応するケーパビリティを獲得できないような状況に閉じこめることができる。

prctl(PR_SET_SECUREBITS,
        SECBIT_KEEP_CAPS_LOCKED |
        SECBIT_NO_SETUID_FIXUP |
        SECBIT_NO_SETUID_FIXUP_LOCKED |
        SECBIT_NOROOT |
        SECBIT_NOROOT_LOCKED);

準拠

ケーパビリティに関する標準はないが、 Linux のケーパビリティは廃案になった POSIX.1e 草案に基づいて実装されている。 http://wt.xpilot.org/publications/posix.1e/ を参照。  

注意

/proc/PID/task/TID/status ファイルを使うと、スレッドのケーパビリティセットを見ることができる。 /proc/PID/status ファイルには、プロセスのメインスレッドのケーパビリティセットが表示される。

libcap パッケージは、ケーパビリティを設定・取得するための ルーチン群を提供している。これらのインタフェースは、 capset(2) と capget(2) が提供するインターフェースと比べて、より使いやすく、変更される可能性が少ない。 このパッケージでは、 setcap(8), getcap(8) というプログラムも提供されている。 パッケージは http://www.kernel.org/pub/linux/libs/security/linux-privs で入手できる。

バージョン 2.6.24 より前、およびファイルケーパビリティが 有効になっていない2.6.24 以降のカーネルでは、 CAP_SETPCAP ケーパビリティを持ったスレッドは自分以外のスレッドの ケーパビリティを操作できる。 しかしながら、これは理論的に可能というだけである。 以下のいずれかの場合においても、どのスレッドも CAP_SETPCAP ケーパビリティを持つことはないからである。

*

2.6.25 より前の実装では、システム共通のケーパビリティ・バウンディングセット /proc/sys/kernel/cap-bound ではこのケーパビリティは常に無効になっており、 ソースを変更してカーネルを再コンパイルしない限り、 これを変更することはできない。

*

現在の実装ではファイルケーパビリティが無効になっている場合、 プロセス毎のバウンディングセットからこのケーパビリティを抜いて init は開始され、 システム上で生成される他の全てのプロセスでこのバウンディングセットが 継承される。

関連項目

カーネルソース内の include/linux/capability.h

Index

名前

説明

ケーパビリティのリスト

過去と現在の実装

スレッドケーパビリティセット

ファイルケーパビリティ

execve() 中のケーパビリティの変換

ケーパビリティと、ルートによるプログラムの実行

ケーパビリティ・バウンディングセット

ユーザ ID 変更のケーパビリティへの影響

プログラムでケーパビリティセットを調整する

securebits フラグ: ケーパビリティだけの環境を構築する

準拠

注意

関連項目