QubesOS-ის გამოყენება Windows 7-თან მუშაობისთვის

არ არის ბევრი სტატია Habré-ზე, რომელიც მიეძღვნა Qubes ოპერაციულ სისტემას და ის, რაც მე მინახავს, ​​არ აღწერს მისი გამოყენების გამოცდილებას. ჭრილის ქვემოთ, ვიმედოვნებ, რომ გამოვასწორებ ამას Qubes-ის, როგორც Windows-ის გარემოს დაცვის საშუალებად გამოყენების მაგალითის გამოყენებით და, ამავე დროს, შევაფასებ სისტემის რუსულენოვანი მომხმარებლების რაოდენობას.

რატომ Qubes?

Windows 7-ის ტექნიკური მხარდაჭერის დასრულების ისტორიამ და მომხმარებელთა მზარდმა შფოთვამ განაპირობა ამ OS-ის მუშაობის ორგანიზების აუცილებლობა, შემდეგი მოთხოვნების გათვალისწინებით:

• უზრუნველყოს სრულად გააქტიურებული Windows 7-ის გამოყენება მომხმარებლისთვის განახლებების და სხვადასხვა აპლიკაციების (მათ შორის ინტერნეტის საშუალებით) დაყენების შესაძლებლობით;
• განახორციელოს ქსელური ურთიერთქმედების სრული ან შერჩევითი გამორიცხვა პირობების საფუძველზე (ავტონომიური მუშაობა და ტრაფიკის ფილტრაციის რეჟიმი);
• უზრუნველყოფს მოსახსნელი მედიისა და მოწყობილობების შერჩევითად დაკავშირების შესაძლებლობას.

შეზღუდვების ეს ნაკრები გულისხმობს აშკარად მომზადებულ მომხმარებელს, რადგან დამოუკიდებელი ადმინისტრირება ნებადართულია და შეზღუდვები არ არის დაკავშირებული მისი პოტენციური მოქმედებების დაბლოკვასთან, არამედ შესაძლო შეცდომების ან დესტრუქციული პროგრამული ეფექტების გამორიცხვასთან. იმათ. მოდელში შიდა დამნაშავე არ არის.

გამოსავლის ძიებისას ჩვენ სწრაფად მივატოვეთ შეზღუდვების განხორციელების იდეა ჩაშენებული ან დამატებითი Windows ინსტრუმენტების გამოყენებით, რადგან საკმაოდ რთულია ადმინისტრატორის უფლებების მქონე მომხმარებლის ეფექტურად შეზღუდვა, რაც მას აპლიკაციების ინსტალაციის შესაძლებლობას უტოვებს.

შემდეგი გამოსავალი იყო იზოლაცია ვირტუალიზაციის გამოყენებით. დესკტოპის ვირტუალიზაციის ცნობილი ინსტრუმენტები (მაგალითად, ვირტუალური ყუთი) ცუდად არის შესაფერისი უსაფრთხოების პრობლემების გადასაჭრელად და ჩამოთვლილი შეზღუდვები მომხმარებელმა უნდა შეასრულოს სტუმრის ვირტუალური მანქანის თვისებების მუდმივი გადართვით ან რეგულირებით (შემდგომში - როგორც VM), რაც ზრდის შეცდომების რისკს.

ამავდროულად, ჩვენ გვქონდა Qubes-ის, როგორც მომხმარებლის დესკტოპის სისტემის გამოყენების გამოცდილება, მაგრამ გვქონდა ეჭვი სტუმრებთან მუშაობის სტაბილურობაში. გადაწყდა Qubes-ის ამჟამინდელი ვერსიის შემოწმება, რადგან აღნიშნული შეზღუდვები ძალიან კარგად ჯდება ამ სისტემის პარადიგმაში, განსაკუთრებით ვირტუალური მანქანების შაბლონების დანერგვა და ვიზუალური ინტეგრაცია. შემდეგ ვეცდები მოკლედ ვისაუბრო ქუბესის იდეებსა და ინსტრუმენტებზე, პრობლემის გადაჭრის მაგალითის გამოყენებით.

Xen ვირტუალიზაციის სახეები

Qubes დაფუძნებულია Xen ჰიპერვიზორზე, რომელიც ამცირებს პროცესორის რესურსების, მეხსიერების და ვირტუალური მანქანების მართვის ფუნქციებს. ყველა სხვა სამუშაო მოწყობილობებთან კონცენტრირებულია dom0-ში, Linux-ის ბირთვის საფუძველზე (Qubes for dom0 იყენებს Fedora დისტრიბუციას).

