☰

他のユーザーが自分のファイルを表示できないようにする[閉じる]

tag-icon • tag-icon ubuntu sudo root su privacy
他のユーザーが自分のファイルを表示できないようにする[閉じる]

引用:ルート/スーパーユーザーは読み取り保護されたファイルを読み取ることができますか？

私のUbuntuユーザーアカウント名は「user-3121」、タイプは「Administrator」です。タイプが「admin」の「admin」というアカウントもあります。 「admin」が自分でログインできるのか、「user-3121」で自分のファイルを表示できるのか、どうすればわかりますか？

/etc/sudoers私はこの問題を他のユーザーと議論し、私のファイルを保護するために修正を試みました。

Cmnd_Alias   SHELLS = /bin/sh,/bin/bash,/bin/ksh, /usr/bin/x11/passwd

Cmnd_Alias   SU = /usr/bin/su,/bin/su,/usr/bin/gksudo,/usr/bin/sudo,/usr/bin/su bash,/usr/bin/sudo /bin/bash,/usr/sbin/visudo

Cmnd_Alias   PASS = /usr/bin/passwd root,/bin/* * root,/bin/* * sysadmin,/bin/* * /home/sysadmin,/usr/bin/passwd

Cmnd_Alias      EDIT= /bin/* /etc/sudoers,/bin/* sudoers,/bin/* /etc/passwd,/bin/* passwd,/bin/* /etc/group,/bin/* group,/bin/* /etc/shadow,/bin/* shadow,/*/*/[a-z]* /etc/sudoers,/*/*/[a-z]* /etc/passwd,/*/*/[a-z]* /etc/group,/*/*/[a-z]* /etc/shadow,/*/*/[a-z]* sudoers,/*/*/[a-z]* passwd,/*/*/[a-z]* group,/*/*/[a-z]* shadow

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin,/usr/sbin/userdel sysadmin,/usr/sbin/deluser * sysadmin,/usr/sbin/deluser sysadmin

root    ALL=(ALL) ALL, !CMDS

%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT
%sudo  ALL=(ALL) ALL,!SHELLS, !SU, !CMDS, !PASS, !EDIT

admin ALL=(ALL) ALL
administrator ALL=(ALL) ALL

「管理者」がまだ私のデータを読み取ることができる場合、これが発生しないようにするにはどうすればよいですか？また、この設定はどのように機能しますか？ 「user-3121」はいくつかのsudoコマンドを実行できますが、実際には「user-3121」はどこにも記載されていませんか？

PS「root」ユーザーのパスワードを知っている人は私だけなので、「su」コマンドを使用してrootとしてログインできます。

答え1

さて、今これが何を意味するのか理解できます。

Cmnd_Alias   CMDS = /usr/sbin/userdel * sysadmin, ...
%admin ALL=(ALL) ALL, !SHELLS, !SU, !CMDS, !PASS, !EDIT

残念ながら、これは悪い考えです。

セキュリティの面で一般的な原則は、自分が誰であるかを説明できることです。許可する。何かをリストできる場合は意外とまれです。いいえ許可し、何も見逃さないようにしてください。

具体的に

$ cp /usr/sbin/userdel ./letsbefriends
$ sudo ./letsbefriends sysadmin

sudo su（同じ原則は、/を具体的にブロックする構成にも適用されますsudo sudo。）

肯定的な例として、次のリストを考えてみましょう。許可する「管理者」ユーザーのための作業[*]:

# admin can run `reboot`.  (They can't run e.g. `reboot --force`).
admin ALL=(ALL) reboot ""

/etc/sudoersに "user-3121"がないのはなぜですか？

良い質問です！ user-3121はsudoのメンバーですグループ。/etc/sudoers、グループはlineと一致します%sudo。

「あなたが私に見せてくれたそのトリックはかわいいですね。あなたができることはいくつかあります。しかし、あなたはそれについて議論し、一般的な原則を受け入れないようにします。

他の人は別のアイデアを思いついた。何が役に立ちますか？ [**]

$ sudo /proc/self/exe sh

