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

[ggg12345 (ggg)]

先把問題放著:
放在 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 搬到雲端提供的虛擬機上執行, 但又不洩密.

→ askeing:到後面已經不懂老師到底是在什麼基礎下、信任什麼的狀況下
→ askeing:提出要防止雲端公司的偷看了！？
→ askeing:簡單說，現在的雲端安全，通常都是保證同硬體、同VMM上的
→ askeing:VM，能設定成互相切開獨立而不會被影響，已這樣的方式讓
→ askeing:用戶安心，因為租用VM同時，不知道跑在哪裡，也許有其他人
→ askeing:租用的機器想要竊聽資訊等等～都可以透過這方式擋掉
→ askeing:至於磁碟加密，這是可行的。
→ askeing:然而run起來的時候的記憶體加密，似乎則不可行
假如 vmm 是可信的, 而全硬體的老式 IBM VMM 管 Virtual memory mapper, 並
提供所有 iommu 及 I/O driver, 此時, hostos 與 guestos 都工作在各自隔離
的空間, hostos 是在虛擬的 priviledge mode 上工作. 而因為這是個硬體的
vmm 除了用硬體手段外, 很難將竊聽軟體接進去. 這是假設硬體VMM及硬體是可
信的.

→ askeing:理由如前所述，即使在VMM上弄出所謂的驗證查核機制
→ askeing:這時候又回到了，到底信不信任提供VMM的雲端公司這個議題
→ askeing:對於一個已經不信任的公司，他們提供一個機制供人檢查
→ askeing:然而機制真的是正常運行嗎？還是模組可能會被抽換或更動？
→ askeing:VMM和硬體整個都在別人那邊，到底要怎樣才能真的讓人信任
→ askeing:根本就是一個大問題，而不是單純說說就可以說服客戶
生產的硬體 其功能 當然有其檢驗的程序以確保合乎規範. 換言之, 除了事前
邏輯分析驗證, 生產之後還是得接受功能核驗. 如果 secure VMM(或 Hypervisor)
功能規範被確定, 是否有這功能? 是否正確無誤? 這都是能被查驗的.

→ askeing:何況光是老師上面回的DomU不想讓Dom0看封包的例子就可看出  06/10 02:54
→ askeing:DomU不加密，轉手給Dom0加密，要送出時讓VMM解密
→ askeing:許多重要操作都跑去VMM了，這時候VMM要怎樣讓人信任？
→ askeing:且真的這樣加密解密，封包一多掉的速度應該很可觀
→ askeing:加上多吃的額外負擔，一台伺服器上面能跑的VM會降低
這是 XEN 與 VMware 用修改軟體碼的方法代替硬體的指令攔截技術以後,
因為並沒有更低一層的 Hypervisor(VMM)隔離, 使得 hostos 與 VMM 都
工作在同一個 priviledged mode 以至於沒有 mapper(mmu , iommu) 隔
離. 由 VMM 對 hostsos 對其他 vm 的資訊存取做加密的原因就是隔離.

如果是 封包, 那是不用真的搬遷加解密, 實況是 pointer 與 descripor
在被 check 與移動, 真的搬出 VMM 才有實質加解密. 每個 VM(含 Dom0)
都有其 configuration, 真正的資源分配理論上就是 VMM 該知曉實況.
效率問題本就是虛擬機技術該持續改善的地方.

→ askeing:這只是封包部份，當所有VM的記憶體都加上一堆機制來加密…
→ askeing:我想  您的想法立意良好，但似乎有點太理想化了 ^^a
全軟體的 Emulator 就是道地的 掃瞄 所有程式指令, VMware用的就是 patch
技術. 也被微軟認為是病毒的感染手法.

資訊隔離技術 就跟 VM之間 需要相互隔離一樣, 一直就是存在的需求. 這理
想不太可能是高不可攀, secure hypervisor 只是個機制或工具, 其功能從外
部就能被檢核. 隔離遮蔽就如同人類的外衣, 該穿就穿, 該脫就脫, 核驗就如
同照鏡子, 由穿戴者就能自行檢驗. 至於衣服是否會在泡水後會被紅外照相機
攝相使之失效, 那仍然也是可以被檢驗的. 某種程度的防護是有必要的需求.

