問題タブ [linux-capabilities]

プロセスが機能するために必要な Linux の機能がわからないという困難な状況にあります。必要なキャップを見つけるための最良の方法、または方法は何ですか?

私が今考えることができる唯一のことは、capsh を使用して、プロセスですべての大文字を削除することです。その後、プロセスは失敗し、機能するまで (--drop=CAP_XZY を削除して) キャップの追加を開始します。

より良い提案はありますか？

特に Linux/POSIX の世界では、一時的な初期化のみを目的として (たとえば、root が所有する秘密鍵ファイルを読み取る、1024 未満のポートを開く、またはリソース制限を引き上げる) ための root 機能を必要とするデーモンは、多くの場合、setuid()/setresuid()やsetgid()/などの関数呼び出しで資格情報を変更しsetresgid()、呼び出しfork()て実際のプログラムをその子として実行する設計パターンに従います。fork()-ing は「万が一に備えて」行われると思われますが、そうするための実際のセキュリティ上の考慮事項は何ですか?

setgroups(0, NULL)そして、それをフォローアップするために、( 、setresgid(GID_NOBODY, GID_NOBODY, GID_NOBODY)およびに加えて) プログラムがLinux の機能setresuid(UID_NOBODY, UID_NOBODY, UID_NOBODY)を積極的に制限している場合、その理由はまだ関連していますか?cap_set_proc()

CAP_NET_ADMINPython アプリケーションで特定のサブプロセスの機能を設定したいと考えています。私はそうするために多くのことを試みましたが、例が利用できないため成功しませんでした。

私がしたことはprctl.capbset.drop("setgid", prctl.CAP_NET_ADMIN)、サブプロセスを作成する直前に、pipを使用して提案されたように python-prctl(1.6.1) と prctl(1.0.1) をインストールし、アプリケーションに実装したことです。しかし、それさえもcapbset認識できないようです。

サブプロセスでは、scapy を使用してネットワークを盗聴したいと考えています。

以下のように私のアプリを実行します：

sudo rkt run --insecure-options=image --interactive --net=host ./myapp.aci

メッセージが表示されます：

メモリのロックに失敗しました: メモリを割り当てることができません

CAP_IPC_LOCK掘り下げた後、コンテナに機能が渡されていないことが示されているように見えます。いくつかのドキュメントを掘り下げましたが、構成を追加する必要がある場所や、これを有効にするオプションが見つかりません。どうすればいいですか？

コンテナーを特権モードで実行している場合、すべてのカーネル機能を備えていますか、それとも個別に追加する必要がありますか?

私はさまざまなホストで Docker を使用しています: RHEL7 、SELS12 および CentOS7 で、CentOS7 で Docker ホストとして実行されているコンテナーでは、SLES12 または RHEL7 で Docker ホストとして実行されているコンテナーと比較して、異なる動作が見つかりました。

異なる動作は、Docker コンテナーの一般的な問題に関連しています: https://github.com/docker/docker/issues/7147
https://github.com/docker/docker/issues/6800

Docker ホストとして CentOS7 を使用するコンテナー内:

パスのシンボリックを解決する権限があります: /proc/1
コマンド:ls -la /proc/1

コンテナの開始コマンド:

ただし、Docker ホストとして SLES12 または RHEL7 を使用するコンテナーでは:

上記のリンクでわかるように、同じコマンドで許可が拒否されます。
指図：ls -la /proc/1

追加情報：

Docker のセキュリティ ドキュメントに依存している ため、コンテナはデフォルトで制限付きの Linux カーネル機能セットで開始されます。

これらの機能の 1 つ: CAP_SYS_PTARCE
この機能は、デフォルトで任意の Linux ホスト マシンに存在します:

Linux マシンの例:

しかし、すべてのコンテナーでは、デフォルトで欠落しています (コンテナー を --cap-add=sys_ptrace で開始しない限り) 。

