Re: [討論] 雲端與掃毒=掃走機密資訊怎麼辦?!

看板Soft_Job作者 (ggg)時間14年前 (2011/06/10 14:04), 編輯推噓8(8推 0噓 95→)
留言103則, 2人參與, 最新討論串5/7 (看更多)
先把問題放著: 放在 PC 上的私人資料會不會被冒充或惡意的掃毒軟體掃走? (不用扯雲端掃毒) 租用雲端的虛擬機跑需要 license key 的 CADtool, license key 在雲端虛擬 機上會不會被管雲端的 操作管理人員 掃(偷看)走? 技術上要怎麼打開 license key 來用, 又不必怕被掃走? 留著底下相關的 key words -TPM, IBM vTPM sHype, Intel TXT, Trusted Computing, Secure Migration -及現在的雲端安全也都提到 remote operator's interference, 相關的做法 -就是 Secure Hypervisor.雲端 operator 掃走 license key, 這問題一點都 -不是我劃的大餅. 雲端就是已有這類解答提案, 一切也就在往前走了. ================================ 舉個簡單的需求: 正在個人的PC上執行某個要 License key 的軟體, 處理某個機密資訊. 假設這個軟體是在 hostos 上用某個軟體(或有硬體支援的)Hypervisor 產生 VM, 再於該 VM 啟動 guestOS 由之執行 Key Licensed software 與處理 機密資訊. 使用者將VM相關資訊及其上的 guestOS 與 AP 都 以瞬間快照存到一個加密檔. 現在這使用者想讓這個 VM 搬到雲端提供的虛擬機上執行, 但又不洩密.
→
06/10 02:44, , 1F
到後面已經不懂老師到底是在什麼基礎下、信任什麼的狀況下
06/10 02:44, 1F
→
06/10 02:44, , 2F
提出要防止雲端公司的偷看了！？
06/10 02:44, 2F
→
06/10 02:45, , 3F
簡單說，現在的雲端安全，通常都是保證同硬體、同VMM上的
06/10 02:45, 3F
→
06/10 02:46, , 4F
VM，能設定成互相切開獨立而不會被影響，已這樣的方式讓
06/10 02:46, 4F
→
06/10 02:46, , 5F
用戶安心，因為租用VM同時，不知道跑在哪裡，也許有其他人
06/10 02:46, 5F
→
06/10 02:47, , 6F
租用的機器想要竊聽資訊等等～都可以透過這方式擋掉
06/10 02:47, 6F
→
06/10 02:47, , 7F
至於磁碟加密，這是可行的。
06/10 02:47, 7F
→
06/10 02:48, , 8F
然而run起來的時候的記憶體加密，似乎則不可行
06/10 02:48, 8F
假如 vmm 是可信的, 而全硬體的老式 IBM VMM 管 Virtual memory mapper, 並 提供所有 iommu 及 I/O driver, 此時, hostos 與 guestos 都工作在各自隔離 的空間, hostos 是在虛擬的 priviledge mode 上工作. 而因為這是個硬體的 vmm 除了用硬體手段外, 很難將竊聽軟體接進去. 這是假設硬體VMM及硬體是可 信的.
→
06/10 02:48, , 9F
理由如前所述，即使在VMM上弄出所謂的驗證查核機制
06/10 02:48, 9F
→
06/10 02:49, , 10F
這時候又回到了，到底信不信任提供VMM的雲端公司這個議題
06/10 02:49, 10F
→
06/10 02:49, , 11F
對於一個已經不信任的公司，他們提供一個機制供人檢查
06/10 02:49, 11F
→
06/10 02:50, , 12F
然而機制真的是正常運行嗎？還是模組可能會被抽換或更動？
06/10 02:50, 12F
→
06/10 02:52, , 13F
VMM和硬體整個都在別人那邊，到底要怎樣才能真的讓人信任
06/10 02:52, 13F
→
06/10 02:52, , 14F
根本就是一個大問題，而不是單純說說就可以說服客戶
06/10 02:52, 14F
生產的硬體 其功能 當然有其檢驗的程序以確保合乎規範. 換言之, 除了事前 邏輯分析驗證, 生產之後還是得接受功能核驗. 如果 secure VMM(或 Hypervisor) 功能規範被確定, 是否有這功能? 是否正確無誤? 這都是能被查驗的. → askeing:何況光是老師上面回的DomU不想讓Dom0看封包的例子就可看出 06/10 02:54
→
06/10 02:54, , 15F
DomU不加密，轉手給Dom0加密，要送出時讓VMM解密
06/10 02:54, 15F
→
06/10 02:54, , 16F
許多重要操作都跑去VMM了，這時候VMM要怎樣讓人信任？
06/10 02:54, 16F
→
06/10 02:57, , 17F
且真的這樣加密解密，封包一多掉的速度應該很可觀
06/10 02:57, 17F
→
06/10 02:57, , 18F
加上多吃的額外負擔，一台伺服器上面能跑的VM會降低
06/10 02:57, 18F
這是 XEN 與 VMware 用修改軟體碼的方法代替硬體的指令攔截技術以後, 因為並沒有更低一層的 Hypervisor(VMM)隔離, 使得 hostos 與 VMM 都 工作在同一個 priviledged mode 以至於沒有 mapper(mmu , iommu) 隔 離. 由 VMM 對 hostsos 對其他 vm 的資訊存取做加密的原因就是隔離. 如果是 封包, 那是不用真的搬遷加解密, 實況是 pointer 與 descripor 在被 check 與移動, 真的搬出 VMM 才有實質加解密. 每個 VM(含 Dom0) 都有其 configuration, 真正的資源分配理論上就是 VMM 該知曉實況. 效率問題本就是虛擬機技術該持續改善的地方.
→
06/10 02:58, , 19F
這只是封包部份，當所有VM的記憶體都加上一堆機制來加密…
06/10 02:58, 19F
→
06/10 02:59, , 20F
我想 您的想法立意良好，但似乎有點太理想化了 ^^a
06/10 02:59, 20F
全軟體的 Emulator 就是道地的 掃瞄 所有程式指令, VMware用的就是 patch 技術. 也被微軟認為是病毒的感染手法. 資訊隔離技術 就跟 VM之間 需要相互隔離一樣, 一直就是存在的需求. 這理 想不太可能是高不可攀, secure hypervisor 只是個機制或工具, 其功能從外 部就能被檢核. 隔離遮蔽就如同人類的外衣, 該穿就穿, 該脫就脫, 核驗就如 同照鏡子, 由穿戴者就能自行檢驗. 至於衣服是否會在泡水後會被紅外照相機 攝相使之失效, 那仍然也是可以被檢驗的. 某種程度的防護是有必要的需求. =========== 正在雲端執行的程式應該是被解開來了, 假設雲端設備緊急停電, 立即要做 checkpoint 瞬間照相存檔, 這個太上要求, 假設就是要求 secure hypervisor 緊急配合, 不要遮蔽讓 OP 抄了備援. 那OP 豈不可以靠那份慢慢偷用偷看? 如遮蔽與軟體的執行都靠加解密, 當key離開車子, 通常就不能發動車子. 這 種有時效性的key也是常被用到, 針對租用者vm資訊做必要隔離加密的s-VMM 就可利用網路從使用者那裡取得有時效性的key, 這也能防被全抄挪用.
推
06/10 14:24, , 21F
這個時候VMM變成可以信任了...前面耍寶半天不知在幹嘛
06/10 14:24, 21F
→
06/10 14:24, , 22F
還有你又還繼續停留在 Hosted OS...唉...不可教也
06/10 14:24, 22F
→
06/10 18:21, , 23F
硬體VMM沒玩過不清楚。
06/10 18:21, 23F
→
06/10 18:21, , 24F
但是xen不是Binary Translation
06/10 18:21, 24F
XEN 是改 hostos 的 source code, 沒有 HVM support 前, guestos 也得改.
→
06/10 18:22, , 25F
x86虛擬化麻煩就是有些指令只能跑在ring0，所以才有各種
06/10 18:22, 25F
→
06/10 18:23, , 26F
方法要規避這問題。後來可以硬體支援之後可以跑HVM，
06/10 18:23, 26F
→
06/10 18:23, , 27F
OS就可以直接跑在ring0, VMM種在ring-1做事。
06/10 18:23, 27F
→
06/10 18:24, , 28F
以native來說，根本沒有host OS
06/10 18:24, 28F
hostos是被拿來利用其已有的各類配合硬體的 driver, scheduler, tool 與 ui, 減少發展 VMM 的難度. 最老爺的 IBM VMM 是 Microprogramming 支援的, 其上 就是支援變出各個獨立分割Virtual Machine 的 control program. 這個部份不 必要是完整的OS, 但要能控制實際的整個硬體, 但用一個完整的 OS 來支援那是 省事太多. 現在的 Hardware Supported VM 仍然是支援這種利用現成 OS 與 driver 的方法. 商用的 system VM 都是跑 native code , guestOS 也是 native code. 只有部份 process VM 其指令集(如 MIPS) 跟硬體指令(如 X86)不同. 不知以 native 來說, 是何種說法? 不過, 沒有現成 hostOS 支援, 實際控制硬 體的 i/o driver 是來自何處? 還是您認為 XEN 的 Dom0 跑的不是 os ?
→
06/10 18:25, , 29F
封包的部份現在實際就是這樣做，只是呼應老師的隱藏資訊
06/10 18:25, 29F
→
06/10 18:25, , 30F
如果信任VMM，當然依照現況作法沒有問題。
06/10 18:25, 30F
→
06/10 18:26, , 31F
最後一段，首先是虛擬化跟模擬是不同東西。
06/10 18:26, 31F
→
06/10 18:26, , 32F
再來則是VM之間的隔離，與VM跟雲端公司操作者隔離是兩回事
06/10 18:26, 32F
→
06/10 18:27, , 33F
VMM也是在操作者的手中，甚至硬體也是。
06/10 18:27, 33F
還有 34 則推文
還有 2 段內文
→
06/10 21:35, , 68F
恩，我剛剛寫錯，應該說 XenDesktop XD
06/10 21:35, 68F
→
06/10 21:35, , 69F
不過VMware的改名叫做View了，VDI現在應該可以算統稱？
06/10 21:35, 69F
→
06/10 21:36, , 70F
的是 XenApp...
06/10 21:36, 70F
→
06/10 21:37, , 71F
VDI那個是名詞用久了，大家常講已經跟VMWare綁一起了:P
06/10 21:37, 71F
推
06/10 21:47, , 72F
VMM現在要用patch技術是蠻難的，VMWare是FV不用談，
06/10 21:47, 72F
→
06/10 21:47, , 73F
XenServer也頂多是driver可以PV
06/10 21:47, 73F
→
06/10 21:47, , 74F
以後HVM在雲端普及化後，就更都沒差了....
06/10 21:47, 74F
推
06/10 21:55, , 75F
至於防毒部分，現在的趨勢反而是希望掃毒能夠更靠VMM一
06/10 21:55, 75F
→
06/10 21:56, , 76F
點，所以VMWare有一大堆API給像T牌M牌去呼叫(例VMSafe)
06/10 21:56, 76F
→
06/10 21:57, , 77F
這個部分 Xen (還有喊的比作的大聲的Hyper-V) 就都還差
06/10 21:57, 77F
→
06/10 21:57, , 78F
的遠了。
06/10 21:57, 78F
→
06/10 22:01, , 79F
他們的目的才是Secure Hypervisor在努力的對象，所以看
06/10 22:01, 79F
→
06/10 22:01, , 80F
到一個名校老師亂扯一通，也只能又好氣又好笑
06/10 22:01, 80F
→
06/10 22:16, , 81F
Citrix Mcafee 也是有在合作弄個open security API就是
06/10 22:16, 81F
================ → askeing:我說的HostOS是Host Based Virtualization的名詞 06/10 21:13 → askeing:他位置在VMM下面，Dom0跑的架構根本不同，用hostOS很怪 06/10 21:13 你說的是這個: host based virtualization: Virtualization implemented in a host computer rather than in a storage subsystem or storage appliance. Virtualization can be implemented either in host computers, in storage subsystems or storage appliances, or in specific virtualization appliances in the storage interconnect fabric. 這是 storage virtualization 不是系統虛擬機 (System Virtual Machine). INTEL 的 hardware supported hypervisor 主要在對敏感指令的自動攔截 但面對各種硬體組合, 仍然是依賴現有OS是最方便可能. 而高速IO一定動 用到 DMA, DMA 就能干擾到 real memory 內容, 目前做法是 software的 iommu, 這就是鉗入機制於 hypervisor 使之隔離. ======================================================= 敏感性指令意涵很清楚: 使 VM 的執行受到影響干擾的動作都是. Control sensitive instructions Those that attempt to change the configuration of resources in the system. Behavior sensitive instructions configuration of resource 最明顯的例子就是 Virtual Memory 的 mapping table 內容,這是 memory table 的接取與更改. VMM 上層的hostos guestos 都不能直接進去改, 必須由 VMM 看狀況對象處理. Those whose behavior or result depends on the configuration of resources (the content of the relocation register or the processor's mode). 換言之, 一旦 VMM 掌控上來後, 某些影響到其他 VM 的 table access 就必 須被攔截, 再由 VMM 看狀況給予隨對象而異的結果. ==============
→
06/10 22:17, , 82F
只是似乎 focus 在 XenDesktop 上的防毒！？
06/10 22:17, 82F
推
06/10 22:34, , 83F
如果是指 MOVE AV，那是針對VDI的，詳情可能要問另一位
06/10 22:34, 83F
→
06/10 22:34, , 84F
長輩，那個重點技術應該是在效能部份吧...
06/10 22:34, 84F
→
06/10 22:38, , 85F
如果是說把動作集中往外導，那應該跟V家的滿像的 XD
06/10 22:38, 85F
→
06/10 22:39, , 86F
如果不是的話就不清楚它們在做什麼了 :P
06/10 22:39, 86F
→
06/10 22:58, , 87F
老師不要只找自己想看的部份
06/10 22:58, 87F
→
06/10 22:59, , 88F
這篇 #1Dw4nhyT 就給過參考了 http://tinyurl.com/2wanyc
06/10 22:59, 88F
→
06/10 23:04, , 89F
通常在業界討論的時候提Host OS人家想到就是Type 2
06/10 23:04, 89F
→
06/10 23:05, , 90F
而最後這段sensitive instructions解釋也是對的
06/10 23:05, 90F
→
06/10 23:05, , 91F
但無法解釋老師那句「隔離的要求本就是她的任務」！？？
06/10 23:05, 91F
推
06/10 23:53, , 92F
不太想繼續理他，一個名校老師淪落到人家說什麼就去
06/10 23:53, 92F
→
06/10 23:54, , 93F
google剪貼資料有點可悲...
06/10 23:54, 93F
=========== 你要說的是這個: Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. A guest operating system thus runs on another level above the hypervisor. 在 INTEL 還沒提供 Hardware support 的 CPU 時, 好幾個商用VM 系統 就已宣稱是 Type1, 此時, guestos 是在 user mode. 部份敏感的 i/o 指令 有一部份 靠舊有的 v86 mode 可以配合, 但若超越 8086 架構指令 就不行了, 此做法的 hypervisor 還是跟一個使用 priviledge mode 的 hostOS 擺在一起, hypervisor 就是要透過 hostos 控制硬體. hostos 的 operator 還是可以干擾到 hypervisor 的執行. 這跟 hypervisor 直接掌控硬體進行管理還是有所不同. 敏感指令或動作需要被攔截到 Hypervisor 由之查核後再執行, 不就是 為了避免相互干擾出錯? 隔離不就是可避免干擾?
推
06/11 09:33, , 94F
老師上課都是google完然後這樣亂用名詞和瞎掰人家架構
06/11 09:33, 94F
→
06/11 09:33, , 95F
的嗎?
06/11 09:33, 95F
→
06/11 12:00, , 96F
那是架構的問題，沒硬體支援之前，靠得主要是PV，
06/11 12:00, 96F
→
06/11 12:00, , 97F
至於Driver要放VMM還是Dom0有不同作法
06/11 12:00, 97F
→
06/11 12:01, , 98F
老師要是去跟社群的人討論這議題時，還是不要用HostOS為好
06/11 12:01, 98F
→
06/11 12:02, , 99F
最後，原先講的隔離是說資安上各VM之間的隔離
06/11 12:02, 99F
→
06/11 12:03, , 100F
網路封包、記憶體…等 靠VMM的機制去分開
06/11 12:03, 100F
→
06/11 12:03, , 101F
你最後提的隔離怎變成了各VM的指令不互相影響！？
06/11 12:03, 101F
→
06/11 12:03, , 102F
各VM指令不互相影響本來就是虛擬畫的基本要求
06/11 12:03, 102F
→
06/11 12:04, , 103F
但跟資安在VMM上提的隔離沒啥關係就是…(至少我這樣覺的)
06/11 12:04, 103F
假設 hypervisor 在最底層, 其上的有 kernel space 的 hostos, 也有 user space 的 guestos(理論上也可以在 kernel space, 以支援 recursive VM). Hypervisor 該管實體 mmu 的 mapper, 是吧? 但 hypervisor 是否該將 某 VM 裡的實際記憶體內容或位址交給 kernel space 的 VM(或者說 operator 使用的 hostos)? 隔離就是看不見, 拿不到, 跟該資訊相關的指令拿不到資訊就起不了作用, 也就是不能影響. 這是共用資源的老問題, 但 VMM 不是只提供隔離後不理, 還要做出各 vm 想要的效果, 碰到極端反面,就保護的立場則是不給做. 跟資安是否有關? 那就隨認知有所不同是很正常的. 正確說是不互相"干擾", 也就是不造成失誤. ※ 編輯: ggg12345 來自: 140.115.5.45 (06/11 13:08)
‣ 更多 ggg12345 的文章
文章代碼(AID): #1DyRFhSg (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 5 之 7 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 ggg12345 的文章
文章代碼(AID): #1DyRFhSg (Soft_Job)