この章では、Solaris オペレーティングシステム (Solaris OS) におけるファイル保護の方法について説明します。また、システムに悪影響を与える可能性のあるアクセス権が設定されたファイルからシステムを保護する方法についても説明します。
アクセス制御リスト (ACL) を使って ZFS ファイルを保護する方法については、『Oracle Solaris ZFS 管理ガイド』の第 8 章「ACL による Oracle Solaris ZFS ファイルの保護」を参照してください。
この章の内容は次のとおりです。
ファイルは、UNIX ファイルアクセス権と ACL を通して保護することができます。スティッキービットが設定されたファイルと、実行可能なファイルは、特殊なセキュリティー対策が必要です。
この表は、ファイルとディレクトリの監視と保護を行うコマンドについて説明したものです。
表 6–1 ファイルとディレクトリの保護を行うコマンド
コマンド |
説明 |
マニュアルページ |
---|---|---|
ディレクトリ内のファイルとファイル情報を表示します。 | ||
ファイルの所有権を変更します。 | ||
ファイルのグループ所有権を変更します。 | ||
ファイルのアクセス権を変更します。記号モード (文字と記号) または絶対モード (8 進数) を使用して、ファイルのアクセス権を変更できます。 |
従来の UNIX ファイルアクセス権では、次に示す 3 つのユーザークラスに所有権を割り当てることができます。
ユーザー – ファイルまたはディレクトリの所有者。通常はファイルを作成したユーザーです。ファイルの所有者は、そのファイルの読み取り、書き込み (ファイルを変更する)、または実行 (コマンドの場合) が行えるユーザーを決定できます。
グループ – ユーザーグループのメンバー。
その他 – ファイル所有者ではなくグループメンバーでもないその他の全ユーザー。
ファイルアクセス権の割り当てや変更が行えるのは、通常、そのファイルの所有者だけです。しかし、ファイルの所有権の変更は、管理権限のあるユーザー (スーパーユーザーなど) または役割 (Primary Administrator 役割など) によっても行えます。システムポリシーを上書きする方法については、例 6–2 を参照してください。
ファイルは、7 つの形式のいずれかになります。各形式は、次のように記号で示されます。
次の表に、各ユーザークラスに与えることができる、ファイルまたはディレクトリのアクセス権を示します。
表 6–2 ファイルとディレクトリのアクセス権
記号 |
アクセス権 |
オブジェクト |
説明 |
---|---|---|---|
r |
読み取り |
ファイル |
ファイルの内容を開いて読み込むことができます。 |
|
|
ディレクトリ |
ディレクトリ内のファイルを一覧表示できます。 |
w |
書き込み |
ファイル |
ファイルの内容の変更またはファイルの削除を行えます。 |
|
|
ディレクトリ |
ディレクトリに対してファイルまたはリンクを追加できます。また、ディレクトリ内のファイルまたはリンクの削除も行えます。 |
x |
実行 |
ファイル |
ファイルがプログラムまたはシェルスクリプトの場合、そのファイルを実行できます。また、exec(2) システム呼び出しの 1 つを使用してそのプログラムを実行することもできます。 |
|
|
ディレクトリ |
ディレクトリ内のファイルを開いたり、実行したりできます。また、ディレクトリを作成し、その下にサブディレクトリを作成できます。 |
- |
拒否 |
ファイルとディレクトリ |
ファイルの読み込み、書き込み、または実行を行うことができません。 |
これらのファイルアクセス権は、通常のファイルと特殊ファイル (デバイス、ソケット、名前付きパイプ (FIFO) など) の両方に適用されます。
シンボリックリンクには、そのリンクが指すファイルのアクセス権が適用されます。
ディレクトリとそのサブディレクトリ内のファイルは、そのディレクトリに対するファイルアクセス権を制限することで保護できます。ただし、スーパーユーザーはシステム上のすべてのファイルとディレクトリにアクセスできます。
実行可能ファイルと公開ディレクトリには、 3 種類の特殊なアクセス権 (setuid、setgid、およびスティッキービット) を設定できます。これらのアクセス権を設定すると、その実行可能ファイルを実行するユーザーは、そのファイルの所有者 (またはグループ) の ID を持つことができます。
特殊なアクセス権はセキュリティー上の問題を引き起こすため、設定するときは十分な注意が必要です。たとえば、ユーザー ID (UID) を 0 (root の UID) に設定するプログラムを実行すれば、ユーザーはスーパーユーザー権限を取得できます。また、すべてのユーザーは、所有するファイルに対して特殊なアクセス権を設定できるため、これもセキュリティー上の問題の原因となります。
setuid アクセス権や setgid アクセス権を不正に使用してスーパーユーザー権限が取得されていないか、システムを監視する必要があります。疑わしいアクセス権によって、管理プログラムの所有権が root や bin ではなく一般ユーザーに付与されていることが考えられます。この特殊なアクセス権を使用しているファイルをすべて検索し、リストする方法は、「特殊なファイルアクセス権が設定されたファイルを見つける方法」を参照してください。
setuid アクセス権を実行可能ファイルに設定すると、このファイルを実行するプロセスにはその実行可能ファイルを実行しているユーザーではなく、ファイルの所有者に基づいてアクセス権が与えられます。この特殊なアクセス権を使用すると、通常は所有者しか利用できないファイルやディレクトリにアクセスできます。
たとえば、passwd コマンドの setuid アクセス権によってユーザーはパスワードを変更できます。次に、setuid アクセス権のある passwd コマンドの例を示します。
-r-sr-sr-x 3 root sys 28144 Jun 17 12:02 /usr/bin/passwd |
この特殊なアクセス権は、プロセスの実行が終了したあとでも、高度な知識のあるユーザーは setuid プロセスによって与えられたアクセス権を維持する手段を見つけることができるため、セキュリティー上の危険が存在します。
プログラムから予約済み UID (0 から 99) で setuid アクセス権を使用しても、実効 UID は正しく設定されない場合があります。シェルスクリプトを使用するか、setuid アクセス権では予約済み UID を使用しないようにしてください。
setgidアクセス権は setuid アクセス権に似ています。プロセスの実効グループ ID (GID) はファイルを所有するグループに変更され、ユーザーにはそのグループに与えられたアクセス権に基づくアクセス権が与えられます。/usr/bin/mail コマンドには、次のように setgid アクセス権が設定されています。
-r-x--s--x 1 root mail 67504 Jun 17 12:01 /usr/bin/mail |
setgidアクセス権がディレクトリに適用されると、このディレクトリ内で作成されたファイルはディレクトリが所属するグループに含まれることになります。生成するプロセスが所属するグループに含まれるわけではありません。ディレクトリに対する書き込み権および実行権を持つユーザーは、そのディレクトリにファイルを作成できます。ただし、作成したファイルはユーザーのグループではなくディレクトリを所有するグループに割り当てられます。
setgidアクセス権を使用して不正にスーパーユーザー権限が取得されていないか、システムを監視する必要があります。疑わしいアクセス権によって、このようなプログラムへのグループアクセス権が、root や bin ではなく、意外なグループに与えられることがあります。このようなアクセス権を使用しているファイルをすべて検索し、一覧表示する方法は、「特殊なファイルアクセス権が設定されたファイルを見つける方法」を参照してください。
「スティッキービット」は、ディレクトリ内のファイルを保護するアクセス権ビットです。ディレクトリにスティッキービットが設定されている場合、そのファイルを削除できるのはその所有者、ディレクトリの所有者、または特権を持つユーザーだけです。特権を持つユーザーの例として、root ユーザーや Primary Administrator 役割が挙げられます。スティッキービットにより、ユーザーは /tmp などの公開ディレクトリからほかのユーザーのファイルを削除できなくなります。
drwxrwxrwt 7 root sys 400 Sep 3 13:37 tmp |
TMPFS ファイルシステム上で公開ディレクトリを設定するときには、スティッキービットを手動で設定してください。手順については、例 6–5 を参照してください。
ファイルやディレクトリを作成するときには、デフォルトのアクセス権が設定されます。このシステムデフォルトは変更が可能です。テキストファイルのアクセス権は 666 であり、すべてのユーザーに読み取り権と書き込み権を与えます。ディレクトリと実行可能ファイルのアクセス権は 777 で、すべてのユーザーに読み取り権、書き込み権、および実行権を与えます。一般にユーザーは、自分の /etc/profile ファイル、.cshrc ファイル、または .login ファイルを手動で指定し、システムのデフォルトに優先させます。
umask コマンドによって割り当てられる値は、デフォルトから差し引かれます。この処理には、chmod コマンドでアクセス権を与えるのと同じ方法でアクセス権を拒否する効果があります。たとえば、chmod 022 コマンドはグループとその他のユーザーに書き込み権を与えますが、umask 022 コマンドはグループとその他のユーザーの書き込み権を拒否します。
次の表に、代表的な umask の設定とその設定が実行可能ファイルに与える影響を示します。
表 6–3 各セキュリティーレベルの umask 設定
セキュリティーレベル |
umask 設定 |
許可されないアクセス権 |
---|---|---|
緩やか (744) |
022 |
グループとその他のユーザーによる w |
中程度 (740) |
027 |
グループによる w、その他のユーザーによる rwx |
中程度 (741) |
026 |
グループによる w、その他のユーザーによる rw |
厳しい (700) |
077 |
グループとその他のユーザーによる rwx |
umask 値の設定の詳細については、umask(1) のマニュアルページを参照してください。
chmod コマンドを使用すると、ファイルのアクセス権を変更できます。ファイルまたはディレクトリの所有者、あるいはスーパーユーザーだけがそのアクセス権を変更できます。
chmod コマンドを使用して、次のどちらかのモードでアクセス権を設定できます。
絶対モード – ファイルアクセス権を表す数値を使用します。絶対モードを使用してアクセス権を変更するときは、3 つ 1 組のアクセス権を 8 進数で表します。絶対モードは、アクセス権の設定に一番多く使用されている方法です。
次の表に、絶対モードでファイルのアクセス権を設定するための 8 進数値を示します。これらの数字を 3 つ組み合わせて、所有者、グループ、その他のユーザーのファイルアクセス権をこの順に設定します。たとえば、値 644 は、所有者に対して読み取り権と書き込み権を設定し、グループとその他のユーザーに対しては読み取り専用権を設定します。
表 6–4 絶対モードによるファイルのアクセス権の設定
8 進数値 |
ファイルのアクセス権 |
設定されるアクセス権 |
---|---|---|
0 |
--- |
なし |
1 |
--x |
実行権のみ |
2 |
-w- |
書き込み権のみ |
3 |
-wx |
書き込み権と実行権 |
4 |
r-- |
読み取り権のみ |
5 |
r-x |
読み取り権と実行権 |
6 |
rw- |
読み取り権と書き込み権 |
7 |
rwx |
読み取り権、書き込み権、実行権 |
次の表に、記号モードでファイルのアクセス権を設定するための記号の一覧を示します。記号では、アクセス権を設定または変更できる対象ユーザー、実行される操作、あるいは割り当てるまたは変更するアクセス権を指定できます。
表 6–5 記号モードによるファイルのアクセス権の設定
記号 |
機能 |
説明 |
---|---|---|
u |
<対象ユーザー> |
ユーザー (所有者) |
g |
<対象ユーザー> |
グループ |
o |
<対象ユーザー> |
その他のユーザー |
a |
<対象ユーザー> |
すべて |
= |
オペレータ |
割り当て |
+ |
オペレータ |
追加 |
- |
オペレータ |
削除 |
r |
アクセス権 (アクセス権ビット) |
読み取り |
w |
アクセス権 (アクセス権ビット) |
書き込み |
x |
アクセス権 (アクセス権ビット) |
実行 |
l |
アクセス権 (アクセス権ビット) |
強制ロック、setgid ビットはオン、グループ実行ビットはオフ |
s |
アクセス権 (アクセス権ビット) |
setuid または setgid ビットはオン |
t |
アクセス権 (アクセス権ビット) |
スティッキービットはオン、その他の実行ビットはオン |
機能列に <対象ユーザー> <操作> <アクセス権> の順で、ファイルまたはディレクトリのアクセス権を変更する記号を指定します。
アクセス権を変更する対象となるユーザーを指定します。
実行する操作を指定します。
変更するアクセス権を指定します。
絶対モードまたは記号モードで、ファイルに特殊なアクセス権を設定できます。しかし、ディレクトリに setuid アクセス権を設定する場合と、ディレクトリからこのアクセス権を削除する場合は、記号モードを使用する必要があります。絶対モードでは、3 つ 1 組のアクセス権の左端に新しい 8 進数値を追加して、特殊なアクセス権を設定します。次の表に、ファイルに特殊なアクセス権を設定する 8 進数値を示します。
表 6–6 絶対モードによる特殊なファイルアクセス権の設定
8 進数値 |
特殊なファイルアクセス権 |
---|---|
1 |
スティッキービット |
2 |
setgid |
4 |
setuid |
従来の UNIX ファイル保護機能は、ファイルの所有者、ファイルグループ、その他のユーザーという 3 つのユーザークラスに 読み取り権、書き込み権、実行権を提供します。UFS ファイルシステムでは、アクセス制御リスト (ACL) により次のことが可能となり、ファイルセキュリティーを管理するレベルがさらに詳細になります。
ファイル所有者、グループ、その他のユーザー、特定のユーザーおよびグループにファイルアクセス権を定義します
これらの各カテゴリにデフォルトのアクセス権を定義します
ZFS ファイルシステムの ACL および NFSv4 ファイルの ACL については、『Oracle Solaris ZFS 管理ガイド』の第 8 章「ACL による Oracle Solaris ZFS ファイルの保護」を参照してください。
たとえば、グループ内のすべてのユーザーがファイルを読み取れるようにする場合は、そのファイルにグループの読み取り権を設定すればすみます。その場合に、そのグループ内の 1 人のユーザーだけに書き込み権を与えたいとします。標準の UNIX ではファイルセキュリティーをこのように設定することはできませんが、ACL では可能です。
ACL エントリはファイルの ACL を定義する手段であり、UFS ファイルシステムでは、エントリは setfacl コマンドを使って設定されます。UFS ACL エントリは、次のようにコロンで区切ったフィールドで構成されます。
entry-type:[uid|gid]:perms |
ファイルのアクセス権を設定する ACL エントリの種類です。たとえば、entry-type は user (ファイルの所有者) または mask (ACL マスク) に設定できます。ACL エントリの一覧については、表 6–7 と表 6–8 を参照してください。
ユーザー名またはユーザー ID (UID) です。
グループ名またはグループ ID (GID) です。
entry-type に設定するアクセス権を表します。perms は、記号文字 rwx または 8 進数の数字で指定できます。これらは chmod コマンドに使用するのと同じ数字です。
次に、ユーザー stacey の読み取り権と書き込み権を設定する ACL エントリの例を示します。
user:stacey:rw- |
ACL などの UFS ファイルシステム属性は UFS ファイルシステムだけでサポートされます。そのため、/tmp ディレクトリ (通常は、TMPFS ファイルシステムとしてマウントされている) で ACL エントリを持つファイルを復元またはコピーすると、その ACL エントリは失われます。UFS ファイルを一時的に格納するには、/var/tmp ディレクトリを使用してください。
次の表は、ファイルに ACL を設定するときに使用する有効な ACL エントリの一覧です。最初の 3 つの ACL エントリは、基本的な UNIX のファイル保護機能を提供します。
表 6–7 UFS ファイルの ACL エントリ
ACL エントリ |
説明 |
---|---|
u[ser]::perms |
所有者のアクセス権。 |
g[roup]::perms |
グループのアクセス権。 |
o[ther]:perms |
所有者やグループのメンバー以外のユーザーのアクセス権。 |
m[ask]:perms |
ACL マスク。マスクエントリは、ユーザー (所有者以外) とグループに許可される最大アクセス権を示します。マスクは、すべてのユーザーとグループのアクセス権を即時に変更する手段です。 たとえば、mask:r-- マスクエントリは、ユーザーとグループが書き込み権および実行権を持つことがアカウントに示されていても、読み取り権しか使用できないことを意味します。 |
u[ser]:uid:perms |
特定のユーザーのアクセス権。uid には、ユーザー名または UID の数値を指定できます。 |
g[roup]:gid:perms |
特定のグループのアクセス権。gid には、グループ名または GID の数値を指定できます。 |
表 6–7 に示した ACL エントリのほかに、ディレクトリにはデフォルトの ACL エントリも設定できます。デフォルトの ACL エントリを持つディレクトリ内で作成されたファイルまたはディレクトリは、デフォルトの ACL エントリと同じ ACL エントリを持つことになります。表 6–8 は、ディレクトリに使用するデフォルトの ACL エントリの一覧です。
ディレクトリ上の特定のユーザーおよびグループに対してデフォルトの ACL エントリを初めて設定するときは、所有者、グループ、その他のユーザー、および ACL マスクにもデフォルトの ACL エントリを設定する必要があります。これらのエントリは、必ず設定しなければなりません。これらは、次の表に示された最初の 4 つのデフォルト ACL エントリに相当します。
表 6–8 UFS ディレクトリのデフォルト ACL エントリ
デフォルトの ACL エントリ |
説明 |
---|---|
d[efault]:u[ser]::perms |
所有者のデフォルトアクセス権。 |
d[efault]:g[roup]::perms |
グループのデフォルトアクセス権。 |
d[efault]:o[ther]:perms |
所有者やグループのメンバー以外のユーザーのデフォルトアクセス権。 |
d[efault]:m[ask]:perms |
デフォルトの ACL マスク。 |
d[efault]:u[ser]:uid:perms |
特定のユーザーのデフォルトアクセス権。uid には、ユーザー名または UID の数値を指定できます。 |
d[efault]:g[roup]:gid:perms |
特定のグループのデフォルトアクセス権。gid には、グループ名または GID の数値を指定できます。 |
次のコマンドは、UFS ファイルまたはディレクトリに設定される ACL の管理に使用されます。
ACL エントリの設定、追加、変更、および削除を行います。詳細は、setfacl(1) のマニュアルページを参照してください。
ACL エントリを表示します。詳細は、getfacl(1) のマニュアルページを参照してください。
セキュリティーのバグの多くは、デフォルトで読み取り権、書き込み権、および実行権が設定された実行可能スタックで発生します。実行可能スタックには実行権が割り当てられていますが、ほとんどのプログラムは実行可能スタックがなくても正しく機能します。
noexec_user_stack 変数を使うと、スタックを実行可能として割り当てるかどうかを指定できます。この変数は、Solaris 2.6 から利用可能です。デフォルトでは、この変数は 0 に設定されるため (64 ビットアプリケーションを除く)、プログラムは ABI に準拠して動作します。この変数が 0 以外の値に設定された場合、システムはシステム中のすべてのプロセスのスタックに読み取り権と書き込み権のマークを付けますが、実行権のマークは付けません。
この変数が設定されている場合、プログラムがスタック上でコードを実行しようとすると SIGSEGV シグナルが送信されます。このシグナルが送信されると、通常、プログラムはコアダンプして終了します。このようなプログラムは、違反しているプログラム名、プロセス ID、およびプログラムを実行した実ユーザー ID を含む警告メッセージも生成します。次に例を示します。
a.out[347] attempt to execute code on stack by uid 555 |
メッセージは、syslog kern 機能が notice レベルの設定されているときに、syslog デーモンによってログに記録されます。このログへの記録は、デフォルトで syslog.conf ファイルに設定されていて、メッセージがコンソールと /var/adm/messages ファイルの両方に送信されることを意味します。詳細は、syslogd(1M) および syslog.conf(4) のマニュアルページを参照してください。
syslog メッセージは、潜在的なセキュリティーの問題を調べるときに役立ちます。また、このメッセージは、この変数を設定したために正しく動作しなくなった、実行可能スタックに依存するプログラムを確認するのにも役立ちます。メッセージを記録しない場合、システム管理者は、/etc/system ファイルで noexec_user_stack_log 変数を 0 に設定します。メッセージが記録されなくなりますが、SIGSEGV シグナルは送られるので、実行中のプログラムはコアダンプを生成して終了します。
mprotect() 関数を使用すれば、プログラムのスタックが実行可能であることを明示的にマーク付けできます。詳細は、mprotect(2) のマニュアルページを参照してください。
ハードウェアの制限のため、実行可能スタックの問題を捕えて報告する機能は、ほとんどの x86 ベースシステムで利用できません。AMD64 プロダクトファミリ内のシステムであれば、実行可能スタックの問題を捕えて報告できます。
次の作業マップは、ファイル保護に関連した作業の説明箇所を示しています。
タスク |
説明 |
参照先 |
---|---|---|
UNIX アクセス権を使用してファイルを保護します |
ファイルの UNIX アクセス権を表示します。UNIX アクセス権を使用してファイルを保護します | |
ACL を使用してファイルを保護します |
ACL を追加することで、UNIX アクセス権よりも細かいレベルでファイルを保護します。 | |
セキュリティーリスクのあるファイルからシステムを保護します |
不審な所有権が設定された実行可能ファイルを見つけます。システムに損傷を与えかねないファイルを無効にします。 |
次の作業マップは、ファイルアクセス権の一覧表示、ファイルアクセス権の変更、特殊なファイルアクセス権によるファイルの保護などの作業操作について説明した箇所を示しています。
作業 |
参照先 |
---|---|
ファイル情報を表示します | |
ファイル所有権を変更します | |
ファイルアクセス権を変更します |
ls コマンドを使用して、ディレクトリ内のすべてのファイルに関する情報を表示します。
次のコマンドを入力すると、現在のディレクトリ内のすべてのファイルの一覧が長形式で表示されます。
% ls -la |
ユーザー所有権、グループ所有権、ファイルのアクセス権などを長形式で表示します。
ドット (.) で始まる隠しファイルを含め、すべてのファイルを表示します。
次の例では、/sbin ディレクトリ内のファイルを部分的に表示しています。
% cd /sbin % ls -la total 13456 drwxr-xr-x 2 root sys 512 Sep 1 14:11 . drwxr-xr-x 29 root root 1024 Sep 1 15:40 .. -r-xr-xr-x 1 root bin 218188 Aug 18 15:17 autopush lrwxrwxrwx 1 root root 21 Sep 1 14:11 bpgetfile -> ... -r-xr-xr-x 1 root bin 505556 Aug 20 13:24 dhcpagent -r-xr-xr-x 1 root bin 456064 Aug 20 13:25 dhcpinfo -r-xr-xr-x 1 root bin 272360 Aug 18 15:19 fdisk -r-xr-xr-x 1 root bin 824728 Aug 20 13:29 hostconfig -r-xr-xr-x 1 root bin 603528 Aug 20 13:21 ifconfig -r-xr-xr-x 1 root sys 556008 Aug 20 13:21 init -r-xr-xr-x 2 root root 274020 Aug 18 15:28 jsh -r-xr-xr-x 1 root bin 238736 Aug 21 19:46 mount -r-xr-xr-x 1 root sys 7696 Aug 18 15:20 mountall . . . |
それぞれの行には、ファイルについての情報が次の順で表示されています。
ファイルの形式 – たとえば、d。ファイル形式の一覧は、「ファイルとディレクトリの所有権」を参照してください。
アクセス権 – たとえば、r-xr-xr-x。詳細は、「ファイルとディレクトリの所有権」を参照してください。
ハードリンクの数 – たとえば、2。
ファイルの所有者 – たとえば、root。
ファイルのグループ – たとえば、bin。
バイト数で示したファイルサイズ – たとえば、7696。
ファイルの作成日時、またはファイルが最後に変更された日時 – たとえば、Aug 18 15:20。
ファイルの名前 – たとえば、mountall。
ファイル所有者、Primary Administrator 役割、またはスーパーユーザーは、任意のファイルの所有権を変更できます。
ファイルのアクセス権を表示します。
% ls -l example-file -rw-r--r-- 1 janedoe staff 112640 May 24 10:49 example-file |
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
ファイルの所有者を変更します。
# chown stacey example-file |
ファイルの所有者が変更されていることを確認します。
# ls -l example-file -rw-r--r-- 1 stacey staff 112640 May 26 08:50 example-file |
セキュリティー上の考慮事項 – rstchown 変数の設定をゼロに変更してシステムセキュリティーポリシーを上書きする場合は、それ相応の理由がなければなりません。システムにアクセスするユーザーは誰でもシステム上の任意のファイルの所有権を変更できるようになります。
この例では、rstchown 変数の値は、/etc/system ファイル内でゼロに設定されます。この設定によりファイルの所有者は、chown コマンドを使用してファイルの所有権をほかのユーザーに変更できます。所有者は chgrp コマンドを使用し、ファイルのグループ所有権を所有者自身が属していないグループに設定することもできます。変更は、システムの再起動時に適用されます。
set rstchown = 0 |
詳細は、chown(1) および chgrp(1) のマニュアルページを参照してください。
NFS マウントされたファイルシステムでは、所有権とグループの変更に関する制限がほかにもあります。NFS マウントされたシステムに対するアクセスの制限については、『Solaris のシステム管理 (ネットワークサービス)』の第 6 章「ネットワークファイルシステムへのアクセス (リファレンス)」を参照してください。
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
$ chgrp scifi example-file |
グループの設定については、『Solaris のシステム管理 (基本編)』の第 4 章「ユーザーアカウントとグループの管理 (概要)」を参照してください。
ファイルのグループ所有権が変更されていることを確認します。
$ ls -l example-file -rw-r--r-- 1 stacey scifi 112640 June 20 08:55 example-file |
また、例 6–2 も参照してください。
ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。
現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。
アクセス権を記号モードで変更します。
% chmod who operator permissions filename |
アクセス権を変更する対象となるユーザーを指定します。
実行する操作を指定します。
変更するアクセス権を指定します。有効な記号の一覧は、表 6–5 を参照してください。
ファイルまたはディレクトリを指定します。
ファイルのアクセス権が変更されていることを確認します。
% ls -l filename |
次の例では、その他のユーザーから読み取り権を削除します。
% chmod o-r example-file1 |
次の例では、ユーザー、グループ、およびその他のユーザーに、読み取り権と実行権を追加します。
$ chmod a+rx example-file2 |
次の例では、グループに読み取り権、書き込み権、および実行権を割り当てます。
$ chmod g=rwx example-file3 |
ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。
現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。
アクセス権を絶対モードで変更します。
% chmod nnn filename |
所有者、グループ、その他のユーザーのアクセス権をこの順序で表す 8 進数値を指定します。有効な 8 進数値の一覧は、表 6–4 を参照してください。
ファイルまたはディレクトリを指定します。
chmod コマンドを使用して ACL エントリを持つファイルのグループアクセス権を変更する場合、グループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクのアクセス権は、そのファイル上に ACL エントリを持つほかのユーザーおよびグループのアクセス権を変更する場合があるので注意が必要です。getfacl コマンドを使用して、すべての ACL エントリに適切なアクセス権が設定されていることを確認してください。詳細は、getfacl(1) のマニュアルページを参照してください。
ファイルのアクセス権が変更されていることを確認します。
% ls -l filename |
次の例では、公開ディレクトリのアクセス権が、744 (読み取り / 書き込み / 実行; 読み取り専用; 読み取り専用) から 755 (読み取り / 書き込み / 実行; 読み取り / 実行; 読み取り / 実行) に変更されます。
# ls -ld public_dir drwxr--r-- 1 ignatz staff 6023 Aug 5 12:06 public_dir # chmod 755 public_dir # ls -ld public_dir drwxr-xr-x 1 ignatz staff 6023 Aug 5 12:06 public_dir |
次の例では、実行可能シェルスクリプトのアクセス権が、読み取り/書き込みから、読み取り/書き込み/実行に変更されます。
% ls -l my_script -rw------- 1 ignatz staff 6023 Aug 5 12:06 my_script % chmod 700 my_script % ls -l my_script -rwx------ 1 ignatz staff 6023 Aug 5 12:06 my_script |
ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。
現在の所有者またはスーパーユーザー能力を持つユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。
% chmod nnnn filename |
ファイルまたはディレクトリのアクセス権を変更する 8 進数値を指定します。一番左端の 8 進数値で、ファイルに特殊なアクセス権を設定します。特殊なアクセス権に有効な 8 進数値の一覧は、表 6–6 を参照してください。
ファイルまたはディレクトリを指定します。
chmod コマンドを使用して ACL エントリを持つファイルのグループアクセス権を変更する場合、グループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクのアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループのアクセス権を変更する場合があるので注意が必要です。getfacl コマンドを使用して、すべての ACL エントリに適切なアクセス権が設定されていることを確認してください。詳細は、getfacl(1) のマニュアルページを参照してください。
ファイルのアクセス権が変更されていることを確認します。
% ls -l filename |
次の例は、dbprog ファイルに setuid のアクセス権を設定します。
# chmod 4555 dbprog # ls -l dbprog -r-sr-xr-x 1 db staff 12095 May 6 09:29 dbprog |
次の例では、dbprog2 ファイルに setgid のアクセス権を設定します。
# chmod 2551 dbprog2 # ls -l dbprog2 -r-xr-s--x 1 db staff 24576 May 6 09:30 dbprog2 |
次の例では、public_dir ディレクトリにスティッキービットのアクセス権を設定します。
# chmod 1777 public_dir # ls -ld public_dir drwxrwxrwt 2 ignatz staff 512 May 15 15:27 public_dir |
次の作業マップは、UFS ファイルの ACL を表示する、ACL を変更する、ほかのファイルへ ACL をコピーするといった作業について説明した箇所を示しています。
作業 |
参照先 |
---|---|
ファイルに ACL が存在するかを確認します | |
ファイルに ACL を追加します | |
ACL をコピーします | |
ACL を変更します | |
ファイルから ACL を削除します | |
ファイルの ACL を表示します |
% ls -l filename |
filename には、ファイルまたはディレクトリを指定します。
出力のモードフィールドの右側にプラス記号 (+) が表示されているときは、そのファイルに ACL が設定されています。
UNIX ファイルアクセス権を超える ACL エントリを追加しない限り、ファイルの ACL は「弱い」とみなされ、プラス記号 (+) は表示されません。
次の例では、ch1.sgm ファイルに ACL が設定されています。ACL は、モードフィールドの右側にあるプラス記号 (+) で示されています。
% ls -l ch1.sgm -rwxr-----+ 1 stacey techpubs 167 Nov 11 11:13 ch1.sgm |
setfacl コマンドを使用してファイルの ACL を設定します。
% setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ... |
ファイルに対して ACL を設定します。すでに ACL が設定されている場合、新しい ACL に置き換えます。このオプションには、少なくとも user::、group::、および other:: のエントリを指定する必要があります。
所有者のアクセス権を指定します。
グループメンバーのアクセス権を指定します。
所有者またはグループのメンバー以外のユーザーのアクセス権を指定します。
ACL マスクのアクセス権を指定します。マスクは、ユーザー (所有者以外) とグループに許される最大アクセス権を示します。
ファイルまたはディレクトリ上で特定のユーザーとグループに設定する 1 つまたは複数の ACL エントリのリストを指定します。ディレクトリ上でデフォルトの ACL エントリを設定することもできます。有効な ACL エントリについては、表 6–7 と表 6–8 を参照してください。
ACL を設定する 1 つまたは複数のファイルまたはディレクトリを指定します。filename が複数ある場合は、スペースで区切ります。
すでにファイル上に ACL が存在する場合、-s オプションを指定すると、ACL 全体が新しい ACL に置き換えられます。
詳細は、setfacl(1) のマニュアルページを参照してください。
ACL (ACL エントリ) がファイルに設定されたことを確認します。
% getfacl filename |
詳細は、「ファイルに ACL が設定されているかどうかを検査する方法」を参照してください。
次の例では、ch1.sgm ファイルのアクセス権を設定しています。所有者には読み取り権と書き込み権が設定され、グループには読み取り専用権が設定され、その他のユーザーには何も設定されません。また、ユーザー anusha にはこのファイルの読み取り権および書き込み権が与えられ、ACL マスクには読み取り権および書き込み権が設定されます。これは、ユーザーやグループは実行権を持たないことを意味します。
% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:anusha:rw- ch1.sgm % ls -l total 124 -rw-r-----+ 1 stacey techpubs 34816 Nov 11 14:16 ch1.sgm -rw-r--r-- 1 stacey techpubs 20167 Nov 11 14:16 ch2.sgm -rw-r--r-- 1 stacey techpubs 8192 Nov 11 14:16 notes % getfacl ch1.sgm # file: ch1.sgm # owner: stacey # group: techpubs user::rw- user:anusha:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:--- |
次の例では、ch2.sgm ファイルのアクセス権を設定します。所有者には読み取り権、書き込み権、および実行権が設定され、グループには読み取り専用権が設定され、その他のユーザーには何も設定されません。また、ACL マスクには読み取り権が設定されます。さらに、ユーザー anusha には読み取り権と書き込み権が与えられます。ただし、ACL マスクの設定により、anusha のアクセス権は読み取り専用です。
% setfacl -s u::7,g::4,o:0,m:4,u:anusha:7 ch2.sgm % getfacl ch2.sgm # file: ch2.sgm # owner: stacey # group: techpubs user::rwx user:anusha:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:--- |
getfacl の出力先を変更することにより、ファイルの ACL をほかのファイルへコピーします。
% getfacl filename1 | setfacl -f - filename2 |
ACL のコピー元ファイルを指定します
ACL のコピー先ファイルを指定します
次の例では、ch2.sgm の ACL が ch3.sgm にコピーされます。
% getfacl ch2.sgm | setfacl -f - ch3.sgm |
setfacl コマンドを使用してファイルの ACL エントリを変更します。
% setfacl -m acl-entry-list filename ... |
ファイルの ACL エントリが変更されたことを確認します。
% getfacl filename |
次の例では、ユーザー anusha のアクセス権を読み取りおよび書き込みに変更します。
% setfacl -m user:anusha:6 ch3.sgm % getfacl ch3.sgm # file: ch3.sgm # owner: stacey # group: techpubs user::rw- user::anusha:rw- #effective:r-- group::r- #effective:r-- mask:r-- other:r- |
次の例では、book ディレクトリのデフォルトアクセス権を変更します。グループ staff のデフォルトのアクセス権を読み取りに変更し、さらに、ACL マスクのデフォルトアクセス権を読み取りおよび書き込みに変更します。
% setfacl -m default:group:staff:4,default:mask:6 book |
ファイルから ACL エントリを削除します。
% setfacl -d acl-entry-list filename ... |
指定した ACL エントリを削除します。
ファイルまたはディレクトリから (アクセス権を指定せずに) 削除する ACL エントリのリストを指定します。特定のユーザーとグループの ACL エントリとデフォルトの ACL エントリ以外は削除できません。有効な ACL エントリについては、表 6–7 と表 6–8 を参照してください。
1 つまたは複数のファイルまたはディレクトリを空白で区切って指定します。
setfacl -s コマンドを使用してファイルのすべての ACL エントリを削除してから、指定した新しい ACL エントリで置き換えることもできます。
ファイルから ACL エントリが削除されたことを確認します。
% getfacl filename |
次の例では、ch4.sgm ファイルからユーザー anusha を削除します。
% setfacl -d user:anusha ch4.sgm |
getfacl コマンドを使用してファイルの ACL エントリを表示します。
% getfacl [-a | -d] filename ... |
指定したファイルまたはディレクトリのファイル名、所有者、グループ、ACL エントリを表示します。
指定したディレクトリのファイル名、所有者、グループ、デフォルトの ACL エントリ (存在する場合) を表示します。
1 つまたは複数のファイルまたはディレクトリを空白で区切って指定します。
複数のファイル名をコマンド行に指定した場合は、各 ACL エントリの間に空白行が表示されます。
次の例は、ch1.sgm ファイルのすべての ACL エントリを示します。ユーザーエントリとグループエントリの隣りの #effective: は、ACL マスクによって変更されたあとのアクセス権の設定を示します。
% getfacl ch1.sgm # file: ch1.sgm # owner: stacey # group: techpubs user::rw- user:anusha:r- #effective:r-- group::rw- #effective:rw- mask:rw- other:--- |
次の例は、book ディレクトリのデフォルトの ACL エントリを示します。
% getfacl -d book # file: book # owner: stacey # group: techpubs user::rwx user:anusha:r-x #effective:r-x group::rwx #effective:rwx mask:rwx other:--- default:user::rw- default:user:anusha:r-- default:group::rw- default:mask:rw- default:other:--- |
次の作業マップは、リスクのある実行ファイルをシステム内に見つける作業や、プログラムが実行可能スタックを不正利用しないように防ぐ作業などの操作を説明した箇所を示しています。
タスク |
説明 |
参照先 |
---|---|---|
特殊なアクセス権を持つファイルを見つけます |
setuid ビットがセットされているが、root ユーザーによって所有されていないというファイルを見つけます。 | |
実行可能スタックがオーバーフローしないように防ぎます |
プログラムが実行可能スタックを不正に利用しないように防ぎます。 | |
実行可能スタックのメッセージがログに記録されるのを防ぎます |
実行可能スタックのメッセージのログ記録を無効にします。 |
管理者はシステムを監視し、プログラム上で承認を得ることなく setuid アクセス権および setgid アクセス権が使用されていないかをチェックする必要があります。setuid アクセス権と setgid アクセス権を使用すると、通常のユーザーでもスーパーユーザー権限を取得できてしまいます。疑わしい実行可能ファイルによって、所有権が root または bin ではなく、通常のユーザーに与えられることがあります。
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
find コマンドを使用して setuid アクセス権が設定されているファイルを検索します。
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename |
指定したディレクトリから始めて、マウントされているすべてのパスを検査します。ディレクトリとしてルート (/)、sys、bin、または mail を指定できます。
root が所有するファイルを表示します。
アクセス権が 4000 に設定されているファイルだけを表示します。
find コマンドの出力を ls -ldb 形式で表示します。
find コマンドの結果が書き込まれるファイルです。
結果を /tmp/filename に出力します。
# more /tmp/filename |
setuid アクセス権の詳細については、「setuid アクセス権」を参照してください。
次の例の出力は、rar というユーザーが /usr/bin/sh のコピーを作成し、そのアクセス権を root への setuid に設定したことを示しています。この結果、/usr/rar/bin/sh プログラムは root アクセス権で実行されます。
この出力は、将来の参考にするため、/tmp ディレクトリからファイルを移動することで保存されました。
# find / -user root -perm -4000 -exec ls -ldb {} \; > /var/tmp/ckprm # cat /var/tmp/ckprm -r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at -r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab ---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct -r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir -r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin -r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched ---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh -r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df -rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp -r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd -r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su # mv /var/tmp/ckprm /export/sysreports/ckprm |
実行可能スタックのセキュリティーリスクについては、「実行可能ファイルを原因とするセキュリティーへの悪影響を防止する」を参照してください。
Primary Administrator 役割を引き受けるか、スーパーユーザーになります。
Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。
/etc/system ファイルを編集し、次の行を追加します。
set noexec_user_stack=1 |
システムを再起動します。
# init 6 |
この例では、実行可能スタックメッセージのログ記録が無効にされ、続いてシステムの再起動が行われます。
# cat /etc/system set noexec_user_stack=1 set noexec_user_stack_log=0 # init 6 |