===========
正在雲端執行的程式應該是被解開來了, 假設雲端設備緊急停電, 立即要做
checkpoint 瞬間照相存檔, 這個太上要求, 假設就是要求 secure hypervisor
緊急配合, 不要遮蔽讓 OP 抄了備援. 那OP 豈不可以靠那份慢慢偷用偷看?

如遮蔽與軟體的執行都靠加解密, 當key離開車子, 通常就不能發動車子. 這
種有時效性的key也是常被用到, 針對租用者vm資訊做必要隔離加密的s-VMM
就可利用網路從使用者那裡取得有時效性的key, 這也能防被全抄挪用.


推 luciferii:這個時候VMM變成可以信任了...前面耍寶半天不知在幹嘛
→ luciferii:還有你又還繼續停留在 Hosted OS...唉...不可教也
→ askeing:硬體VMM沒玩過不清楚。
→ askeing:但是xen不是Binary Translation
XEN 是改 hostos 的 source code, 沒有 HVM support 前, guestos
也得改.

→ askeing:x86虛擬化麻煩就是有些指令只能跑在ring0，所以才有各種
→ askeing:方法要規避這問題。後來可以硬體支援之後可以跑HVM，
→ askeing:OS就可以直接跑在ring0, VMM種在ring-1做事。
→ askeing:以native來說，根本沒有host OS
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 ?

→ askeing:封包的部份現在實際就是這樣做，只是呼應老師的隱藏資訊
→ askeing:如果信任VMM，當然依照現況作法沒有問題。
→ askeing:最後一段，首先是虛擬化跟模擬是不同東西。
→ askeing:再來則是VM之間的隔離，與VM跟雲端公司操作者隔離是兩回事
→ askeing:VMM也是在操作者的手中，甚至硬體也是。
→ askeing:有一種覺得我不停在講相同東西的感覺 O_Oa
PC 也是整個都在使用者的手中, 但如果系統的某個權限不給, 這個使用者還是
被限制接取. 就如同硬碟內容被加密, 沒有解密key還是會看不見實際內容.

只要 OP 操控 hypervisor 做隱蔽隔離(Mapper mapping 或 加密)的權限被限制
與分割之後, 透過 Dom0 能否偷窺, 就是是否擁有依權限相關的 key 而定.

Hypervisor 的機制就是需要處理 "敏感的" 動作(或指令)而來的, 做到隔
離的要求本就是她的任務.

