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


35

共有UNIXホスティングで、sensitive-data.txtファイルがあり、次を発行した場合:

chmod 600 sensitive-data.txt

rootユーザーは引き続きファイルを読み取ることができますか?具体的には、mercurial hgrcファイルにパスワードを保存しても安全かどうか疑問に思っています。

更新

設定が非常に簡単だったため、mecurialキーリング拡張機能を使用することにしました。

pip install mercurial_keyring

そしてhgrcに追加します:

[extensions]
mercurial_keyring =

しかし、私はまだこの質問の答えに興味があります。

回答:


62

はい、rootは次のことができます。

$ echo Hello you\! > file
$ chmod 600 file
$ ls -l file
-rw------- 1 terdon terdon 11 Feb 27 02:14 file
$ sudo -i
# cat file
Hello you!

いずれにしても、rootがファイルをrootとして読み取れなかったとしても、パスワードなしでいつでもログインできます。

$ whoami
terdon
$ sudo -i
[sudo] password for terdon: 
# whoami 
root
# su - terdon
$ whoami
terdon

そのため、(または)rootを使用して他のユーザー名に変更すると、自分が自分であるかのように何でもできるようになります。susudo -iu username


23

LSM(SELinux、AppArmor など)がそれをできない場合を除き、root(およびandを使用する他のユーザー/プロセス)はすべてを実行できると常に仮定します。CAP_DAC_OVERRIDECAP_DAC_READ_SEARCH

つまり、すべてのキーストロークを読み取ることができると仮定する必要があります。パスワードは本当に安全ではありません。深刻なレベルのセキュリティが必要な場合は、自分で完全に制御されているシステムを使用する必要があります(他のユーザーも使用していません)。


これは、現在実装されている機能に関する実際の問題です。それらはターゲットを指定しないので、それが起こらないようにするために、機能(SELinuxなど)に優先する型の強制が必要です。1人のユーザーCAP_DAC_OVERRIDEを与えると、システム上の他のセキュリティメカニズムをオーバーライドするために必要なすべての特権が1回のファウルで一気に付与されます。CAP_DAC_OVERRIDE基本的にCAP_DO_WHATEVER_YOU_WANTです。
ブラッチリー

10

はい、rootにはすべての権限があります

ここで、ディレクトリ名のテストを作成し、ファイルlonston.txtにタッチしてファイルをリストしたことがわかります。

root@system99:/tmp# mkdir test && touch lonston.txt && ls -l
total 4
-rw-r--r-- 1 root root    0 Feb 27 16:35 lonston.txt
drwxr-xr-x 2 root root 4096 Feb 27 16:35 test

次に、000を使用してファイルとディレクトリの権限をnull権限に変更し、権限を表示するためにリストしました

root@system99:/tmp# chmod 000 lonston.txt && chmod 000 test && ls -l
total 4
---------- 1 root root    0 Feb 27 16:35 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

それから、私はファイルに書き込み、catを使用してファイルを読み取ることができます

root@system99:/tmp# echo "Yes root have all Privileges than other user's, let we see the permission of user's too" > lonston.txt 

root@system99:/tmp# cat lonston.txt 
Yes root have all Privilages than other user's, let we see the permission of user's too

たとえ私がd ---------(null)000許可を持っているディレクトリに入っても、rootでさえ読み取りまたは書き込み許可を持っていません。

root@system99:/tmp# cd test/
root@system99:/tmp/test# pwd
/tmp/test

でも、許可の変更後にファイルとフォルダを作成できました

root@system99:/tmp/test# touch /tmp/test/lonston/testdir/babin.txt

root@system99:/tmp/test# ls -l /tmp/test/lonston/testdir/
total 0
-rw-r--r-- 1 root root 0 Feb 27 16:39 babin.txt

ここで、400の許可が表示されます。

root@system99:/tmp/test# chmod 400 babin.txt

ファイル許可を確認するリスト

root@system99:/tmp/test# ls -l
total 8
-r-------- 1 root root   34 Feb 27 16:42 babin.txt
drwxr-xr-x 3 root root 4096 Feb 27 16:38 lonston

vim im iを使用して、ファイルbabin.txtに1行追加しました

root@system99:/tmp/test# vim babin.txt

しかし、vimモードでは、W10に気付くでしょう:警告:読み取り専用ファイルを変更しますが、それでも書き込み可能です

これで、出力用にファイルをcatできます

root@system99:/tmp/test# cat babin.txt 
hi this is the write persmission 
this is added while the file have 400 permission

次に、rootユーザーから通常のユーザーにログアウトし、rootの何もnull permissonを持つファイルをリストしました

root@system99:/tmp# exit
exit

/ tmpディレクトリに移動します

sysadmin@system99:~$ cd /tmp/
sysadmin@system99:/tmp$ ls -l
total 8
---------- 1 root root   88 Feb 27 16:36 lonston.txt
d--------- 2 root root 4096 Feb 27 16:35 test