Xen მხარს უჭერს ვირტუალიზაციის რამდენიმე ტიპს (მაგალითებს მოვიყვან Intel არქიტექტურისთვის, თუმცა Xen მხარს უჭერს სხვებს):

• პარავირტუალიზაცია (PV) - ვირტუალიზაციის რეჟიმი ტექნიკის მხარდაჭერის გამოყენების გარეშე, რომელიც მოგვაგონებს კონტეინერის ვირტუალიზაციას, შეიძლება გამოყენებულ იქნას ადაპტირებული ბირთვის მქონე სისტემებისთვის (dom0 მუშაობს ამ რეჟიმში);
• სრული ვირტუალიზაცია (HVM) - ამ რეჟიმში, ტექნიკის მხარდაჭერა გამოიყენება პროცესორის რესურსებისთვის, ხოლო ყველა სხვა მოწყობილობა ემულირებულია QEMU გამოყენებით. ეს არის ყველაზე უნივერსალური გზა სხვადასხვა ოპერაციული სისტემის გასაშვებად;
• აპარატურის პარავირტუალიზაცია (PVH - ParaVirtualized Hardware) - ვირტუალიზაციის რეჟიმი ტექნიკის მხარდაჭერის გამოყენებით, როდესაც, აპარატურასთან მუშაობისთვის, სტუმრის სისტემის ბირთვი იყენებს ჰიპერვიზორის შესაძლებლობებზე ადაპტირებული დრაივერებს (მაგალითად, საერთო მეხსიერება), რაც გამორიცხავს QEMU ემულაციის საჭიროებას. და I/O შესრულების გაზრდა. Linux-ის ბირთვი, რომელიც იწყება 4.11-დან, შეუძლია ამ რეჟიმში იმუშაოს.

Qubes 4.0-დან დაწყებული, უსაფრთხოების მიზეზების გამო, პარავირტუალიზაციის რეჟიმის გამოყენება მიტოვებულია (მათ შორის Intel-ის არქიტექტურაში ცნობილი დაუცველობის გამო, რომელიც ნაწილობრივ შერბილებულია სრული ვირტუალიზაციის გამოყენებით); PVH რეჟიმი გამოიყენება ნაგულისხმევად.

ემულაციის გამოყენებისას (HVM რეჟიმი), QEMU იხსნება იზოლირებულ VM-ში, სახელწოდებით stubdomain, რითაც ამცირებს პოტენციური შეცდომების გამოყენების რისკს იმპლემენტაციაში (QEMU პროექტი შეიცავს უამრავ კოდს, მათ შორის თავსებადობისთვის).
ჩვენს შემთხვევაში, ეს რეჟიმი უნდა იყოს გამოყენებული Windows-ისთვის.

ვირტუალური მანქანების სერვისი

Qubes-ის უსაფრთხოების არქიტექტურაში ჰიპერვიზორის ერთ-ერთი მთავარი შესაძლებლობა არის PCI მოწყობილობების გადატანა სტუმრის გარემოში. ტექნიკის გამორიცხვა საშუალებას გაძლევთ გამოყოთ სისტემის მასპინძელი ნაწილი გარე შეტევებისგან. Xen მხარს უჭერს PV და HVM რეჟიმებს, მეორე შემთხვევაში ის მოითხოვს მხარდაჭერას IOMMU (Intel VT-d) - ტექნიკის მეხსიერების მართვა ვირტუალური მოწყობილობებისთვის.

ეს ქმნის რამდენიმე სისტემის ვირტუალურ მანქანას:

• sys-net, რომელზედაც გადადის ქსელური მოწყობილობები და რომელიც გამოიყენება ხიდად სხვა VM-ებისთვის, მაგალითად, ისინი, რომლებიც ახორციელებენ firewall-ის ან VPN კლიენტის ფუნქციებს;
• sys-usb, რომელზეც გადადის USB და სხვა პერიფერიული მოწყობილობის კონტროლერები;
• sys-firewall, რომელიც არ იყენებს მოწყობილობებს, მაგრამ მუშაობს როგორც Firewall დაკავშირებული VM-ებისთვის.

USB მოწყობილობებთან მუშაობისთვის გამოიყენება პროქსი სერვისები, რომლებიც სხვა საკითხებთან ერთად გთავაზობთ:

