アカウント名:
パスワード:
一受託業者が決めるべき問題じゃないね。そのシステムのセキュリティポリシに従って決まる。
より良いシステムになるよう助言はした方がよいと思うけどね。
ところで、これって、サーバ(やクライアント)毎のパーソナルファイアウォールの話だよね。設定できるなら、設定した方がいいとは思うね。しかし、ネットワークで適切に守られていれば、それで十分と言う考え方もある。それこそセキュリティポリシだ。
パーソナルファイアウォールと同様の問題で、SELinuxをどうするか、って話はあるよね。SELinuxを無効にしてるのをよく見るけど…
具体例として取り上げて申し訳ないんだけど「Hinemos」がまさにそうで、開発元となったNTTデータの説明でしっかりと「SELinuxを無効化します。」と書いてある。SELinux有効では動作しないのか、それとも手順書上そうなってるだけなのか、検証した人はいないのだろうか。
単に、SELinuxを設定するノウハウが無いとか、NTTにはあってもユーザにはなくて、サポート経費を考えると、そうせざるを得ない、とか。
まぁ手抜きだよね。適切なポリシーと一緒に配置すれば動作しないわけがない。
ただ、ファイルパスとかもポリシーに入っているわけで、標準と違うパスにファイル配置したければポリシーだのラベルだの調整しなければいけない。それを説明するのが面倒だから無効にしないと動かないと言ってるだけだ。（本一冊になるようなことをただで教えろと言われるし）
ちょっと書き忘れた。
たいていの場合、ドキュメントレベルではSELinuxサポートしません！と書いてあっても中にポリシーファイルついてるのでは。サクっとコンパイルしていれときゃ問題ない。
あー、もう一つおもいだした
＞SELinux有効では動作しないのか、それとも手順書上そうなってるだけなのか、検証した人はいないのだろうか。
こんなもの、聞くまでもなく自分でためしゃいいじゃねぇか、っていうのもコメントつかないほどSELinuxって使い方だれも知らないのな。
permissiveモードで起動するように設定して動かすとポリシー違反があったことが報告されるけどプロセスの動作はブロックされない。そうやって、AVC（違反報告）を集めてポリシーを作る。ただ、一から作るのは結構大変だし、全部網羅したという確証もないのでパッケージについてるのがないか探すのが吉。
＃SELinuxは初めて有効になったときファイルにラベルというものを付けるので起動に時間かかるよ。
それを開発元が検証した上でドキュメントを作ればよかったんじゃないかな。なんで手抜きにしちゃったんだろう。オープンソースなんで自分で好きにやれってのは分かるんですがね。
＞ただ、ファイルパスとかもポリシーに入っているわけで、標準と違うパスにファイル配置したければポリシーだのラベルだの＞調整しなければいけない。
これに尽きると思う。たとえばログファイルのディレクトリ変えました、とか、リッスンするポート番号変えました、といったものでも（たとえ設定者は大したことではないと思っていても）SELinuxにとっては重大なポリシー違反なのでそのプロセスは動きません。
変に動きますというと、自分で設定いじった癖に”うごかねーじゃねぇえか”、というウマシカ君たちが騒ぐので放っておくしかない。そんな奴らの相手をするくらいなら”デフォでオフでしょJK”とか言わせておく方がいい。
同意。
たまに「iptablesやSELinuxは無効にするのが常識」って言う人が居るのだけど、そういうのにはちょっと腹が立つ。自分たちが理解できてない、制御出来ないシロモノだからやむなく無効にしてるんであって、本来は、ちゃんと理解して必要な許可設定を行うべきだと思う。
OS標準ソフトウェアだけなら、大抵SELinux有効でなんとかなるね。
問題は、サードパーティーのソフトウェア製品を入れる場合。その製品の要件に「SELinux無効」とか書いてあったり…困ったもんだ。
＞本来は、ちゃんと理解して必要な許可設定を行うべきだと思う。
SELinuxをちゃんと理解して設定できるレベルの技術者を集められるプロジェクトは世間の1%も無いよ。 無効が常識とか言うレベルはアレだけど、現実的にはソコソコ理解している(理解できる)メンバが中心になるので、テスト期間が十分に取れて後で責任を押し付けられないなら設定しても良いけど、ギリギリ納期で開発が終われば、ほとんどのメンバが消えるような現場が多い現状では無効にするのが現実解だと思うしかない。
DとかIとかFとかNの命令するだけの一次受け企業担当者は「本来は、ちゃんと理解して必要な許可設定を行うべき」とか良く口にするけど、それができるメンバがいないのだから下請けいじめでしかない。現実を見ず正論を振りかざして作業を押し付ける現場ばっかりだから、作業は減らないんだよなー。
>命令するだけの一次受け企業担当者は「本来は、ちゃんと理解して必要な許可設定を行うべき」とか良く口にするけど
いや、それを口にしない奴はヤバイだろ。
いや、下請けとしては一番ヤバイ状況じゃないの？口は出すけど金は出さない。口は出したので責任は押し付けたということでしょ？口に出さないならこちらが提案なりすればいいだけ
その通りで、「お前んとこが提示した単価じゃ無理だよ」ってのばっかりです。んでこれを言い続けると、「じゃよそに頼むわ」つってやってるフリしているところに仕事が行き、向こうも知っていながら単価安く上げたいから黙認して、後になって問題がでて、「やってるって言ったよな？」って言う。下請けに責任を押し付けてその場を逃げても信用ってのは戻ってこないんですけどね。まあ信用と単価を天秤にかけて信用取るのはお役所ぐらいになってきましたけど。
夏休みになるとこう言う知ったかぶりな人が増えるなあ。DとIは知らんけど少なくともFとNとNとHはグループ(企業)全体のテンプレでSELinuxはデフォルトOFFになってるよ。FWはON。勿論プロジェクトごとにポリシー上書きしてONには出来るけど、各社のツールとかがOFFが前提になってたりするから、普通はONにしない。後、これは噂と言うか都市伝説レベルの与太話かもだけど、SELinuxはNSAがらみで各社何か情報を掴んでるからOFFになっているんじゃないかと言う話も聞いた事がある。
無効化しなければならない理由が明確にあるのならその選択肢もありうる。しかし面倒を避けるため、ってだけなら唯の手抜きだしそれ自体は僅かで他が問題なければ影響ないとしても確実にセキュリティ下げてはいるんでそのリスクと何を比べた判断なのか次第だと思う
手抜きだと一概に言えないほどSELinuxはひどいでしょ。意図的にわかりにくく設定しづらくしてセキュリティを高めているつもりなのかと勘ぐりたくなる。技術、知識、意識がうんぬんと言うより新しいアクセス制御のソフトをつくった方がましに思える。
SELinuxの連中(NSA)が新しいアクセス制御ソフトの導入を全力で妨害していたのをブチ切れて解決してくれたLinusさんマジイケメン
つまりTOMOYO Linuxを有効にすればいい。さすがに仕事では使ったこと無いけど、個人で運用してたサーバには使ってたな。
AppArmorとかどうですか?
そのリスクと何を比べた判断なのか次第だと思う
大抵の場合は単なる手抜き、というのは同意として。
リスクと管理負荷を比べた判断、という言い訳はよく聞くね。
言い訳じゃなくて、適切な判断だと思いますよ。それこそセキュリティポリシでしょ?
言い訳じゃなくて、適切な判断だと思いますよ。
適切な判断のケースもあるし、そうでない場合もあるよ。
例えば、ちゃんと調査して設定すればOKなのに、工期を確保できないがために、「リスクと管理負荷を比べた判断」ということにした、というケースがある。受託業者も工数が減るし、委託側も工期を守れるなら、と結託した結果そーなるケースね。
「ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない」だって適切な判断なのに、そういう誤摩化しをする人の考え方がよくわからない。
ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない
結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。実は、調査する気もその能力もない、って話だったりするとなおさら。
あと、前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃいけなくなっちゃうから、とかね。
セキュリティが十分かどうかの説明は当然するよね。妥当かどうかは顧客が決める。
顧客と一口に行っても、一体ではないからね。誰が誰に説明するのか、って問題になる。業者が直接付き合うのは、IT部門の担当者で、会社の経営層に説明するのは、そのIT部門のトップだったり。そーなると、みょーな社内力学とかが働いたりして。
委託される側が社内力学の事まで気を遣うのが過剰なんでしょうね。私の場合は「期間と金があれば出来るが、懐事情は分かっている。社内向けの説明はよろしく」で通しているけど問題になったことはないですね。稀なケースではあるけど顧客の経営陣へ説明する場合も、正直に言う。判断するのはその人たちの役目で、そのための情報に嘘を混ぜてもろくな事にならない。金も期間もくれないところとは、どうせ将来的にもうまくやれないので早期撤収するという自社ポリシーのおかげでもありますが。
そもそも安全性を第一に考えるなら専用の閉じたネットワークでやれとか色々とコスト度外視のことをやらなければならずじゃあどこまで安全性を犠牲にしてコストを優先するか？ってのが考え方の基本であってセキュリティ第一が基本の考え方じゃないしねセキュリティとコストのバランスについては客に従うべきだよねその責任とお金は客が負担するものなんだし
ＮＴＴデータのCAFIS系の提案では必ずFWとSELinuxも盛り込んでいるが管理運用できない理由からSELinuxはおおむね対象外にされていた。構築できても維持できないのなら致し方ないか。
SELinux なんてあんな組織が関係してるもの有効にするわけないじゃないですか ;-)
たしかにセキュリティポリシー次第だろうけどさ、どういうポリシーで運用するのかは外部の株主とかに分かるようにするべきだよね。
どういうポリシーで運用するのかは外部の株主とかに分かるようにする
趣旨には賛成です。が、どう説明すれば、ITの専門家でも経営の専門家でもない株主に理解してもらえるでしょうか?
プライバシーマーク!…なわけないよね。
いつ株式会社とか外部に説明がいる組織と判明したのだろうか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
セキュリティポリシ次第 (スコア:5, 興味深い)
一受託業者が決めるべき問題じゃないね。
そのシステムのセキュリティポリシに従って決まる。
より良いシステムになるよう助言はした方がよいと思うけどね。
ところで、これって、サーバ(やクライアント)毎のパーソナルファイアウォールの話だよね。
設定できるなら、設定した方がいいとは思うね。
しかし、ネットワークで適切に守られていれば、それで十分と言う考え方もある。
それこそセキュリティポリシだ。
パーソナルファイアウォールと同様の問題で、SELinuxをどうするか、って話はあるよね。
SELinuxを無効にしてるのをよく見るけど…
Re:セキュリティポリシ次第 (スコア:3, 興味深い)
具体例として取り上げて申し訳ないんだけど「Hinemos」がまさにそうで、開発元となったNTTデータの説明でしっかりと「SELinuxを無効化します。」と書いてある。
SELinux有効では動作しないのか、それとも手順書上そうなってるだけなのか、検証した人はいないのだろうか。
Re:セキュリティポリシ次第 (スコア:1)
単に、SELinuxを設定するノウハウが無いとか、NTTにはあってもユーザにはなくて、サポート経費を考えると、そうせざるを得ない、とか。
Re: (スコア:0)
まぁ手抜きだよね。
適切なポリシーと一緒に配置すれば動作しないわけがない。
ただ、ファイルパスとかもポリシーに入っているわけで、標準と違うパスにファイル配置したければポリシーだのラベルだの
調整しなければいけない。
それを説明するのが面倒だから無効にしないと動かないと言ってるだけだ。（本一冊になるようなことをただで教えろと言われるし）
Re: (スコア:0)
ちょっと書き忘れた。
たいていの場合、ドキュメントレベルではSELinuxサポートしません！と書いてあっても中にポリシーファイルついてるのでは。
サクっとコンパイルしていれときゃ問題ない。
Re: (スコア:0)
あー、もう一つおもいだした
＞SELinux有効では動作しないのか、それとも手順書上そうなってるだけなのか、検証した人はいないのだろうか。
こんなもの、聞くまでもなく自分でためしゃいいじゃねぇか、っていうのもコメントつかないほどSELinuxって使い方だれも知らないのな。
permissiveモードで起動するように設定して動かすとポリシー違反があったことが報告されるけどプロセスの動作はブロックされない。
そうやって、AVC（違反報告）を集めてポリシーを作る。
ただ、一から作るのは結構大変だし、全部網羅したという確証もないのでパッケージについてるのがないか探すのが吉。
＃SELinuxは初めて有効になったときファイルにラベルというものを付けるので起動に時間かかるよ。
Re:セキュリティポリシ次第 (スコア:1)
それを開発元が検証した上でドキュメントを作ればよかったんじゃないかな。なんで手抜きにしちゃったんだろう。
オープンソースなんで自分で好きにやれってのは分かるんですがね。
Re: (スコア:0)
＞ただ、ファイルパスとかもポリシーに入っているわけで、標準と違うパスにファイル配置したければポリシーだのラベルだの
＞調整しなければいけない。
これに尽きると思う。たとえばログファイルのディレクトリ変えました、とか、リッスンするポート番号変えました、といったものでも
（たとえ設定者は大したことではないと思っていても）SELinuxにとっては重大なポリシー違反なのでそのプロセスは動きません。
変に動きますというと、自分で設定いじった癖に”うごかねーじゃねぇえか”、というウマシカ君たちが騒ぐので放っておくしかない。
そんな奴らの相手をするくらいなら”デフォでオフでしょJK”とか言わせておく方がいい。
Re: (スコア:0)
Re: (スコア:0)
同意。
たまに「iptablesやSELinuxは無効にするのが常識」って言う人が居るのだけど、
そういうのにはちょっと腹が立つ。
自分たちが理解できてない、制御出来ないシロモノだからやむなく無効にしてるんであって、
本来は、ちゃんと理解して必要な許可設定を行うべきだと思う。
Re:セキュリティポリシ次第 (スコア:1)
OS標準ソフトウェアだけなら、大抵SELinux有効でなんとかなるね。
問題は、サードパーティーのソフトウェア製品を入れる場合。
その製品の要件に「SELinux無効」とか書いてあったり…
困ったもんだ。
Re: (スコア:0)
＞本来は、ちゃんと理解して必要な許可設定を行うべきだと思う。
SELinuxをちゃんと理解して設定できるレベルの技術者を集められるプロジェクトは世間の1%も無いよ。
無効が常識とか言うレベルはアレだけど、現実的にはソコソコ理解している(理解できる)メンバが中心になるので、テスト期間が十分に取れて後で責任を押し付けられないなら設定しても良いけど、ギリギリ納期で開発が終われば、ほとんどのメンバが消えるような現場が多い現状では無効にするのが現実解だと思うしかない。
DとかIとかFとかNの命令するだけの一次受け企業担当者は「本来は、ちゃんと理解して必要な許可設定を行うべき」とか良く口にするけど、それができるメンバがいないのだから下請けいじめでしかない。現実を見ず正論を振りかざして作業を押し付ける現場ばっかりだから、作業は減らないんだよなー。
Re:セキュリティポリシ次第 (スコア:2, おもしろおかしい)
>命令するだけの一次受け企業担当者は「本来は、ちゃんと理解して必要な許可設定を行うべき」とか良く口にするけど
いや、それを口にしない奴はヤバイだろ。
Re: (スコア:0)
いや、下請けとしては一番ヤバイ状況じゃないの？
口は出すけど金は出さない。口は出したので責任は押し付けたということでしょ？
口に出さないならこちらが提案なりすればいいだけ
Re: (スコア:0)
その通りで、「お前んとこが提示した単価じゃ無理だよ」ってのばっかりです。
んでこれを言い続けると、「じゃよそに頼むわ」つってやってるフリしているところに仕事が行き、
向こうも知っていながら単価安く上げたいから黙認して、後になって問題がでて、
「やってるって言ったよな？」って言う。
下請けに責任を押し付けてその場を逃げても信用ってのは戻ってこないんですけどね。
まあ信用と単価を天秤にかけて信用取るのはお役所ぐらいになってきましたけど。
Re: (スコア:0, 参考になる)
夏休みになるとこう言う知ったかぶりな人が増えるなあ。
DとIは知らんけど少なくともFとNとNとHはグループ(企業)全体のテンプレでSELinuxはデフォルトOFFになってるよ。FWはON。
勿論プロジェクトごとにポリシー上書きしてONには出来るけど、各社のツールとかがOFFが前提になってたりするから、普通はONにしない。
後、これは噂と言うか都市伝説レベルの与太話かもだけど、SELinuxはNSAがらみで各社何か情報を掴んでるからOFFになっているんじゃないかと言う話も聞いた事がある。
Re: (スコア:0)
Re: (スコア:0)
無効化しなければならない理由が明確にあるのならその選択肢もありうる。
しかし面倒を避けるため、ってだけなら唯の手抜きだし
それ自体は僅かで他が問題なければ影響ないとしても確実にセキュリティ下げてはいるんで
そのリスクと何を比べた判断なのか次第だと思う
Re:セキュリティポリシ次第 (スコア:2, 興味深い)
手抜きだと一概に言えないほどSELinuxはひどいでしょ。
意図的にわかりにくく設定しづらくしてセキュリティを高めているつもりなのかと勘ぐりたくなる。
技術、知識、意識がうんぬんと言うより新しいアクセス制御のソフトをつくった方がましに思える。
Re:セキュリティポリシ次第 (スコア:1)
SELinuxの連中(NSA)が新しいアクセス制御ソフトの導入を全力で妨害していたのをブチ切れて解決してくれたLinusさんマジイケメン
Re: (スコア:0)
つまりTOMOYO Linuxを有効にすればいい。さすがに仕事では使ったこと無いけど、個人で運用してたサーバには使ってたな。
Re: (スコア:0)
AppArmorとかどうですか?
Re:セキュリティポリシ次第 (スコア:1)
そのリスクと何を比べた判断なのか次第だと思う
大抵の場合は単なる手抜き、というのは同意として。
リスクと管理負荷を比べた判断、という言い訳はよく聞くね。
Re:セキュリティポリシ次第 (スコア:1)
言い訳じゃなくて、適切な判断だと思いますよ。
それこそセキュリティポリシでしょ?
Re:セキュリティポリシ次第 (スコア:1)
言い訳じゃなくて、適切な判断だと思いますよ。
適切な判断のケースもあるし、そうでない場合もあるよ。
例えば、ちゃんと調査して設定すればOKなのに、工期を確保できないがために、「リスクと管理負荷を比べた判断」ということにした、というケースがある。
受託業者も工数が減るし、委託側も工期を守れるなら、と結託した結果そーなるケースね。
Re: (スコア:0)
「ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない」だって適切な判断なのに、そういう誤摩化しをする人の考え方がよくわからない。
Re:セキュリティポリシ次第 (スコア:1)
ちゃんと調査して設定すればOKだが、工期が確保出来ないから、やらない
結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。
実は、調査する気もその能力もない、って話だったりするとなおさら。
あと、前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃいけなくなっちゃうから、とかね。
Re: (スコア:0)
> 結果、セキュリティが不十分になります、と説明しなければならないことになっちゃうから、とかですかね。
時間くれれば（導入及びその他への影響の）調査して実施するけどその工期（と予算）は与えてくれないからできないっていうだけでしょ。
セキュリティが十分かどうかの説明は当然するよね。
妥当かどうかは顧客が決める。
> 前例を破ると、自分たちの過去の仕事が不十分だったことを認めなきゃ
仕事でこういう話扱ってればわかると思うけど、これは逆。
これまでやっ
Re:セキュリティポリシ次第 (スコア:1)
セキュリティが十分かどうかの説明は当然するよね。
妥当かどうかは顧客が決める。
顧客と一口に行っても、一体ではないからね。
誰が誰に説明するのか、って問題になる。
業者が直接付き合うのは、IT部門の担当者で、会社の経営層に説明するのは、そのIT部門のトップだったり。
そーなると、みょーな社内力学とかが働いたりして。
Re: (スコア:0)
委託される側が社内力学の事まで気を遣うのが過剰なんでしょうね。
私の場合は「期間と金があれば出来るが、懐事情は分かっている。社内向けの説明はよろしく」で通しているけど問題になったことはないですね。
稀なケースではあるけど顧客の経営陣へ説明する場合も、正直に言う。
判断するのはその人たちの役目で、そのための情報に嘘を混ぜてもろくな事にならない。
金も期間もくれないところとは、どうせ将来的にもうまくやれないので早期撤収するという自社ポリシーのおかげでもありますが。
Re: (スコア:0)
そもそも安全性を第一に考えるなら専用の閉じたネットワークでやれとか色々とコスト度外視のことをやらなければならず
じゃあどこまで安全性を犠牲にしてコストを優先するか？ってのが考え方の基本であってセキュリティ第一が基本の考え方じゃないしね
セキュリティとコストのバランスについては客に従うべきだよね
その責任とお金は客が負担するものなんだし
Re: (スコア:0)
ＮＴＴデータのCAFIS系の提案では必ずFWとSELinuxも盛り込んでいるが管理運用できない理由からSELinuxはおおむね対象外にされていた。
構築できても維持できないのなら致し方ないか。
Re: (スコア:0)
SELinux なんてあんな組織が関係してるもの有効にするわけないじゃないですか ;-)
Re: (スコア:0)
たしかにセキュリティポリシー次第だろうけどさ、どういうポリシーで運用するのかは外部の株主とかに分かるようにするべきだよね。
Re:セキュリティポリシ次第 (スコア:1)
どういうポリシーで運用するのかは外部の株主とかに分かるようにする
趣旨には賛成です。
が、どう説明すれば、ITの専門家でも経営の専門家でもない株主に理解してもらえるでしょうか?
プライバシーマーク!…なわけないよね。
Re: (スコア:0)
いつ株式会社とか外部に説明がいる組織と判明したのだろうか？