主要Linuxディストロでroot権限奪われる危険！ udisksに新たな脆弱性が見つかる
引用元：https://news.ycombinator.com/item?id=44325861
ローカル権限昇格なんて気にしないよ。共有カーネルでセキュリティ境界を引けるって今でも思ってるなら、カーネルのCVEデータベースを見てゾッとするべきだね。派手なタイトルのエクスプロイトの裏には、聞いたこともないのが20個もあるんだから。syscallの使用を制限して、最小限でちゃんと監査されたsyscallフィルタリング層を使ってカーネルのほとんどを隠せば、ある程度はできるかもしれないけど、本当に分かってる人がやらないと。ちゃんとしたセキュリティ強化はたくさんのソフトを壊しちゃうよ。基本的なレベルのセキュリティを得るには、「BPF」って文字がつくものは全部無効にして、＼procとか＼sysみたいな仮想ファイルシステムは全部隠して、io_uringも無効にして、何か動かなくなるまで見つけたCONFIG＿＊を全部削除しないとダメ。一部のサブシステムは他より脆弱みたいだね（皮肉なことにnetfilterが脆弱性の安定供給源に見える）。
それなのに、みんな実際にはコンテナベースの隔離をしょっちゅう使ってるし、世の中終わってないよ。それに、Androidシステムの全てのセキュリティドメインはカーネルを共有してるのに、Androidは世の中で最もセキュアなシステムの一つだ。確かにSELinuxを大量に使ってるけど、それがどうした？ 結局共有カーネルだし、かなり高機能なやつだよ。カーネル内部でセキュリティ隔離ができないからローカル権限昇格を気にする必要ないっていう考え方には賛成できないな。
コンテナは信頼できるセキュリティ境界としては機能しないよ。あれは開発者＼運用ツールなんだから。
皮肉なことに、Ubuntu 24はユーザーが名前空間にアクセスするのをブロックしたらしいね。そのカーネルインターフェースでローカル権限昇格がたくさんあったからさ。隔離に使いたいプログラムはこれで壊れるけど。
あんまり関係ないんじゃない？
話してる脅威はマルチユーザーシステム向けだよ。
トーマス、Kata ContainersみたいなマイクロVMについてどう思う？ runcの代わりにDockerのバックエンドで使えるよ。知ってるとは思うけど、読者のために言うと、CPUのVT命令で隔離されてるんだ。VT命令はVMを隔離するために作られてるんだから。いまだに「コンテナはコンテナしない」（Dan Walshのボストン訛りで）とは思うけど、これはちゃんとしたスタートに見えるね。https://katacontainers.io
ここ10年くらいで、Linuxの名前空間はローカル権限昇格の、そして時にはカーネル空間での任意のコード実行の、絶対的に最も多い原因だったんだ。マルチユーザーシステムではユーザー名前空間のサポート無しでカーネルをビルドするのが、ほぼ同じくらい長い間、定番のアドバイスだったんだよ。Ubuntuはただ対応が遅れてるだけさ。彼らは主にサーバーかシングルユーザーデスクトップの顧客が多いからね。
で、Pulse Audioサービスって今どこのユーザーで動いてる？
これはローカルエクスプロイトだけど、言及されてるサービスの組み合わせをサポートしてるシステムなら、つまりたくさんのシステムで、危険があるんだ。RHEL系や多分Ubuntuもそうね。AlmaLinuxのブログでCVEのテストパッチの情報を見てみなよ。https://almalinux.org/blog/2025-06-18-test-patches-for-cve-2…
Androidのカーネルってさ、元の投稿にあった強化とか機能無効化のほとんどを備えてるんじゃないの？
それって開発には遅くてダメだよね。本番には多少良いかもだけど、検証されてないいろんなハイパーバイザー次第って感じ。
いや、違うよ。eBPFとかstrace、パケットフィルタリングは有効だよ。AndroidはSELinuxとかで、それらにアクセスできるコードを制限してるんだ。投稿主が必要だって言ってる、カーネルから完全に削除するのとは全然違うよ。
＞ pulseaudioは誰で動いてるの？
わかんない、pipewireみたい。
自分のアカウント以外だとしても、攻撃に使うユーザーじゃないでしょ。ログインや外部サーバー動かすアカウントが先にやられる必要があって、そしたらpulseaudioなしで直接エクスプロイト使えるじゃん。
/homeに一つしかフォルダないなら、君には管理者パッチの緊急性は低いかもね。
どの”検証されてない”ハイパーバイザーのこと？ KataはFirecrackerで動くよ。
Pipewireはpipewireユーザーで、systemdかOpenRCが管理してるんだ。だから、そいつらが管理するプロセスならどれでも新しいpipewireユーザープロセスを始められるってわけ。ローカルの権限昇格は、一つのエクスプロイト[0]でリモートにつながる可能性ありだよ。
[0] https://www.bleepingcomputer.com/news/security/hackers-collaboration-tools-breached-to-spread-linux-backdoor/
コンテナの分離ってさ、共有レイヤーの共有ライブラリでもダメになることあるよね？ 俺のヤバいサービスが君の超大事なハードウェア制御サービスと同じ cooltechframework ってベースレイヤー使ってて、もしそこに間違いがあったら…
＞ Pipewireはpipewireユーザーで、systemdかOpenRC管理。
俺が確認した環境じゃ pipewire ユーザーいなくて、ログインした自分のアカウントで動いてたよ。
＞ ローカル権限昇格はエクスプロイトでリモートにつながる。
それって外部とやり取りするアカウント向けだよね。
俺しかユーザーいないなら、自分と pipewire アカウント間を安全に保つセキュリティ機能は期待してない。権限昇格は、全然違う動かし方してるシステムにとってヤバいんだ。
もし知らなかったらだけど、コンテナってセキュリティの壁じゃないんだよ。bubblewrap みたいなやつがセキュリティ境界になるんだ。
もしブラウザからとか、自分で録ってないファイルから音を出すなら、君のアカウントは外部と通信してるってことになるよ。
別プロセスだからそれぞれ影響受けるだけだよ。同じコードでもデータが別なら関係ないじゃん。
名前空間って隔離とかセキュリティにめっちゃ使われてるのに、皮肉な話だよねー。
Linux FoundationがCNAになってから、たいしたことない“脆弱性”にもCVEがバンバン出るようになったんだよね。CVEの数だけ見ても意味なくね？
これがホントならさ、なんでLinuxデバイス全部root化されてないわけ？って思うよね。
同じ共有命令で動く別プロセスね。もし共有命令をハックして変えられたら、他のコンテナも好きな命令で動かせちゃうじゃん。
実はbubblewrapの方がもっと酷いんだよ。何年も直されてない既知のヤバい抜け道があるからね。
レイヤーはCOWだからさ、どっかのコンテナがレイヤー変えても、同じイメージから起動した他のコンテナには影響ないよ。元々の脆弱性は残るけど、それぞれ別々にハックしないといけないんだ。
もしsystemdとかOpenRCのユーザーが全然いない、超カスタムかマイナーなビルド環境だったらさ。その場合、ユーザーはvideoグループに入ってるから、ローカルでエスケープされれば、特別なことしなくてもroot取られちゃうんだよ。
udisksって、依存関係抜きでコードが26万5334行もあるんだってさ。それに比べてpmountは1万9978行で、13倍以上少ないんだ。sudoのCVE発生率（コード1000行あたり約0.5件、うち57.5％がCVSS7以上）で見積もると、udisksには約76件、pmountには約5件の深刻なCVEがありそうだねって計算だよ。
UbuntuがsudoをRustで再実装したバージョンに切り替えるみたいだよ。記事はこれ→https://www.phoronix.com/news/Ubuntu-25.10-sudo-rs-Default リポジトリはここ→https://github.com/trifectatechfoundation/sudo-rs ライセンスが緩いのがちょっとなんだけど、長期的に見ればセキュリティは良くなるはずだよ。
sudoにあんなにコード量があるなんてマジで信じらんないんだけど。OSに「これ制限なしで実行して」ってお願いするだけかと思ってたよ。自分でそういうロジックを持ってるなんて思ってもみなかったな。
Rust版への切り替え、時期尚早だって思わない？Rustバージョンには、まだ見つかってないロジックのバグがいっぱいあるって、俺は結構確信してるんだよね。
もっとコメントを表示（1）
複雑なシステムってさ、書き直されるときはいつもバグとかリグレッションがいっぱい出ちゃうもんなんだよ。
「ライセンスが緩いのが残念」だって？くそっ、それは残念だね。人が自分の作品を好きなように使うのを、それが俺個人の選択より制限が緩いってだけで許せないなんて、マジで嫌いだわ。もちろん皮肉だよ。
Linuxは広くオープンで協力的なエコシステムでうまくいってる。一方、BSDはあんまり良くないLinuxみたいで、プロプライエタリ製品に押し込められてるだけ。GoogleはAndroidの“制限の少ない”ライセンスのおかげでAOSPを締め付けてる。結局、Copyleftライセンスの方が長い目で見るとオープンソースプロジェクトには明らかに良いって、もう十分に証明されてると思うよ。
LinuxにそんなAPIはないよ。sudoにsetuidビットが設定されてるからカーネルが現在のユーザーに関係なくrootで起動するだけ。これ多分、まだ使われてる最悪な古い設計の一つだよ—どのバイナリもsetuidが設定されてたら、質問なしでrootとして実行されちゃう。逆に、実行中のバイナリの権限を上げる方法もない。これはWindowsみたいに、実行中のプロセスが権限を得たり失ったりするための堅牢な認証・認可APIで何十年も前に解決されるべきだった。ファイルシステムのビットがプログラムにroot権限を与えるなんて、頭おかしい。ファイルシステムをこっそり壊して、そのビットを自分のバイナリに設定することで見つかるCVEが多分ダース単位であるんじゃない？
いくつか、ってのは？
十分すぎるくらい？
もしかしたら二つ、致命的なやつ？
こっちの方がマシ？
ネットワーク越しのsudoers共有とか、そういうのに全部関係してると思うな。ああいうゴミみたいなのを全部取っ払えば、言語は本当にスッキリするだろうね。だって、今はsudoってそういう使い方されてないでしょ。
OpenDoas、OpenBSDのdoasの移植版だけど、予想されることのほとんどをたった4260行のコードでやってるんだ。sudoにはほとんど誰も知らないポリシーツールがたくさんあるけど、それが攻撃対象領域を増やしてるんだよ。
210個のsudo CVEのリスト、どう探しても見つからないんだけど。それホントに合ってる？
既存のプログラムだって、致命的なバグが２つはあるだろうね。不完全なものを不完全なもので置き換えるだけで、書き直しが必ずしも悪いわけじゃない。特に時間が経って巨大化したプログラムなら、もっと良い構造にしたり、良い仕様書をつけたりするメリットがある。他のものが依存してるから変えられない、みたいな偶然の振る舞いをどうしても維持したいシステムもあるけど、sudoはそういうんじゃないと思うよ。
例えば、Alpine linuxではOpenDoasがデフォルトで使われてるよ。
そもそも、どうして何もかも制限なしに実行される必要があるわけ？
＞ if any binary has setuid set, it runs as root
More precisely, it runs as the file owner. Which is often root.
There’s also full sudo session logging and a logging server now, along with binaries to replay all those logs. Whether those LOC reflect the logging server, I don’t know.It literally replays in the terminal like a movie. It’s nice, but I worry too much about the security implications (passwords captured, etc) to roll it out.edit:Ah yes, sudoreplay. You can see this video a playback via it. That’s not the guy typing, that’s sudoreplay time-accurately replaying what happens.https://www.youtube.com/watch?v=8XHlowCiLaM
Should your calculator ask who you are to compute 2+2? Contrary to popular belief, access control was stapled onto the computation space. There was a time when it was considered an unnecessary extravagance. It only became the night unbuckle mandate that machines give a shit about who you are once we started using computers as the basis of business systems.Accounts thereafter, ruined everything.
There’s been some work on alternatives to setuid sudo. For example run0 from systemd.
Asking the OS to do something without restrictions is not very difficult; sudo does that by virtue of its existence (it’s setuid). The extra code is deciding when not to do that.
For anyone thinking this is unnecessarily pedantic, it’s not.I didn’t exactly know what setuid did. I learned something today. :)
I got it from here [0]. I didn’t notice it was a keyword search, so it’s an overcount. Thanks for correcting me.
Going off its security advisories page [1] and this tracker [2], it seems to be around 43 CVEs, most rated high severity.
So the actual rate would be 43 CVE / 430 kLoC = ~0.01 CVE per kLoC, so ~2.65 CVEs for udisks and ~0.2 for pmount.[0] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sudo[1] https://www.sudo.ws/security/advisories/[2] https://security.snyk.io/package/linux/debian%3A10/sudo
Someone said this: https://news.ycombinator.com/item?id=44364842I agree.How about we just start using doas, anyway?
I remember last time I installed it, there was neither sudo nor doas preinstalled.
sudo has a lot of machinery for representing complex policies which involve partial access to elevated (or just different) permissions, and with more conditions than just a correct password for the requesting user. The kernel itself just sees a binary running as root which may drop some of those permissions before starting another process.
(And this isn’t even the most arcane part of linux userland authorization and authentication. PAM is by far the scariest bit, very few people understand it and the underlying architecture is kinda insane)
言いたいことわかったわ。
君の言い方だと、使われてる言葉とか開発者への批判みたいに聞こえちゃったんだよ。複雑なツールを単に書き直したって事実だけじゃなくてね。
そういえば、sudoって仕様とか、過去の脆弱性に対する既存のユニットテストとかないのかな？
こんなに重要なものを実装するのに、リグレッションテストとかドキュメントがたくさんないなんて超びっくりだわ。
エンジニアによる書き直しで、元のツールが自身の仕様に従ってないケースが見つかることもあるんだ。この書き直しで元のsudoに二つ問題が見つかったし。
このプロジェクトに関わったうちのエンジニアの一人が、使ったテスト手法や見つけた問題についてここで書いてるよ: https://ferrous-systems.com/blog/testing-sudo-rs/.
その後、書き直し版専用のセキュリティ監査をやって三つの問題が見つかったんだけど、そのうち一つは元のsudoの実装にも影響するんだ: https://ferrous-systems.com/blog/sudo-rs-audit/.
俺も、大きくて複雑なコードベースの書き直しはたいてい悪い選択だって考えには賛成だよ。
でも、sudoは特に大きなコードベースじゃないし、特に複雑でもないんだ—ただ、特にセンシティブなだけ。
そういう場合、トレードオフが逆転することもあると思う。
古くて機能が安定したコードベースを（範囲を絞って）書き直すことは、あらゆる面で改善につながる可能性があるんだ。
デスクトップで20年以上もLinuxを結構ハッピーに使ってる者として言わせてもらうと、機能面でもセキュリティ面でも、いまだに永遠の実験みたいに感じるね。
Linuxが実験的だと思うなら、他のOSを見たらいいよ。
BSDファミリーはかなり成熟してて安全だと俺は結構確信してるな。
Linuxはほとんどの人にとって、まあ十分って感じ。
それは確かに興味深い見方だね。
俺はプライベートでも仕事でも両方使ってるけど、セキュリティ面では（selinuxあっても）物足りなさを感じるのは認めるとしても、機能面では俺がもう一つ使ってるWindowsをゲーム体験以外ではるかに超えてると思うよ。
GrapheneOSみたいなのがデスクトップにもあればいいのになぁ（Qubesは知ってるよ）
ローカルのroot権限昇格って、最近はほとんど関係ないんだよね。
実際、エクスプロイトチェーンの一部としてしか役に立たないって感じ。
シェルサーバーとか、もうないでしょ。
大きな違いの一つは、BSDは統括委員会によって設計されてるってこと。
普通、同じ問題に対する解決策が15種類もあるんじゃなくて、うまく機能する解決策が2～3種類なんだよ。
ファイルシステムを例にとると、公式のファイルシステムはUFS(1＼2)とZFS。
GEOMをLVMやLUKSとかに使ってる。
そうは言っても、開発資金や開発者の大部分はLinuxに注ぎ込まれてるから、それ自体が（最終的には）より良いシステムにするのかもしれないね。
追記: もちろんUFSは非推奨じゃないよ。
＞GrapheneOSみたいなのがデスクトップにもあればいいのになぁ（Qubesは知ってるよ）
SecureBlueとKicksecureが一番近い代替だよ。
もっとコメントを表示（2）
エクスプロイトチェーンだって？
まさに、同じ記事で言ってたFedoraに影響するPAMの問題と組み合わせるみたいなやつ？
Linuxは成熟して安全っていうけど、iOSやAndroidみたいなアプリごとの権限管理（ファイルやカメラの使用許可とか）がないんだよね。昔は良かったのかもしれないけど、最近はちょっと競争相手に遅れをとってるんじゃない？
記事の脆弱性はローカル権限昇格（LPE）の話で、PAMはその一部。LPEはまずコード実行が必要ってこと。ほとんどのシングルユーザーLinuxでは、LPEは大したことないと思うな。俺のPCみたいに一人で使ってるなら、ユーザーでコード実行されればパスワードとか全部盗まれるし、結局sudoのパスワードもバレてroot取られるでしょ。LPEがあっても、永続化とかがちょっとやりやすくなるくらいで、結果はそんなに変わらない気がする。
「シングルユーザーLinuxデバイスでLPEは意味ない」って話、ほとんどがAndroidじゃないかな？って思う。もしそうなら、Androidはアプリをちゃんとサンドボックス化してるから、rootを取れるってのは結構大きなアドバンテージになるはずだよ。
「Eternal experiment（永遠の実験）」って言うけどさ…Windows 11、見たことある？ 10でもいいけど。開発者たちはしょっちゅう色んなとこいじって、壊して、直して…ってのを数ヶ月ごとに繰り返してるじゃん。
BSDは運営委員会が設計してるから、同じ問題に15個も解決策があるんじゃなくて、ちゃんと動くのが2〜3個って感じ。比べるなら、特定のBSDとLinuxそのものじゃなくて、特定のBSDとLinuxディストロの間で比べるのが正しいよ。
Androidってシングルユーザーシステムじゃないんだよね。アプリとかサービスとか、基本的に全部それぞれ独自のユーザーを持ってる。アプリごとに違うユーザーIDとSELinuxコンテキストがあるし、Androidのセキュリティはかなりしっかりしてるよ。
そのサイトからして事実と違うって！ grsecurity®は高性能なexploit対策を提供する唯一のカーネル置き換えって言ってるけど、secureblueはフルデスクトップディストロで、grapheneosの強化ツール（hardened mallocとか hardened chromiumのフォーク）を組み込んで、flatpakで hardenedアプリを展開するベースにしてる。grsecurityは全然そんなことしてないよ。
そうそう、grsecurityは「インチキだよ」って言われるんじゃなくて、ちゃんとシステムを硬くする現実的な方法を提供してるんだよ。
ねぇ、「シングルユーザーシステム」って言葉の使い方がややこしいんだよ。ノートPCみたいに「人が一人しか使わない」って意味ならAndroidもそうだけど、システム上のユーザーアカウントとは別次元の話。
Androidはアプリがサンドボックスされてるから、root権限が取られるってのはやっぱりヤバいことなんだ。その点では同意だよ。
なんか、平均的なLinuxディストロよりも、BSDたち（FreeBSDとかOpenBSDとか）の方が、それぞれ全然違う感じがするんだよね。
「BSDってかなり成熟してて安全だと思うよ」って話だけど、illumosベースのシステムもそうだってことを忘れちゃダメだよ。
人気のあるLinuxディストロは似てるけど、Void、Alpine、Gentoo、Chimera、NixOSみたいに、全部のディストロを見たら全然違うんだよ。
使ってるC librariesとかinit systemsとかも色々違うからね。
BSDは委員会設計で質が高いって言うけど、Linuxのユーザー空間って「首なし鶏」みたいにバラバラだよね。kernelみたいにTorvaldsみたいな「独裁者」がいた方が、まとまりがあって良いものができると思うんだ。Jobsとかもそうだよね。
昔Open SolarisをLaptopで使ってみたけど、けっこう良かったんだ。でも、とにかくsoftwareのsupportが全然なくて大変だったな。
最近はWeb中心になったけど、Illumosも状況はきっと変わってないだろうね。
ねぇ、container escapingって、VM escapingと比べてどれくらい難しいの？Containersはホントはsecurity boundariesじゃないんだけど、よくそう思われて使われてるよね。
従来のLinux desktopって、全部自分のuser権限で動かしてるんだよ。Firefoxもdesktop environmentもsudoもね。これはAndroidと全然違う話。
「multi-seat」かどうかは関係ないんだ。人気のLinux distrosは、desktopではちゃんとしたmulti-user configurationになってない。
Serversは別だけど、ここではdesktopの話をしてるんだ。
Chromium OSは、けっこう（appのisolationって点で）近いことやってるよ。VM baseでLinux applicationsを動かしてて、GPU accelerationもできるんだ。
でも、Googleが出してるやつ以外で、人気のあるdistroがないんだよね。