• HID (ადამიანის ინტერფეისის მოწყობილობა) მოწყობილობის კლასისთვის, ბრძანებების გაგზავნა dom0-ზე;
• მოსახსნელი მედიისთვის, მოწყობილობის ტომების გადამისამართება სხვა VM-ებზე (გარდა dom0-ისა);
• პირდაპირ USB მოწყობილობაზე გადამისამართება (USBIP და ინტეგრაციის ხელსაწყოების გამოყენებით).

ასეთ კონფიგურაციაში, წარმატებულმა შეტევამ ქსელის სტეკის ან დაკავშირებული მოწყობილობების მეშვეობით შეიძლება გამოიწვიოს მხოლოდ გაშვებული VM სერვისის კომპრომისამდე და არა მთლიანად სისტემის მთლიანობაში. და სერვისის VM-ის გადატვირთვის შემდეგ, ის ჩაიტვირთება თავდაპირველ მდგომარეობაში.

VM ინტეგრაციის ინსტრუმენტები

ვირტუალური აპარატის სამუშაო მაგიდასთან ურთიერთქმედების რამდენიმე გზა არსებობს - სტუმრების სისტემაში აპლიკაციების დაყენება ან ვირტუალიზაციის ხელსაწყოების გამოყენებით ვიდეოს ემულაცია. სტუმრის აპლიკაციები შეიძლება იყოს სხვადასხვა უნივერსალური დისტანციური წვდომის ხელსაწყოები (RDP, VNC, Spice და ა.შ.) ან ადაპტირებული კონკრეტულ ჰიპერვიზორზე (ასეთ ინსტრუმენტებს, როგორც წესი, სტუმრის კომუნალურებს უწოდებენ). შერეული ვარიანტის გამოყენება ასევე შეიძლება, როდესაც ჰიპერვიზორი ახდენს I/O-ს ემულაციას სტუმრის სისტემისთვის და გარედან უზრუნველყოფს პროტოკოლის გამოყენების შესაძლებლობას, რომელიც აერთიანებს I/O-ს, მაგალითად, Spice-ის მსგავსად. ამავდროულად, დისტანციური წვდომის ხელსაწყოები, როგორც წესი, ახდენენ გამოსახულების ოპტიმიზაციას, რადგან ისინი გულისხმობენ მუშაობას ქსელის საშუალებით, რაც არ ახდენს დადებით გავლენას სურათის ხარისხზე.

Qubes გთავაზობთ საკუთარ ინსტრუმენტებს VM ინტეგრაციისთვის. უპირველეს ყოვლისა, ეს არის გრაფიკული ქვესისტემა - ფანჯრები სხვადასხვა ვირტუალური მეხსიერებიდან გამოსახულია ერთ სამუშაო მაგიდაზე საკუთარი ფერის ჩარჩოებით. ზოგადად, ინტეგრაციის ინსტრუმენტები დაფუძნებულია ჰიპერვიზორის შესაძლებლობებზე - გაზიარებული მეხსიერება (Xen საგრანტო ცხრილი), შეტყობინებების ხელსაწყოები (Xen მოვლენის არხი), საერთო შენახვის xenstore და vchan საკომუნიკაციო პროტოკოლი. მათი დახმარებით ხორციელდება ძირითადი კომპონენტები qrexec და qubes-rpc და აპლიკაციის სერვისები - აუდიო ან USB გადამისამართება, ფაილების ან ბუფერში შინაარსის გადაცემა, ბრძანებების შესრულება და აპლიკაციების გაშვება. შესაძლებელია დაწესდეს პოლიტიკა, რომელიც საშუალებას მოგცემთ შეზღუდოთ VM-ზე ხელმისაწვდომი სერვისები. ქვემოთ მოყვანილი ფიგურა არის ორი VM-ის ურთიერთქმედების ინიციალიზაციის პროცედურის მაგალითი.

ამრიგად, VM-ში მუშაობა ხორციელდება ქსელის გამოყენების გარეშე, რაც იძლევა ავტონომიური VM-ების სრულ გამოყენებას ინფორმაციის გაჟონვის თავიდან ასაცილებლად. მაგალითად, ასე ხორციელდება კრიპტოგრაფიული ოპერაციების (PGP/SSH) გამიჯვნა, როდესაც პირადი გასაღებები გამოიყენება იზოლირებულ VM-ებში და არ სცილდება მათ.

შაბლონები, აპლიკაცია და ერთჯერადი VM-ები