→ askeing:我說的HostOS是Host Based Virtualization的名詞
→ askeing:他位置在VMM下面，Dom0跑的架構根本不同，用hostOS很怪
→ askeing:如果以老師現在信任VMM的說法，不就推翻 #1Dw4nhyT 的假設
→ askeing:再者，PC在使用者手中，上面的OS也在使用者手中，所以能力
→ askeing:足夠的情況下，換硬體、換OS、改OS灌上去，都可以做到！
→ askeing:還是老師認為雲端服務公司的操作者沒那個能力？
→ askeing:而且更加詭譎的是，要設定權限讓Dom0不能做什麼事情，
→ askeing:結果還是靠Dom0探下去設定，設定的人也是那個雲端公司的人
→ askeing:這不是很奇怪嗎？
→ askeing:而所謂"敏感的指令"是說sensitive instructions？
→ askeing:那就跟現在虛擬化談的安全，要隔離各VM沒什麼關係
→ askeing:也許老師看到這名詞誤以為這是在說某些指令很令人敏感，
→ askeing:可能會操作到什麼機密資訊。 但是它指的不是這個意思，
→ askeing:可以參考 http://tinyurl.com/3k93ba6
→ askeing:BTW，硬碟加密跟記憶體加密是不同的東西。
→ askeing:老師如果真的想搞清楚虛擬化，
→ askeing:或真的覺得您提的方案非常合理，誠心建議您可以提給Xen
→ askeing:那邊應該更多專業好手，屆時老師可以回來分享 ^^
推 luciferii:唉...多講無益...
→ askeing:恩～我只是就我了解的、以及經驗，就算不從Dom0往下探
→ luciferii:其實看到掃毒是patch技術...VMWare也是Patch技術
→ askeing:直接在VMM裡面動手腳也是可以的…
→ luciferii:就知道不用講下去了...老師腦袋裏的技術跟實務在用的東
→ luciferii:西根本扯不上邊...
→ askeing:其實VMware現在大概不能算Patch技術了！？
→ askeing:可惜沒機會看到 ESX 的Code… Xen很多地方追不上他們
推 luciferii:Xen還有追...像商用的Xen其實是強在Desktop/App那塊
→ luciferii:其實是thinclient演化來的...這個VDI還不夠比
→ askeing:Ctrix XenServer嗎？他們的VDI聽說不錯～
→ luciferii:那也是虛擬化的一種...不過通常大家比的不是這個就是了.
→ luciferii:Citrix的XenServer就是Xen啦，對比ESX(VSphere(
→ askeing:主要看是哪塊應用啦～公司內的架構就可以用VDI了
→ luciferii:Citrix對應VDI的是XenDesktop, 另外一個只針對App虛擬化
→ askeing:恩，我剛剛寫錯，應該說 XenDesktop XD
→ askeing:不過VMware的改名叫做View了，VDI現在應該可以算統稱？
→ luciferii:的是 XenApp...
→ luciferii:VDI那個是名詞用久了，大家常講已經跟VMWare綁一起了:P
推 luciferii:VMM現在要用patch技術是蠻難的，VMWare是FV不用談，
→ luciferii:XenServer也頂多是driver可以PV
→ luciferii:以後HVM在雲端普及化後，就更都沒差了....
推 luciferii:至於防毒部分，現在的趨勢反而是希望掃毒能夠更靠VMM一
→ luciferii:點，所以VMWare有一大堆API給像T牌M牌去呼叫(例VMSafe)
→ luciferii:這個部分 Xen (還有喊的比作的大聲的Hyper-V) 就都還差
→ luciferii:的遠了。
→ luciferii:他們的目的才是Secure Hypervisor在努力的對象，所以看
→ luciferii:到一個名校老師亂扯一通，也只能又好氣又好笑
→ askeing:Citrix Mcafee 也是有在合作弄個open security API就是
================
→ 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 看狀況給予隨對象而異的結果.
==============

→ askeing:只是似乎 focus 在 XenDesktop 上的防毒！？
推 luciferii:如果是指 MOVE AV，那是針對VDI的，詳情可能要問另一位
→ luciferii:長輩，那個重點技術應該是在效能部份吧...
→ askeing:如果是說把動作集中往外導，那應該跟V家的滿像的 XD
→ askeing:如果不是的話就不清楚它們在做什麼了 :P
→ askeing:老師不要只找自己想看的部份
→ askeing:這篇 #1Dw4nhyT 就給過參考了 http://tinyurl.com/2wanyc
→ askeing:通常在業界討論的時候提Host OS人家想到就是Type 2
→ askeing:而最後這段sensitive instructions解釋也是對的
→ askeing:但無法解釋老師那句「隔離的要求本就是她的任務」！？？
推 luciferii:不太想繼續理他，一個名校老師淪落到人家說什麼就去
→ luciferii:google剪貼資料有點可悲...
===========
你要說的是這個:
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 由之查核後再執行, 不就是
為了避免相互干擾出錯? 隔離不就是可避免干擾?

推 luciferii:老師上課都是google完然後這樣亂用名詞和瞎掰人家架構
→ luciferii:的嗎?
→ askeing:那是架構的問題，沒硬體支援之前，靠得主要是PV，
→ askeing:至於Driver要放VMM還是Dom0有不同作法
→ askeing:老師要是去跟社群的人討論這議題時，還是不要用HostOS為好
→ askeing:最後，原先講的隔離是說資安上各VM之間的隔離
→ askeing:網路封包、記憶體…等 靠VMM的機制去分開
→ askeing:你最後提的隔離怎變成了各VM的指令不互相影響！？
→ askeing:各VM指令不互相影響本來就是虛擬畫的基本要求
→ askeing:但跟資安在VMM上提的隔離沒啥關係就是…(至少我這樣覺的)
假設 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)