しかし、通常のユーザーからファイルを読んでいる間はできません

sysadmin@system99:/tmp$ cat lonston.txt 
cat: lonston.txt: Permission denied

sysadmin@system99:/tmp$ cd test/
cat: test/: Permission denied

それだけです、rootユーザーの力を得ることを願っています

通常のユーザーの場合、root権限が必要な場合はsudoを使用する必要があり、sudoパスワードが要求されます

例:

sysadmin@system99:/tmp$ sudo cat lonston.txt 
[sudo] password for sysadmin: 
Yes root have all Privilages than other user's, let we see the permission of user's too

sudoユーザーはrootユーザーのグループと連携しているため、sudoにはroot権限があります。

sudoの詳細

# man sudoers

ここでは、通常のユーザーがSudo権限を持つことができるように定義されていることがわかります。

sysadmin@system99:/tmp$ sudo cat /etc/sudoers

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

完全に、rootに読み取り権限がない場合でも、ファイルを読み取り、編集、または削除できます。


2
なぜこの回答にはそれほど多くの賛成票がないのですか?例で発生する可能性のあるほとんどすべてのケースをカバーしています。
フーバー

8

従来のUnixでは、ルートはすべて強力です。特に、rootは任意のファイルを読み取ることができ、プログラムが内部で行っていることをスヌープすることさえできます。データが非常に機密性の高い場合は、暗号化されたコピーのみを保持し(たとえば、GNUプライバシーガードを検討してください。ただし、ドキュメントを注意深く読んでください)、完全に制御できないマシンでは決して復号化しないでください。

(パラノイアは素晴らしいです、決して十分ではありません;-)

真剣に、データの漏洩が引き起こす可能性のあるコストを慎重に検討してください。したがって、セキュリティに対する支払いにどの程度の準備ができますか。完全なセキュリティは不可能です。もう少しセキュリティを高めるには、コストが急激に増加し始めます。しかし、実際にはセキュリティを向上させない高価な手段のtrapに陥らないように注意してください...


3

また、ハードウェアと同じ部屋にいる可能性のある人は誰でも、必要なものを読み書きできると想定する必要があります。非常に忍耐強い場合、最終的に暗号化されたデータを理解できます。暗号化ソフトウェアを置き換えることができれば、サイドチャネル方式は必要ありません。


2

はい、所有者ができない場合でも、ルートは保護されたファイルを読み取ることができます(所有者は明らかに保護を解除してからコンテンツを読み取ることができます)。

echo "123" > abc.txt
chmod 000 abc.txt
cat abc.txt

cat:abc.txt:許可が拒否されました

su
cat abc.txt

123

ただし、通常のセットアップでは、ルートはNFS(「ルートスカッシュ」)などのリモートファイルシステム上の保護されたファイルにアクセスできません。


NFSルートスカッシュに言及するための+1。ただし、NFSマウントされたディレクトリを所有しているユーザーに対してrootがsuできる限り、root squashは保護しません。
ジェニーD

2

ルートまたはいずれかがファイルを読み取れないようにするには、ファイルを暗号化する必要があります。ファイル暗号化は、複雑なファイルシステムの操作に対処する必要がない場合に検討する非常に便利なオプションです。

暗号化オプション:

  1. 通常のファイルを暗号化し、自分以外のすべてのユーザーがそれらを表示できないようにする
  2. シェルスクリプトを暗号化し、暗号化されたバージョンを実行可能にしますが、誰もがそれらを変更または表示できないようにします

オプション1を選択した場合、ファイルを暗号化する方法は次のとおりです。

cat (your-file) | openssl aes-128-cbc -a -salt -k "(specify-a-password)" > (your-file).enc

上記のファイルを復号化するには、次のようなコマンドを実行します。

cat (your-file).enc | openssl aes-128-cbc -a -d -salt -k "(specify-the-password)" > (your-file).dec

-上記をスクリプトに入れて、履歴に表示されないようにすることができます。または、「- k」パラメーターを削除するだけで、opensslがパスワードの入力を求めます。

オプション2を選択した場合は、スクリプトをコピーして次のサイトに貼り付けてください。

http://www.kinglazy.com/shell-script-encryption-kinglazy-shieldx.htm

そのサイトにスクリプトを送信すると、zipファイルがすぐに作成されます。リンクをzipファイルにコピーしてから、UNIXボックスに移動して次の手順を実行します。

  1. wget zipファイルへのリンク
  2. 新しくダウンロードしたzipファイルを解凍します
  3. cd / tmp / KingLazySHIELD
  4. ./install.sh / var / tmp / KINGLAZY / SHIELDX-(your-script-name)/ home /(your-username)-force

上記の手順を完了したら、手順4 .... ie / home /(your-username)/(your-encrypted-script)でインストールするように指定した場所から暗号化スクリプトを実行できます。 sh

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.