web-dev-qa-db-ja.com

ddおよびfdiskコマンドからのデバイスの保護

特定のデバイスがddコマンドの出力ファイルおよびfdiskコマンドのターゲットになるのを防ぐ方法があるかどうか疑問に思っています。私は現在、2つの操作を使用して、SDカードにブートローダー、カーネル、およびルートファイルシステムを書き込むように設定しています。これは/dev/sddとして表示されます。文字以来、sddとsdb、またはsdaを混同するのではないかといつも少し心配しています。 A そして D はキーボードの近くにあり、この形式のコマンドを防ぐ方法を見つけたいと思います。

dd if=/dev/sd[a-zA-Z0-9]* of=/dev/sd[ab]

または

fdisk /dev/sd[ab]
linuxcommand-linehard-diskddfdisk
8
sj755

Udevルールを記述して、補足HDDに十分に一意の名前を付けることができます。

別のアイデア：セキュリティ要件を「誰がやっているのかではなく、彼らがどのようにやっているのか」と表現できるときはいつでも、タイプエンフォースメントについて話しているので、ほとんどのLinuxディストリビューションではTEはMACレベルで行われます。私のMAC経験のほとんどは「SELinux」に関するものです

DACレベルでロックダウンすることはできません。そうしないと、デバイスでI/Oを実行できません（必ずしもセキュリティモデルとしてのDACの障害ではなく、現在のDACポリシーはIDベースであるため、すべてのプログラムが特定のIDで実行すると、追加の管理表現がなくても同一の権限が取得されます）。 MACレベルでロックダウンして、通常のユーザースペースコンポーネントがブロックファイルに対して何も実行できないようにすることができますが、ルートユーティリティとプラットフォームの特定の部分は実行できます。 Fedoraでは、これはすでに、ブロックデバイスがSELinuxタイプのfixed_disk_device_tで表示され、grubがbootloader_exec_tを持っている場合の一種です。次の例を参照してください。

[root@localhost ~]# ls -lhZ $(which grub2-install)
-rwxr-xr-x. root root system_u:object_r:bootloader_exec_t:s0 /sbin/grub2-install
[root@localhost ~]# ls -lhZ /dev/sda
brw-rw----+ root disk system_u:object_r:fixed_disk_device_t:s0 /dev/sda
[root@localhost ~]# sesearch --allow | egrep bootloader | grep fixed
   allow bootloader_t fixed_disk_device_t : lnk_file { read getattr } ; 
   allow bootloader_t fixed_disk_device_t : chr_file { ioctl read write getattr lock append open } ; 
   allow bootloader_t fixed_disk_device_t : blk_file { ioctl read write getattr lock append open } ; 
[root@localhost ~]#

ddには通常のbin_tラベルがありますが、

[root@localhost ~]# ls -lhZ $(which dd)
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /bin/dd

bin_t（どうやら）はブロックデバイスに書き込むことができますが、fdiskとddの新しいファイルコンテキストタイプを作成し、新しいタイプがfixed_disk_device_tにアクセスできないようにするselinuxルールを作成することはそれほど難しくありません。 。通常のユーザーロールでは実行できないようにする必要がありますが、sysadm_tを持つユーザーは実行できます。その後、ディスクのパーティションを再作成する前、またはddを実行する前に、newrole -r root:sysadm_rを実行することを忘れないでください。ブロックデバイス上で（1日中毎日fdiskを実行するわけではないので、大したことではないはずです）。

おそらくあなたが探していたよりも多くの作業がありますが、TEはあなたが直面している一般的な問題を解決するメカニズムです。個人的には、udevルールがおそらく最も安全な賭けです。これに似た問題のより大きなセットを解決することに興味がある場合にのみ、TEのものについて言及します。

5
Bratchley

/dev/sdxがわからない場合は、/dev/disk/にある別のデバイス名を使用してください。

たとえば、私のSDカードリーダーは/dev/disk/by-id/usb-TS-RDF5_SD_Transcend_000000000011-0:0です。確かにそれは少し冗長ですが、少なくともHDDと混同する方法はありません。

あるいは、hdparm -i /dev/sdxは、ハードディスクの場合に役立つ情報を表示し、不幸な事故を回避するのに役立つ場合があります...

4
frostschutz

/dev/disk/by-*にはもっと長く意味のある名前があります。ディスク全体の場合、/dev/disk/by-idには、ディスクモデルとシリアル番号を含むディスクデバイスへのシンボリックリンクが含まれます。

保護を強化するには、デバイスにアクセスするためのアクセス許可を自分に与え（例：Sudo chown sj755 /dev/disk/by-id/ata-Yoyodine-50RDF15H）、残りはrootではなく自分のユーザーで行います。

操作するディスクに期待されるコンテンツが含まれていることを再確認してください。 fdisk -l /dev/whatever、file - </dev/sdz99、…を確認してください。シェルでは、 Esc. 前のコマンドの引数を呼び出すために、デバイス名を再入力しないでください。

3
Gilles 'SO- stop being evil'

それを達成するための2つの方法があります。

  1. ラッパー（シェル関数）を作成し、実際のプログラムに渡す前に引数を確認します。
  2. これらの操作は、SELinux、AppArmorなどによって制限されているシェルから実行してください。
1
Hauke Laging