古い学校のシェルサーバーを数人で実行したい。1つは、ユーザーがsshアクセスを取得してソフトウェアを実行できる場所（ユーザー自身または提供）です。私の懸念は、ユーザー間の適切な分離です。

他のプロセスを表示したり、相互にファイルにアクセスしたり（明示的に許可されていない限り）などしたくないのです。すべての特権エスカレーションバグに噛まれたり、カーネルの小さな更新ごとにサーバーを再起動したりしないでください。これらのセキュリティ対策を講じて、一般的なサービス（Webやメールホスティングなど）を実行するオプションを維持することは完璧です。

昔はgrsecを使っていましたが、古いカーネルを使い続け、自分でコンパイルする手間を省く必要があります。共有サーバーでユーザーを確実に分離する、よりモダンでよりUbuntuの方法はありますか？

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

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.

したがって、/procwith hidepid=23.3 でマウントすると、Linux上の他のユーザーのプロセスの詳細を隠すのに十分です。Ubuntu 12.04にはデフォルトで3.2が付属していますが、新しいカーネルをインストールできます。Ubuntu 14.04以降はこの要件に簡単に適合します。

ACL

最初のステップとして、rwxすべてのホームディレクトリから他のユーザーのアクセス許可を削除します（必要に応じて、グループのアクセス許可も削除します）。もちろん、ホームディレクトリを含むフォルダには、root以外のユーザーに対する書き込み権限がないことを前提としています。

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

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

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

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

/tmp そして umask

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

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