したがって、Docker ホストとして RHEL または SLES で --cap-add=sys_ptrace を使用してコンテナーを開始すると、CentOS 7 で Docker ホストとして取得するのと同じ動作になります。

例: Docker ホスト: RHEL7
Docker イメージ: centos:latest (前と同じ)
Strat command: docker run -it --name=nessi_centos_test5 --cap-add=sys_ptrace centos:latest bash

ここでわかるように、CentOS 7 と同じ動作を得るには、追加の sys_ptrace 機能を使用してコンテナーを開始する必要があります。

技術的な案内：

1. CentOS 7 の異なる動作: コンテナーでコマンドを実行:
   ls -la /proc/1
   結果: エラーなし
2. 他のホスト (RHEL7 および SLES12) の通常の動作 コンテナーでコマンドを実行:
   ls -la /proc/1
   結果:

ls: cannot read symbolic link /proc/1/cwd: Permission denied ls: cannot read symbolic link /proc/1/root: Permission denied ls: cannot read symbolic link /proc/1/exe: Permission denied

1. CentOS 7 の異なる動作は、以下で再現されています。
   

[root@localhost Desktop]# uname -a
Linux localhost.localdomain 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost Desktop]# docker info
Containers: 1
Running: 0 Paused
: 0
Stopped: 1
Images: 1
Server Version: 1.11.2
Storage Driver: devicemapper
Pool Name: docker-253:0-136686025-pool
Pool Blocksize: 65.54 kB
基本デバイス サイズ: 10.74 GB
バッキング ファイルシステム: xfs
データ ファイル: /dev/loop0
メタデータファイル: /dev/loop1
使用されるデータ スペース: 324.3 MB
データ スペースの合計: 107.4 GB
使用可能なデータ スペース: 35.43 GB
メタデータ 使用されるスペース: 847.9 kB
メタデータ容量の合計: 2.147 GB
利用可能なメタデータ容量: 2.147 GB
Udev 同期のサポート: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0データ ループ ファイル: /var/lib/docker/ devicemapper
/devicemapper/data を使用するか、この警告を抑制するために使用します。 メタデータ ループ ファイル: /var/lib/docker/devicemapper/devicemapper/metadata ライブラリ バージョン: 1.02.107-RHEL7 (2016-06-09) ロギング ドライバー: json-file Cgroup ドライバー: cgroupfs プラグイン: ボリューム: ローカル ネットワーク: null ホストbridge カーネル バージョン: 3.10.0-327.22.2.el7.x86_64 オペレーティング システム: CentOS Linux 7 (コア) OSType: linux

--storage-opt dm.thinpooldev--storage-opt <br>dm.no_warn_on_loop_devices=true










アーキテクチャ: x86_64
CPU: 1
合計メモリ: 993.3 MiB
名前: localhost.localdomain
ID: BPVJ:YDPR:4VUO:WNBN:DVZH:7MEH:TPMP:Y3MP:GMN7:UT36:LQ74:GJ4N
Docker ルート ディレクトリ: /var/lib/ docker
デバッグ モード (クライアント): false
デバッグ モード (サーバー): false
レジストリ: https://index.docker.io/v1/
警告: bridge-nf-call-iptables は無効です
警告: bridge-nf-call-ip6tables は無効です無効

Docker イメージ:
centos:latest
ubuntu:14.04

また、テスト済み:
Docker デーモン バージョン: 1.10.2