Qubes-ში მომხმარებლის ყველა სამუშაო კეთდება ვირტუალურ მანქანებში. ძირითადი მასპინძელი სისტემა გამოიყენება მათი კონტროლისა და ვიზუალიზაციისთვის. OS დაინსტალირებულია შაბლონებზე დაფუძნებული ვირტუალური მანქანების ძირითად კომპლექტთან ერთად (TemplateVM). ეს შაბლონი არის Linux VM, რომელიც დაფუძნებულია Fedora ან Debian დისტრიბუციაზე, ინტეგრაციის ხელსაწყოებით დაინსტალირებული და კონფიგურირებული, გამოყოფილი სისტემისა და მომხმარებლის დანაყოფებით. პროგრამული უზრუნველყოფის ინსტალაცია და განახლება ხორციელდება სტანდარტული პაკეტის მენეჯერის მიერ (dnf ან apt) კონფიგურირებული საცავებიდან სავალდებულო ციფრული ხელმოწერის გადამოწმებით (GnuPG). ასეთი VM-ების მიზანია უზრუნველყოს ნდობა აპლიკაციის VM-ების მიმართ, რომლებიც გაშვებულია მათ საფუძველზე.

ჩატვირთვისას, VM აპლიკაცია (AppVM) იყენებს შესაბამისი VM შაბლონის სისტემის დანაყოფის სურათს და დასრულების შემდეგ წაშლის ამ სურათს ცვლილებების შენახვის გარეშე. მომხმარებლის მიერ მოთხოვნილი მონაცემები ინახება მომხმარებლის დანაყოფში, რომელიც უნიკალურია თითოეული VM აპლიკაციისთვის, რომელიც დამონტაჟებულია სახლის დირექტორიაში.

ერთჯერადი VM-ების გამოყენება (disposableVM) შეიძლება სასარგებლო იყოს უსაფრთხოების თვალსაზრისით. ასეთი VM იქმნება შაბლონის საფუძველზე გაშვების დროს და იხსნება ერთი მიზნით - შეასრულოს ერთი აპლიკაცია, დასრულდეს სამუშაოები დახურვის შემდეგ. ერთჯერადი ვირტუალური მანქანების გამოყენება შესაძლებელია საეჭვო ფაილების გასახსნელად, რომელთა შიგთავსმა შეიძლება გამოიწვიოს კონკრეტული აპლიკაციის დაუცველობის გამოყენება. ერთჯერადი VM-ის გაშვების შესაძლებლობა ინტეგრირებულია ფაილების მენეჯერთან (Nautilus) და ელ.ფოსტის კლიენტთან (Thunderbird).

Windows VM ასევე შეიძლება გამოყენებულ იქნას შაბლონისა და ერთჯერადი VM-ის შესაქმნელად მომხმარებლის პროფილის ცალკე განყოფილებაში გადატანით. ჩვენს ვერსიაში, ასეთ შაბლონს მომხმარებელი გამოიყენებს ადმინისტრაციის ამოცანებისა და აპლიკაციის ინსტალაციისთვის. შაბლონზე დაყრდნობით შეიქმნება რამდენიმე აპლიკაციის VM - ქსელში შეზღუდული წვდომით (სტანდარტული sys-firewall შესაძლებლობები) და საერთოდ ქსელში წვდომის გარეშე (ვირტუალური ქსელის მოწყობილობა არ არის შექმნილი). შაბლონში დაინსტალირებული ყველა ცვლილება და აპლიკაცია ხელმისაწვდომი იქნება ამ VM-ებში სამუშაოდ და სანიშნეების პროგრამების დანერგვის შემთხვევაშიც კი, მათ არ ექნებათ ქსელში წვდომა კომპრომისისთვის.

ბრძოლა Windows-ისთვის

ზემოთ აღწერილი ფუნქციები არის Qubes-ის საფუძველი და მუშაობს საკმაოდ სტაბილურად; სირთულეები იწყება Windows-ით. Windows-ის ინტეგრირებისთვის, თქვენ უნდა გამოიყენოთ სტუმრების ინსტრუმენტების ნაკრები Qubes Windows Tools (QWT), რომელიც მოიცავს დრაივერებს Xen-თან მუშაობისთვის, qvideo დრაივერს და ინფორმაციის გაცვლის კომუნალურ პროგრამებს (ფაილის გადაცემა, ბუფერში). ინსტალაციისა და კონფიგურაციის პროცესი დეტალურად არის დოკუმენტირებული პროექტის ვებსაიტზე, ამიტომ ჩვენ გაგიზიარებთ აპლიკაციის გამოცდილებას.