以下は、ブロックするようにシステムを構成する必要がある項目の2つの異なる例です。あなたは私がよりよく知っていると信じることができます。 あなたこの複雑なカスタム構成を作成しました。複雑なシステムには必然的にエラーが含まれます。カスタムシステムを作成し、問題を解決し、メンテナンスしたいですか？通常、あなたは仕事をしたいです。そしてオペレーティングシステムをインストールすると、開発、文書化、およびサポートに入るすべてのタスクの利点を享受できます。

[*] 実際に sudo を特定の目的に限定することは思ったよりも難しいです。実際のセキュリティバリアを提供するためにsudoルールに頼ることは一般的ではないと思います。代わりに、ユーザー自身を保護しながら、特定のタスクに対する権限を委任するために使用されます。誤って大切なハードドライブやネットワークカードのファームウェアにゼロを書き込む可能性が少なくなります。

[**]スポイラー：

sudo /proc/self/exe shシェルは root ユーザーとして実行されます。

SUブロックリストにない代替ファイル名を使用してコマンド（sudo）を実行するのと同じ手法を使用して、定義されたブロックリストをバイパスします。したがって、2番目のインスタンスはsudoユーザーとして正常に実行されていますroot。公開された設定により、rootユーザーはすべてのコマンドを実行できますsudo。したがって、2番目のsudoインスタンスはrootユーザーとしてシェルを実行できます。

結果シェルはすべてのコマンドを実行するために使用できますroot。シェルはsudoを使用しないため、検索しませんsudoers。たとえば、シェルを実行しsuて、パスワードがわからない特定のユーザーとして実行されているシェルにログインできます。

答え2

簡単に言えば、「管理者」タイプのアカウントであれば何でもできると仮定する必要があります。 （下記に例示提供）

（ユーザーがブートローダーメニューまたはファームウェア構成インターフェース（BIOSセットアップ画面とも呼ばれます）にアクセスできる場合も同様です。

以下で目的のコマンドを実行できる場合ユーザーID 0（例：sudo）デフォルトでは、最初にOSをインストールしたプロセスと同じアクセスレベルを持ちます。または、次のいずれかに構造板起動可能 - すべてのファイルをバックアップしたり、アップグレードなどのためにあるドライブから別のドライブに移行できます。

一部のTPMソフトウェア（Ubuntuまたは同様に実装されていない）がない場合は、キーロガーをインストールしてパスワードをキャプチャしたり、実装した認証検証を無効にすることができます。

ユーザーごと暗号化は不正アクセスを防止します。 2年前に最後に更新されたUbuntuコミュニティドキュメントには、この機能を有効にすることができると記載されています。https://help.ubuntu.com/community/EncryptedHome

ファイルアクセスの例

たとえば、一部のユーザーはchmod 0700ディレクトリを保護することが可能だと思うようです。これは正確ではありません。動作する状況を設計できますが、それ自体では十分ではありません。 Fedora Workstation 24、ext4ファイルシステムで実行される例：

$ mkdir secret    # directory with "secret" contents
$ chmod 0700 secret    # apply access control
$ ls -ld secret    # show access control
drwx------. 2 alan-sysop alan-sysop 4096 Nov 13 20:31 secret
$ sudo -u nobody ls -l secret    # other user ("nobody") is denied access
[sudo] password for alan-sysop: 
ls: cannot access 'test': Permission denied
$ sudo ls -l secret    # but root user bypasses access controls (CAP_DAC_OVERRIDE)
total 0

答え3

さて、この質問がある人のためにチャットをまとめてみましょう。基本的に彼がしたことは、彼のホームディレクトリの権限を次に変更したことです0700（彼は読み取り/書き込み実行のみ可能です）。

chmod 0700 /ホームディレクトリ

その後、残りのチャットは管理者がsuそのユーザーを制御できないことを確認しようとしますsudo su。 （はい、通常は他の方法でファイルを取得できますが、権限はありません。）これを行うには、提供された権限を変更し、編集権限のみがあることを確認/etc/sudoersする必要があります。root/etc/sudoers

関連情報