☰

hidepid

tag-icon • tag-icon server kernel ssh security multi-user
hidepid

私は数人のために昔ながらのシェル サーバーを実行したいと考えています。つまり、ユーザーが SSH アクセスを取得してソフトウェア (独自のものまたは提供されたもの) を実行できるようなサーバーです。私が懸念しているのは、ユーザー間の適切な分離です。

明示的に許可されていない限り、お互いのプロセスを表示したり、お互いのファイルにアクセスしたりすることは望ましくありません。権限昇格のバグに悩まされたり、カーネルのマイナー アップデートごとにサーバーを再起動したりしなくて済むと良いのですが。これらのセキュリティ対策を講じた上で、一般的なサービス (Web やメール ホスティングなど) を実行するオプションを維持できれば完璧です。

昔は grsec を使用していましたが、古いカーネルを使い続け、自分でコンパイルする手間をかける必要がありました。共有サーバー上でユーザーを分離するための、より現代的で Ubuntu らしい方法はありますか?

おそらく、AppArmor を使ってその効果を実現できるでしょうか? あるいは、共有環境用に事前構成されたカーネルのリポジトリがあるでしょうか? あるいは、コンテナーに基づくソリューションでしょうか? これらは最近流行しています。

答え1

hidepid

procfsLinuxではhidepidオプションがサポートされるようになりました。man 5 proc:

hidepid=n (since Linux 3.3)
      This   option   controls  who  can  access  the  information  in
      /proc/[pid]  directories.   The  argument,  n,  is  one  of  the
      following values:

      0   Everybody  may  access all /proc/[pid] directories.  This is
          the traditional behavior, and  the  default  if  this  mount
          option is not specified.

      1   Users  may  not  access  files and subdirectories inside any
          /proc/[pid]  directories  but  their  own  (the  /proc/[pid]
          directories  themselves  remain  visible).   Sensitive files
          such as /proc/[pid]/cmdline and /proc/[pid]/status  are  now
          protected  against other users.  This makes it impossible to
          learn whether any user is running  a  specific  program  (so
          long  as  the program doesn't otherwise reveal itself by its
          behavior).

      2   As for mode 1, but in addition the  /proc/[pid]  directories
          belonging  to other users become invisible.  This means that
          /proc/[pid] entries can no longer be used  to  discover  the
          PIDs  on  the  system.   This  doesn't  hide the fact that a
          process with a specific PID value exists (it can be  learned
          by  other  means,  for  example,  by "kill -0 $PID"), but it
          hides a process's UID and  GID,  which  could  otherwise  be
          learned  by  employing  stat(2)  on a /proc/[pid] directory.
          This greatly complicates an  attacker's  task  of  gathering
          information   about  running  processes  (e.g.,  discovering
          whether some daemon is  running  with  elevated  privileges,
          whether  another  user  is  running  some sensitive program,
          whether other users are running any program at all,  and  so
          on).

gid=gid (since Linux 3.3)
      Specifies  the  ID  of  a  group whose members are authorized to
      learn  process  information  otherwise  prohibited  by   hidepid
      (ie/e/,  users  in this group behave as though /proc was mounted
      with hidepid=0.  This group should be used instead of approaches
      such as putting nonroot users into the sudoers(5) file.

したがって、Linux > 3.3 では、マウントする/procだけでhidepid=2他のユーザーのプロセスの詳細を隠すことができます。Ubuntu 12.04 にはデフォルトで 3.2 が付属していますが、新しいカーネルをインストールすることもできます。Ubuntu 14.04 以上は、この要件を簡単に満たします。

ACL について

最初のステップとして、rwxすべてのホーム ディレクトリから他のユーザーの権限を削除します (必要な場合はグループについても削除します)。もちろん、ホーム ディレクトリを含むフォルダーには、ルート以外のユーザーに対する書き込み権限がないものと想定しています。

次に、ACL を使用して、Web サーバーやメール サーバーなどのサービスに適切なディレクトリへのアクセスを許可します。たとえば、 がwww-dataユーザーであり、~/public_htmlにホームページが保存されていると仮定して、Web サーバー プロセスにユーザーのホームページへのアクセスを許可するには、次のようにします。

setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html

同様に、メール プロセスとメールボックス ディレクトリの ACL を追加します。

少なくとも Ubuntu 14.04 以降では、ACL は ext4 でデフォルトで有効になっています。

/tmpそしてumask

もう 1 つの問題は です/tmp。 を設定してumask、ファイルがグループまたは世界で読み取り不可になるようにし、ユーザーの一時ファイルに他のユーザーがアクセスできないようにします。

これら 3 つの設定により、ユーザーは他のユーザーのファイルにアクセスしたり、そのプロセスを調べたりすることができなくなります。

関連情報