タグ

Unixとセキュリティに関するslay-tのブックマーク (5)

  • WindowsのACL(Access Control List)を解説する【準備編】 (1/2)

    今回から複数回に分けて、WindowsのAccess Control List(ACL、アクセス制御リスト)を解説することにする。ACLは、Windowsの中でも面倒な部分の1つで理解しなくても特に困るというものでもないが、複雑なファイルアクセス権の管理(あの人たちにファイルを見せたくないけど、自分たちは編集できる)をする場合、避けて通れないことがある。 ACLが面倒なのは、Windowsでは直接見えにくいものだからだ。ただし、すべてのオブジェクトのACLを説明することはかなり大変なので、ここでは対象をファイルシステム(ファイルとディレクトリ)に限定することにする。と言っても、ファイルシステム固有の部分があるだけで、基はどのACLも同じである。 Windowsでファイルやディレクトリにアクセスできないことがあるが、それはアクセス権を持っていないから。それぞれのファイルやディレクトリに対す

    WindowsのACL(Access Control List)を解説する【準備編】 (1/2)
  • セキュリティホール memo

    復刊リクエスト受付中: ジェイムズ.F.ダニガン「 新・戦争テクノロジー」(現在58票) 中山信弘「ソフトウェアの法的保護」 (現在112票) (オンデマンド購入可) 陸井三郎訳・編「ベトナム帰還兵の証言」 (現在109票) 林克明「カフカスの小さな国 チェチェン独立運動始末」 (現在175票) 田中徳祐「我ら降伏せず−サイパン玉砕戦の狂気と真実」 (復刊決定) RSS に対応してみました。 小ネタは含まれていません。「政治ねたウゼェ」という人は RSS ベースで読むと幸せになれるでしょう (ウザくない人は こっちの RSS がよいかもしれません)。 RSS 1.0 ですので、あくまで RDF Site Summary です。 現在は Really Simple Syndication には対応していません。 今すぐ Really Simple Syndication がほしい人は、のい

  • 混沌を極めるWindowsのssh-agent事情 - Qiita

    どうしてこうなった。 何の話? WindowsでのSSH-AGENTとSSHの話です。 この記事での用語: SSHとssh, SSH-AGENTとssh-agent この記事では、SSH-AGENTと書いたときにはカテゴリとしてのSSHエージェントを意味します。 ssh-agentと書いたときには、実行プログラムとしてのssh-agentコマンドを意味します。 同様に、SSHと書いたときにはカテゴリとしてのSSHクライアントを意味します。 sshと書いたときには、実行プログラムとしてのsshコマンドを意味します。 SSH-AGENTって? SSH-AGENTは、秘密鍵での署名を代行1してくれるツールです。 SSH-AGENT に秘密鍵をロードしてしまえば、あとはパスワード(パスフレーズ)入力なしでSSH認証できる agent forward機能を使うことで、SSHした先でさらにSSHすると

    混沌を極めるWindowsのssh-agent事情 - Qiita
  • ssh-agent のしくみ - eagletmt's blog

    ssh-agent のように daemon として起動し秘密の情報を保持しつつ別プロセスと通信するようなプログラムを書きたくて、ssh-agent はどう実装しているのかざっくり調べた。 https://github.com/openssh/openssh-portable 通信方法 これは普通に ssh-agent を使っていてもすぐ気付くことだけど、ssh-agent は UNIX domain socket を使って通信している。 eval $(ssh-agent) のように実行すると SSH_AUTH_SOCK と SSH_AGENT_PID の2つの環境変数がセットされ、SSH_AUTH_SOCK は UNIX domain socket のパスを、SSH_AGENT_PID は daemon 化した ssh-agent の pid を指している。 SSH_AUTH_SOCK は

    ssh-agent のしくみ - eagletmt's blog
  • Unix系OSの権限分離の変遷について(もしくはなぜ、アプリ単位の権限分離が求められるようになったか)

    Unix系OSの権限分離の変遷について(もしくはなぜ、アプリ単位の権限分離が求められるようになったか) [ブコメした件について。大筋でおかしなことは書いてないと思いますが、出典は確認していません] Unix系OSにおける権限分離は、伝統的に、利用者ごとに異なるuser idを割り振り、これを用いてアクセス制御を行うという方式で実現されてきた。また、デーモンプロセスについては、不要な権限付与を避け、デーモンプロセス間の相互作用を抑制するために、デーモンごとに専用の「user id」を発番するのが一般的な慣習とされるようになったという経緯がある。 しかし、2000年代に入ると、インターネットの普及とあいまって、クライアントサイドではこのような「利用者ごと」の権限分離では不十分という考え方がされるようになってきた。具体的には、 (オンラインバンクのパスワードに代表されるような)攻撃価値が高い情報

  • 1