ユーザ権限とアクセス制御 - 版の履歴

Hironobu: /* 実行権限を限定させる */

2024-02-01T14:18:05Z

実行権限を限定させる

← 古い版		2024年2月1日 (木) 14:18時点における版
268行目:		268行目:
	もちろん、Linuxがコントロールが可能であることと、		もちろん、Linuxがコントロールが可能であることと、
	アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。		アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。
	アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生する<ref>POS37-C. 権限の破棄は確実に行う【[https://www.jpcert.or.jp/sc-rules/c-pos37-c.html JPCERT/CC]】</ref>ことはいうまでもありません。		アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生する<ref>POS37-C. 権限の破棄は確実に行う【[https://www.jpcert.or.jp/sc-rules/c-pos37-c.html JPCERT/CCサイトへ]】</ref>ことはいうまでもありません。

	=== なるべくrootでは動かさない運用 ===		=== なるべくrootでは動かさない運用 ===

Hironobu: /* setgid */

2024-02-01T14:17:05Z

setgid

← 古い版		2024年2月1日 (木) 14:17時点における版
238行目:		238行目:
	</pre>		</pre>


			=== 実行権限を限定させる ===

	ruidがrootの時、つまりrootがファイルを実行した時は何でもできるので、euidをプロセス内で制限なく変更できます。		ruidがrootの時、つまりrootがファイルを実行した時は何でもできるので、euidをプロセス内で制限なく変更できます。
266行目:		268行目:
	もちろん、Linuxがコントロールが可能であることと、		もちろん、Linuxがコントロールが可能であることと、
	アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。		アプリケーションがきちんと矛盾なく利用できるように設計できることとはまったく別のことです。
	~~アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生することはいうまでもありません。~~		アプリケーションの設計が正しくなかったり、実装で間違えていると、セキュリティ侵害が発生する<ref>POS37-C. 権限の破棄は確実に行う【[https://www.jpcert.or.jp/sc-rules/c-pos37-c.html JPCERT/CC]】</ref>ことはいうまでもありません。


	=== なるべくrootでは動かさない運用 ===		=== なるべくrootでは動かさない運用 ===

Hironobu: /* ACL */

2023-02-24T06:10:02Z

ACL

← 古い版		2023年2月24日 (金) 06:10時点における版
348行目:		348行目:


	UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも現敵的な設定をすることが可能になります。		UNIXでは自分以外のユーザにアクセスを許可する場合は、グループに許可するか、それともすべてのユーザに許可するかの大まかな条件でアクセス制御をしています。一方、ACLではアクセス許可を特定のユーザの単位で、あるいはグループ単位で設定できます。ACLの導入により、これまでのUNIXのアクセス制御よりも限定的な設定をすることが可能になります。

Hironobu: /* ユーザと権限 */

2022-06-14T05:09:35Z

ユーザと権限

← 古い版		2022年6月14日 (火) 05:09時点における版
5行目:		5行目:
	またユーザは1つデフォルトのグループID(GID / GroupIDentifier)がつけられています。		またユーザは1つデフォルトのグループID(GID / GroupIDentifier)がつけられています。
	そのユーザIDやグループIDが条件に合致するかどうかでユーザに権限があるかどうかを判断しています。		そのユーザIDやグループIDが条件に合致するかどうかでユーザに権限があるかどうかを判断しています。
			<ref>
			RED HAT ENTERPRISE LINUX Identity Management ガイド
			https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/6/html/identity_management_guide/index
			</ref>

Hironobu: /* ACL */

2020-11-26T13:15:43Z

ACL

← 古い版		2020年11月26日 (木) 13:15時点における版
419行目:		419行目:
	openSUSE		openSUSE
	<ref>		<ref>
	~~openSUSE 第15章 Linuxのアクセス制御リスト~~		20 Linux でのアクセス制御リスト
	https://www.~~suse~~.~~com~~/ja-~~jp/documentation/sles10/book_sle_reference/data~~/cha.acls.html</ref>		https://www.belbel.or.jp/opensuse-manuals_ja/cha-security-acls.html
			</ref>
	やRadHat		やRadHat
	<ref>		<ref>
	~~Storage Administration Guide~~		システム管理者のガイド第5章アクセス制御リスト
	~~第19章~~ アクセス制御リスト		https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-access_control_lists
	https://access.redhat.com~~/site~~/documentation/ja-JP/~~Red_Hat_Enterprise_Linux~~/6/html/~~Storage_Administration_Guide~~/ch-~~acls.html~~
	~~</ref>~~
	~~やTurbolinux~~
	~~<ref>~~
	~~Turbolinux 11 Server: ユーザーガイド第 40章Posix ACL（Access Control List）~~
	~~http://www.turbolinux.co.jp/products/server/11s/user_guide/c15067.html~~
	</ref>		</ref>
	などのACLに関する運用ドキュメントが参考になります。		などのACLに関する運用ドキュメントが参考になります。

Hironobu: /* ディレクトリにsetgidビットを設定する */

2018-12-14T02:10:46Z

ディレクトリにsetgidビットを設定する

← 古い版		2018年12月14日 (金) 02:10時点における版
290行目:		290行目:
	=== ディレクトリにsetgidビットを設定する ===		=== ディレクトリにsetgidビットを設定する ===

	ディレクトリのグループにsetuidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。		ディレクトリのグループにsetgidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。

	<pre class="bash">		<pre class="bash">
321行目:		321行目:
	</pre>		</pre>

	ディレクトリ foo ~~に対しsetuid ビットの設定を行います。setuid~~ ビットがセットされるとグループの"x"だった部分が"s"に変化します。		ディレクトリ foo に対しsetgid ビットの設定を行います。setgid ビットがセットされるとグループの"x"だった部分が"s"に変化します。
	次にコマンド touch で fileB を作成します。		次にコマンド touch で fileB を作成します。
	ディレクトリのグループ hironobu がファイルに継承されて fileB の所有者は root グループが hironobu になります。		ディレクトリのグループ hironobu がファイルに継承されて fileB の所有者は root グループが hironobu になります。

Hironobu: /* ACL */

2018-12-13T18:15:44Z

ACL

@@ 286行目: / 286行目: @@
 apache   apache   /usr/sbin/httpd
 </pre>
 == ACL ==

Hironobu: /* ディレクトリにSGIDを行う */

2018-12-13T18:06:29Z

ディレクトリにSGIDを行う

← 古い版		2018年12月13日 (木) 18:06時点における版
159行目:		159行目:

	;考えてみよう: apacheはユーザwww-dataの権限で動作しています。cgi-binなどでコマンドを動かしファイルinfo.datに情報を書き込む必要があります。しかし、info.dataの中身に関してはセキュリティ上の問題のためユーザfoo以外には読ませたくありません(www-dataにも許可しません)。さて、この場合、info.datの適切なファイルの所有者、適切なパーミッションはどのようなものでしょうか。		;考えてみよう: apacheはユーザwww-dataの権限で動作しています。cgi-binなどでコマンドを動かしファイルinfo.datに情報を書き込む必要があります。しかし、info.dataの中身に関してはセキュリティ上の問題のためユーザfoo以外には読ませたくありません(www-dataにも許可しません)。さて、この場合、info.datの適切なファイルの所有者、適切なパーミッションはどのようなものでしょうか。

	~~=== ディレクトリにSGIDを行う ===~~

	ディレクトリのグループにsetuidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。

	~~<pre class="bash">~~
	~~$ ls -l~~
	~~合計 4~~
	~~drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:35 foo~~
	~~$ sudo touch foo/fileA~~
	~~$ ls -al foo~~
	~~合計 8~~
	~~drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:36 .~~
	~~drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..~~
	~~-rw-r----- 1 root root 0 12月 14 02:36 fileA~~
	~~</pre>~~

	~~この例は、fooというディレクトリがあり、そのディレクトリ下にコマンド touch を使いrootの持ち物である fileA を作成します。~~
	~~この時のfileAの所有者、グループともrootです。~~


	~~<pre class="bash">~~
	~~$ chmod g+s foo~~
	~~$ ls -ld foo~~
	~~drwxrws--- 2 hironobu hironobu 4096 12月 14 02:36 foo~~
	~~$ sudo touch foo/fileB~~
	~~$ ls -al foo~~
	~~合計 8~~
	~~drwxrws--- 2 hironobu hironobu 4096 12月 14 02:37 .~~
	~~drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..~~
	~~-rw-r----- 1 root root 0 12月 14 02:36 fileA~~
	~~-rw-r----- 1 root hironobu 0 12月 14 02:37 fileB~~
	~~</pre>~~

	~~ディレクトリ foo に対しsetuid ビットの設定を行います。setuid ビットがセットされるとグループの"x"だった部分が"s"に変化します。~~
	~~次にコマンド touch で fileB を作成します。~~
	~~ディレクトリのグループ hironobu がファイルに継承されて fileB の所有者は root グループが hironobu になります。~~

	== プロセスのユーザIDとグループID ==		== プロセスのユーザIDとグループID ==

Hironobu: /* グループID利用の方法 */

2018-12-13T18:05:47Z

グループID利用の方法

← 古い版		2018年12月13日 (木) 18:05時点における版
159行目:		159行目:

	;考えてみよう: apacheはユーザwww-dataの権限で動作しています。cgi-binなどでコマンドを動かしファイルinfo.datに情報を書き込む必要があります。しかし、info.dataの中身に関してはセキュリティ上の問題のためユーザfoo以外には読ませたくありません(www-dataにも許可しません)。さて、この場合、info.datの適切なファイルの所有者、適切なパーミッションはどのようなものでしょうか。		;考えてみよう: apacheはユーザwww-dataの権限で動作しています。cgi-binなどでコマンドを動かしファイルinfo.datに情報を書き込む必要があります。しかし、info.dataの中身に関してはセキュリティ上の問題のためユーザfoo以外には読ませたくありません(www-dataにも許可しません)。さて、この場合、info.datの適切なファイルの所有者、適切なパーミッションはどのようなものでしょうか。

			=== ディレクトリにSGIDを行う ===

			ディレクトリのグループにsetuidビットを設定すると、そのディレクトリ以下に作られるファイル及びディレクトリには現ディレクトリのグループが適用されます。

			<pre class="bash">
			$ ls -l
			合計 4
			drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:35 foo
			$ sudo touch foo/fileA
			$ ls -al foo
			合計 8
			drwxrwx--- 2 hironobu hironobu 4096 12月 14 02:36 .
			drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..
			-rw-r----- 1 root root 0 12月 14 02:36 fileA
			</pre>

			この例は、fooというディレクトリがあり、そのディレクトリ下にコマンド touch を使いrootの持ち物である fileA を作成します。
			この時のfileAの所有者、グループともrootです。


			<pre class="bash">
			$ chmod g+s foo
			$ ls -ld foo
			drwxrws--- 2 hironobu hironobu 4096 12月 14 02:36 foo
			$ sudo touch foo/fileB
			$ ls -al foo
			合計 8
			drwxrws--- 2 hironobu hironobu 4096 12月 14 02:37 .
			drwxrwx--- 3 hironobu hironobu 4096 12月 14 02:35 ..
			-rw-r----- 1 root root 0 12月 14 02:36 fileA
			-rw-r----- 1 root hironobu 0 12月 14 02:37 fileB
			</pre>

			ディレクトリ foo に対しsetuid ビットの設定を行います。setuid ビットがセットされるとグループの"x"だった部分が"s"に変化します。
			次にコマンド touch で fileB を作成します。
			ディレクトリのグループ hironobu がファイルに継承されて fileB の所有者は root グループが hironobu になります。

	== プロセスのユーザIDとグループID ==		== プロセスのユーザIDとグループID ==

Hironobu: /* ACL */

2018-12-13T17:49:33Z

ACL

← 古い版		2018年12月13日 (木) 17:49時点における版
298行目:		298行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	$touch foo.txt		$touch foo.txt
	$ ls -l foo.txt		$ ls -l foo.txt
	-rw-rw-r-- 1 hironobu hironobu 0 Aug 31 08:15 foo.txt		-rw-rw-r-- 1 hironobu hironobu 0 Aug 31 08:15 foo.txt
	</~~syntaxhighlight~~>		</pre>


308行目:		308行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	$ getfacl foo.txt		$ getfacl foo.txt
	# file: foo.txt		# file: foo.txt
316行目:		316行目:
	group::rw-		group::rw-
	other::r--		other::r--
	</~~syntaxhighlight~~>		</pre>


322行目:		322行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	$ chmod go-rw foo.txt		$ chmod go-rw foo.txt
	$ ls -l foo.txt		$ ls -l foo.txt
	-rw------- 1 hironobu hironobu 0 Aug 31 08:15 foo.txt		-rw------- 1 hironobu hironobu 0 Aug 31 08:15 foo.txt
	</~~syntaxhighlight~~>		</pre>


338行目:		338行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	$ setfacl -m user:www-data:r foo.txt		$ setfacl -m user:www-data:r foo.txt
	</~~syntaxhighlight~~>		</pre>


346行目:		346行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	$ getfacl foo.txt		$ getfacl foo.txt
	# file: foo.txt		# file: foo.txt
356行目:		356行目:
	mask::r--		mask::r--
	other::---		other::---
	</~~syntaxhighlight~~>		</pre>


386行目:		386行目:


	<~~syntaxhighlight lang~~="bash">		<pre class="bash">
	% ls -l foo.txt		% ls -l foo.txt
	-rw-r-----+ 1 hironobu hironobu 0 Aug 31 08:15 foo.txt		-rw-r-----+ 1 hironobu hironobu 0 Aug 31 08:15 foo.txt
	</~~syntaxhighlight~~>		</pre>