2. 他のホスト (RHEL7 および SLES12) の通常の動作
   
   RHEL7 を Docker ホスト:
   
   [root@localhost ~]# uname -a
   Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
   
   [root@localhost ~]# docker info
   Containers: 14
   Running: 6 Paused
   : 0
   Stopped: 8
   Images: 22
   Server Version: 1.11.2
   Storage Driver: devicemapper
   Pool Name: docker-253:0 -67168288-pool
   プール ブロックサイズ: 65.54 kB
   基本デバイス サイズ: 10.74 GB
   バッキング ファイルシステム: xfs
   データ ファイル: /dev/loop0
   メタデータファイル: /dev/loop1
   使用されるデータ領域: 9.66 GB
   データ容量の合計: 107.4 GB
   利用可能なデータ容量: 16.27 GBメタデータ容量の使用 :
   7.68 MB
   メタデータ容量の合計: 2.147 GB 利用 可能なメタデータ容量 :
   2.14 GB 0 データ ループ ファイル: /var/lib/docker/devicemapper/devicemapper/data 警告: 本番環境でのループバック デバイスの使用は強くお勧めしません。を使用するか、この警告を抑制するために使用します。 メタデータ ループ ファイル: /var/lib/docker/devicemapper/devicemapper/metadata ライブラリ バージョン: 1.02.107-RHEL7 (2015-12-01) ロギング ドライバー: json-file
   
   
   
   
   
   
   --storage-opt dm.thinpooldev--storage-opt dm.no_warn_on_loop_devices=true
   
   
   
   Cgroup ドライバー: cgroupfs
   プラグイン:
   ボリューム: ローカル
   ネットワーク: null ホスト ブリッジ
   カーネル バージョン: 3.10.0-123.el7.x86_64
   オペレーティング システム: Red Hat Enterprise Linux
   OSType: linux
   アーキテクチャ: x86_64
   CPU: 2
   合計メモリ: 1.798 GiB
   名前: localhost .localdomain
   ID: VL2V:RUOZ:U55X:OCEQ:MAS6:MXYV:CKUY:WJQY:3KH3:LWPW:LUYH:E3MM
   Docker ルート ディレクトリ: /var/lib/docker
   デバッグ モード (クライアント): false
   デバッグ モード (サーバー): false
   レジストリ: https://index.docker.io/v1/
   警告: bridge-nf-call-iptables が無効です
   警告: bridge-nf-call-ip6tables が無効です
   
   
   Docker イメージ:
   centos:latest
   centos:7
   ubuntu:14.04
   ubuntu:latest
   rhel:latest
   suse/sles12:latest (SLES マシンでビルドされ、RHEL にコピーされたイメージ)
   
   以下でもテスト済み:
   Docker デーモン バージョン: 1.10.3。1.9
   
   
   Docker ホストとしての SLES12:
   
   

linux-ojix:~ # uname -a
Linux linux-ojix 3.12.28-4-default #1 SMP Thu Sep 25 17:02:34 UTC 2014 (9879bd4) x86_64 x86_64 x86_64 GNU/Linux

linux-ojix:~ # docker info
Containers: 6
Running: 3 Paused
: 0
Stopped: 3
Images: 10
Server Version: 1.10.3

Storage Driver: btrfs
Build Version: Btrfs v3.18.2+20150430
Library Version: 101
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: bridge null host
Kernel Version: 3.12.28-4-default
Operatingシステム: SUSE Linux Enterprise Server 12
OSType: linux
アーキテクチャ: x86_64
CPU: 2
合計メモリ: 1.853 GiB
名前: linux-ojix
ID: NU4F:MOFR:RTUA:F2OM:4G67:NMGV:76S6:BONN:ASD5:XGHF:KVJQ: N242
WARNING: No swap limit support


Docker images:
centos:latest
centos:7
ubuntu:14.04
ubuntu:latest
suse/sles12:latest



Docker ホストとしての CentOS が他のホスト OS (コンテナー内の ls –la /proc/1 - 許可拒否エラーあり) と比較して異なるコンテナー動作 (コンテナー内の ls –la /proc/1 - エラーなし) を引き起こす理由を誰もが理解していますか? )?

スクリプトに cap_net_bind_service Linux 機能を付与しようとしています。ただし、setcap の使用は機能していないようです。

sudo を使用しても問題なく動作します。

これは Fedora 23 ワークステーションにあります。

この時点で少し迷っており、firewalld をオフにしようとしても効果がなく、これをデバッグする方法がわかりません。