アカウント名:
パスワード:
最低限の権限で動かせば、仮にセキュリティホールがあっても被害が最小限で済むのにいまのWindowsには、サンドボックス的な機能が標準装備されてるんだからそれ使えばいいのに
Linux だって、1024 番未満のポートは “privileged port” と呼ばれてですね、root が無いと bind できないんですよ。逆に root 以外が bind できてしまったら、root より先にそのポートを bind して偽のサーバを動かすといった攻撃ができちゃうでしょ。
DNS System の port は何番だか知ってますか?答えは53番です。つまり、これを bind するには Administrators の権限がいるのは当然のことです。
最近じゃあ、*nixでは起動時だけroot権限どころか、むしろrootだと起動できないサービスの方が多い。さらに外部とやりとりするようなサービスでは、昔からchrootやjailなどで囲って起動するなど当たり前だし。qmailやpostfix、dovecotなどに代表されるように、用途に応じて多数のプロセスとユーザを使いわけ、キュー管理やロギングなどの権限が必要となるプロセスにだけroot権限を付与するやり方。POSIX Capabilityによる、単純にそのまま使うには強力すぎるroot権限の分離、seccompによるサンドボックス化などなど、root権限ひとつ使うにしてもそのまま使うことの方
どちらかというと、権限管理の設計が杜撰なのは Unix/LinuxLinuxは、全てのプロセスがrootで動いてるものから、権限を落として起動する。なので、Linuxはバグでフォールバックすると簡単にroot権限が手に入る。ログインなんかさいたる例で、root権限で動いてるプロセスがわざわざユーザー権限に落とすから、ユーザー認証する処理がrootで動いてる。
NTでは、全てのプロセス(カーネル含む)が、何の権限もない状態で起動してから、昇格して権限を得る。バグでフォールバックしても永遠にroot権限のような物は手に入らない。昇格するための穴を探す必要がある。そもそもの話 rootのような何でもありという権限も存在していない。
あと、カーネルを含む全てのプロセスが無権限から昇格しているとすれば、その昇格を認可するのは誰なんでしょ?認可無しで昇格可能なら最初から昇格済みと同じことでは?
90年代じゃないんだから、最低限度OSのお勉強しようぜ。昔は書籍ぐらいしかなかったけど、今はネットにも資料も論文も溢れてるんだから。LinuxでもTrusted OS版の実装ではWindowsの認証の仕組み採用してるよ。
その昇格を認可するのは誰なんでしょ?
それこそがカーネルだと思う。「カーネルを含む全てのプロセス」とは言うけど、アカウントの認証を行うカーネルの部分はプロセス(ユーザーモードプロセス)の外の存在と解釈すればよいのではないだろうか?
そもそもの話 rootのような何でもありという権限も存在していない。
SYSTEMアカウントってrootみたいななんでもありな存在と言っていいのでは?そりゃCAP_FOWNERみたいにファイルに対する権限ガン無視みたいな機能はないですけれど。
> rootのような何でもありという権限いつの時代の話をしているんだろう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
なんでDNSサーバをシステム権限で動かすんだ? (スコア:0)
最低限の権限で動かせば、仮にセキュリティホールがあっても被害が最小限で済むのに
いまのWindowsには、サンドボックス的な機能が標準装備されてるんだからそれ使えばいいのに
Linux だってそうでしょう (スコア:0)
Linux だって、1024 番未満のポートは “privileged port” と呼ばれてですね、root が無いと bind できないんですよ。
逆に root 以外が bind できてしまったら、root より先にそのポートを bind して偽のサーバを動かすといった攻撃ができちゃうでしょ。
DNS System の port は何番だか知ってますか?
答えは53番です。
つまり、これを bind するには Administrators の権限がいるのは当然のことです。
Re: (スコア:-1)
最近じゃあ、*nixでは起動時だけroot権限どころか、むしろrootだと起動できないサービスの方が多い。
さらに外部とやりとりするようなサービスでは、昔からchrootやjailなどで囲って起動するなど当たり前だし。
qmailやpostfix、dovecotなどに代表されるように、用途に応じて多数のプロセスとユーザを使いわけ、キュー管理やロギングなどの権限が必要となるプロセスにだけroot権限を付与するやり方。
POSIX Capabilityによる、単純にそのまま使うには強力すぎるroot権限の分離、seccompによるサンドボックス化などなど、root権限ひとつ使うにしてもそのまま使うことの方
Re:Linux だってそうでしょう (スコア:0, 参考になる)
どちらかというと、権限管理の設計が杜撰なのは Unix/Linux
Linuxは、全てのプロセスがrootで動いてるものから、権限を落として起動する。
なので、Linuxはバグでフォールバックすると簡単にroot権限が手に入る。
ログインなんかさいたる例で、root権限で動いてるプロセスがわざわざユーザー権限に落とすから、ユーザー認証する処理がrootで動いてる。
NTでは、全てのプロセス(カーネル含む)が、何の権限もない状態で起動してから、昇格して権限を得る。バグでフォールバックしても永遠にroot権限のような物は手に入らない。
昇格するための穴を探す必要がある。そもそもの話 rootのような何でもありという権限も存在していない。
Re: (スコア:0)
あと、カーネルを含む全てのプロセスが無権限から昇格しているとすれば、
その昇格を認可するのは誰なんでしょ?
認可無しで昇格可能なら最初から昇格済みと同じことでは?
Re: (スコア:0)
90年代じゃないんだから、最低限度OSのお勉強しようぜ。
昔は書籍ぐらいしかなかったけど、今はネットにも資料も論文も溢れてるんだから。
LinuxでもTrusted OS版の実装ではWindowsの認証の仕組み採用してるよ。
Re: (スコア:0)
その昇格を認可するのは誰なんでしょ?
それこそがカーネルだと思う。「カーネルを含む全てのプロセス」とは言うけど、アカウントの認証を行うカーネルの部分はプロセス(ユーザーモードプロセス)の外の存在と解釈すればよいのではないだろうか?
Re: (スコア:0)
そもそもの話 rootのような何でもありという権限も存在していない。
SYSTEMアカウントってrootみたいななんでもありな存在と言っていいのでは?そりゃCAP_FOWNERみたいにファイルに対する権限ガン無視みたいな機能はないですけれど。
Re: (スコア:0)
> rootのような何でもありという権限
いつの時代の話をしているんだろう