მთავარი სირთულე არსებითად განვითარებული ინსტრუმენტების მხარდაჭერის ნაკლებობაა. Key Developers (QWT), როგორც ჩანს, მიუწვდომელია და Windows-ის ინტეგრაციის პროექტი ელოდება მთავარ დეველოპერს. ამიტომ, უპირველეს ყოვლისა, საჭირო იყო მისი შესრულების შეფასება და საჭიროების შემთხვევაში დამოუკიდებლად მხარდაჭერის შესაძლებლობის გააზრება. ყველაზე რთული შემუშავება და გამართვა არის გრაფიკული დრაივერი, რომელიც ასახავს ვიდეო ადაპტერს და დისპლეის გამოსახულების გენერირებას საერთო მეხსიერებაში, რაც საშუალებას გაძლევთ აჩვენოთ მთელი სამუშაო მაგიდა ან აპლიკაციის ფანჯარა პირდაპირ მასპინძელი სისტემის ფანჯარაში. დრაივერის მუშაობის ანალიზის დროს, ჩვენ მოვახდინეთ კოდის შეკრების ადაპტაცია Linux-ის გარემოში და შევიმუშავეთ გამართვის სქემა Windows-ის ორ სტუმარ სისტემას შორის. Crossbuild-ის ეტაპზე ჩვენ შევიტანეთ რამდენიმე ცვლილება, რამაც გაამარტივა ყველაფერი ჩვენთვის, ძირითადად კომუნალური საშუალებების „ჩუმად“ ინსტალაციის თვალსაზრისით და ასევე აღმოვფხვრათ შესრულების შემაშფოთებელი დეგრადაცია VM-ში დიდი ხნის განმავლობაში მუშაობისას. სამუშაოს შედეგები ცალკე წარმოვადგინეთ საცავები, შესაბამისად არც ისე დიდი ხნით შთამაგონებელი Qubes-ის წამყვანი დეველოპერი.

სტუმრების სისტემის სტაბილურობის თვალსაზრისით ყველაზე კრიტიკული ეტაპი არის Windows-ის გაშვება, აქ შეგიძლიათ ნახოთ ნაცნობი ლურჯი ეკრანი (ან არც კი ნახოთ). გამოვლენილი შეცდომების უმეტესობისთვის იყო სხვადასხვა გამოსავალი - Xen ბლოკის მოწყობილობის დრაივერების აღმოფხვრა, VM მეხსიერების დაბალანსების გამორთვა, ქსელის პარამეტრების დაფიქსირება და ბირთვების რაოდენობის შემცირება. ჩვენი სტუმრების ხელსაწყოები აშენებს ინსტალაციას და მუშაობს სრულად განახლებულ Windows 7-ზე და Windows 10-ზე (გარდა qvideo).

რეალური გარემოდან ვირტუალურ გარემოზე გადასვლისას პრობლემა ჩნდება Windows-ის გააქტიურებასთან დაკავშირებით, თუ გამოიყენება წინასწარ დაინსტალირებული OEM ვერსიები. ასეთი სისტემები იყენებენ აქტივაციას მოწყობილობის UEFI-ში მითითებულ ლიცენზიებზე დაყრდნობით. აქტივაციის სწორად დასამუშავებლად, აუცილებელია მასპინძელი სისტემის (SLIC ცხრილი) მთელი ACPI განყოფილების გადათარგმნა სტუმრის სისტემაში და ოდნავ დაარედაქტიროთ სხვები, დაარეგისტრიროთ მწარმოებელი. Xen საშუალებას გაძლევთ დააკონფიგურიროთ დამატებითი ცხრილების ACPI შინაარსი, მაგრამ ძირითადი ცხრილების შეცვლის გარეშე. მსგავსი OpenXT პროექტის პატჩი, რომელიც ადაპტირებული იყო Qubes-ისთვის, დაეხმარა გამოსავალს. შესწორებები სასარგებლო ჩანდა არა მხოლოდ ჩვენთვის და ითარგმნა Qubes-ის მთავარ საცავში და Libvirt ბიბლიოთეკაში.

Windows ინტეგრაციის ხელსაწყოების აშკარა ნაკლოვანებები მოიცავს აუდიო, USB მოწყობილობების მხარდაჭერის ნაკლებობას და მედიასთან მუშაობის სირთულეს, რადგან არ არსებობს GPU-ს აპარატურის მხარდაჭერა. მაგრამ ეს არ უშლის ხელს VM-ის გამოყენებას საოფისე დოკუმენტებთან მუშაობისთვის და არც კონკრეტული კორპორატიული აპლიკაციების გაშვებას.

Windows VM შაბლონის შექმნის შემდეგ ოპერაციულ რეჟიმში გადასვლის მოთხოვნა ქსელის გარეშე ან შეზღუდული ქსელით შესრულდა აპლიკაციის VM-ების შესაბამისი კონფიგურაციების შექმნით, ხოლო მოსახსნელი მედიის შერჩევითი დაკავშირების შესაძლებლობა ასევე გადაწყდა სტანდარტული OS ინსტრუმენტებით - როდესაც დაკავშირება , ისინი ხელმისაწვდომია VM sys-usb სისტემაში, საიდანაც შესაძლებელია მათი "გადაგზავნა" საჭირო VM-ში. მომხმარებლის დესკტოპი ასე გამოიყურება.

სისტემის საბოლოო ვერსია დადებითად (რამდენადაც ასეთი ყოვლისმომცველი გადაწყვეტა საშუალებას იძლევა) მიიღეს მომხმარებლების მიერ და სისტემის სტანდარტულმა ინსტრუმენტებმა შესაძლებელი გახადა აპლიკაციის გაფართოება მომხმარებლის მობილურ სამუშაო სადგურზე VPN-ით წვდომით.

იმის ნაცვლად, რომ დასკვნა

ზოგადად ვირტუალიზაცია საშუალებას გაძლევთ შეამციროთ მხარდაჭერის გარეშე დარჩენილი Windows სისტემების გამოყენების რისკები - ის არ აიძულებს თავსებადობას ახალ აპარატურასთან, ის საშუალებას გაძლევთ გამორიცხოთ ან აკონტროლოთ სისტემაში წვდომა ქსელის ან დაკავშირებული მოწყობილობების საშუალებით და საშუალებას გაძლევთ დანერგეთ ერთჯერადი გაშვების გარემო.

ვირტუალიზაციის საშუალებით იზოლაციის იდეაზე დაყრდნობით, Qubes OS გეხმარებათ გამოიყენოთ უსაფრთხოების ეს და სხვა მექანიზმები. გარედან ბევრი ადამიანი ქუბესს უპირველეს ყოვლისა ანონიმურობის სურვილად ხედავს, მაგრამ ეს არის სასარგებლო სისტემა როგორც ინჟინრებისთვის, რომლებიც ხშირად ჯონგლირებენ პროექტებს, ინფრასტრუქტურებსა და საიდუმლოებებს მათზე წვდომისთვის, ასევე უსაფრთხოების მკვლევარებისთვის. აპლიკაციების გამიჯვნა, მონაცემები და მათი ურთიერთქმედების ფორმალიზება საფრთხის ანალიზისა და უსაფრთხოების სისტემის დიზაინის საწყისი საფეხურებია. ეს განცალკევება ხელს უწყობს ინფორმაციის სტრუქტურირებას და ამცირებს ადამიანური ფაქტორის გამო შეცდომების ალბათობას - აჩქარებას, დაღლილობას და ა.შ.

ამჟამად განვითარებაში მთავარი აქცენტი კეთდება Linux-ის გარემოს ფუნქციონირების გაფართოებაზე. 4.1 ვერსია მზადდება გამოსაშვებად, რომელიც დაფუძნებული იქნება Fedora 31-ზე და მოიცავს Xen-ისა და Libvirt-ის ძირითადი კომპონენტების მიმდინარე ვერსიებს. აღსანიშნავია, რომ Qubes შექმნილია ინფორმაციული უსაფრთხოების პროფესიონალების მიერ, რომლებიც ყოველთვის ავრცელებენ განახლებებს ახალი საფრთხეების ან შეცდომების გამოვლენის შემთხვევაში.

Afterword

ერთ-ერთი ექსპერიმენტული შესაძლებლობა, რომელსაც ჩვენ ვავითარებთ, გვაძლევს საშუალებას შევქმნათ VM-ები GPU-ზე სტუმრის წვდომის მხარდაჭერით Intel GVT-g ტექნოლოგიაზე, რაც საშუალებას გვაძლევს გამოვიყენოთ გრაფიკული ადაპტერის შესაძლებლობები და მნიშვნელოვნად გავაფართოვოთ სისტემის ფარგლები. წერის დროს, ეს ფუნქცია მუშაობს Qubes 4.1-ის სატესტო ნაგებობებზე და ხელმისაწვდომია გითუბი.

წყარო: www.habr.com