Eksekusi program yang mungkin berbahaya di Linux


33

Saya sedang menulis program yang akan menguji program yang ditulis oleh siswa. Saya takut bahwa saya tidak dapat mempercayai mereka dan saya perlu memastikan bahwa itu tidak akan berakhir buruk bagi komputer yang menjalankannya.

Saya sedang berpikir tentang membuat beberapa pengguna crash test dengan akses terbatas ke sumber daya sistem dan menjalankan program sebagai pengguna itu, tetapi dari apa yang saya temukan di internet sejauh ini, membuat sistem virtual akan menjadi pilihan paling aman ...

Adakah yang bisa membantu saya memilih pendekatan yang tepat? Keamanan adalah masalah besar bagi saya. Di sisi lain, saya tidak ingin solusi yang berlebihan dan membuang banyak waktu untuk belajar sesuatu yang saya tidak benar-benar butuhkan.


7
Jalankan saja program di linux di browser ( bellard.org/jslinux ). Itu kotak pasir yang sangat bagus. :)
Fixee

wow, itu sangat menarik! Namun saya harus menulis semacam antarmuka untuk menggunakannya (karena seluruh proses akan menjadi otomatis) ... Saya perlu memeriksanya. Jika ternyata Javascript Linux ini lebih dari gadget saya bahkan dapat menggunakannya.
korda

Saya benar-benar bermaksud komentar saya sebagai lelucon, tetapi jika Anda benar-benar dapat menggunakannya, itu akan luar biasa. Jujur, jawaban LiveCD (dengan RAMdisk) adalah solusi yang bagus.
Fixee

Ya, jika saya ingin menggunakannya, saya juga akan menggunakannya di halaman web tempat saya dapat mengakses hasilnya - itu akan sangat bagus dan nyaman. Juga faktor geek penting;) juga live disk bukan opsi - seperti yang saya katakan saya sedang membuat program itu akan berjalan pada beberapa server sehingga reboot bukanlah sesuatu yang saya mampu ... Saya kira saya akan tetap menggunakan mesin virtual. ..
korda

Jawaban:


28
  • Mesin virtual dapat memberi Anda keamanan tertinggi tanpa reboot, tetapi kinerja paling rendah.

  • Pilihan lain, bahkan untuk keamanan yang lebih tinggi daripada mesin virtual: boot CD / DVD / flashdisk "live" tanpa akses ke hard drive (nonaktifkan sementara HDD di BIOS; jika Anda tidak bisa, setidaknya jangan pasang drive / unmount itu, jika dipasang secara otomatis - tetapi ini jauh lebih tidak aman)

  • Sebuah buruh pelabuhan kontainer adalah sedikit kurang alternatif aman untuk mesin virtual penuh. Mungkin perbedaan penting (dalam hal keamanan) antara keduanya adalah bahwa sistem yang berjalan di buruh pelabuhan benar-benar menggunakan kernel sistem host Anda.

  • Ada beberapa program seperti isolate yang akan menciptakan lingkungan yang aman dan khusus - ini biasanya disebut kotak pasir - yang biasanya berbasis chroot, dengan pengawasan tambahan - temukan yang sesuai untuk Anda.

  • Chroot sederhana akan paling tidak aman (khususnya dalam hal menjalankan program), meskipun mungkin sedikit lebih cepat, tapi ... Anda harus membuat / menyalin seluruh pohon root terpisah dan menggunakan bind mounts untuk /devdll. (Lihat Catatan 1 di bawah!). Jadi secara umum, pendekatan ini tidak dapat direkomendasikan, terutama jika Anda dapat menggunakan lingkungan yang lebih aman, dan seringkali lebih mudah diatur sandbox.

Catatan 0: Untuk aspek "pengguna khusus", sepertinobodyakun: Ini hampir tidak memberikankeamanan apa pun , apalagi yang sederhanachroot. Seorangnobodypengguna masih dapat mengakses file dan program yang telah membaca dan mengeksekusi izin yang ditetapkan untuk lainnya . Anda dapat mengujinya dengansu -s /bin/sh -c 'some command' nobody. Dan jika Anda memiliki file konfigurasi / histori / cache yang dapat diakses oleh siapa saja (karena kesalahan atau lubang keamanan kecil), program yang berjalan dengannobodyizin dapat mengaksesnya, mencari data rahasia (seperti "pass =" dll.) Dan di banyak cara mengirimnya melalui internet atau apa pun.

Catatan 1: Seperti yang ditunjukkan Gilles dalam komentar di bawah , lingkungan chroot yang sederhana akan memberikan keamanan yang sangat kecil terhadap eksploitasi yang bertujuan untuk meningkatkan hak istimewa. Sebuah tunggal chroot masuk akal keamanan-bijaksana, hanya jika lingkungan minimal, yang terdiri dari program keamanan yang dikonfirmasi hanya (tapi masih tetap ada risiko mengeksploitasi kerentanan kernel-level potensial), dan semua program yang tidak dipercaya berjalan di chroot menjalankan sebagai pengguna yang tidak menjalankan proses apa pun di luar chroot. Apa chroot tidak mencegah terhadap (dengan pembatasan yang disebutkan di sini), adalah penetrasi sistem langsung tanpa eskalasi hak istimewa. Namun, seperti yang dicatat Gilles dalam komentar lain, bahkan tingkat keamanan itu bisa dielakkan, yang memungkinkan program untuk keluar dari chroot.


Terima kasih atas jawabannya. Saya benar-benar seorang pemula dalam hal-hal seperti itu, dapatkah Anda menjelaskan satu hal: mengapa saya perlu mencegah program membaca file dalam sistem (misalnya dengan chroot)? (jika program tidak dapat memodifikasinya).
korda

Sebuah akun pengguna tes kecelakaan memberi Anda beberapa keamanan dasar pasti. Masih ada beberapa hal yang mungkin ingin / perlu Anda cegah. Itu bisa dalam bentuk eksploitasi kerentanan umum yang tertanam dalam program atau peretasan sosial, pengumpulan informasi untuk tujuan serangan jarak jauh di masa depan ... Dan mungkin jauh lebih banyak.
rozcietrzewiacz

Mengapa demikian: adakah cara untuk mencegah pengguna menggunakan koneksi internet?
korda

1
Saya ingin tahu apakah nobodymemiliki akses internet.
korda

1
@rozcietrzewiacz Persyaratan penting bagi chroot untuk memberikan perlindungan adalah tidak menjalankan program chroot sebagai pengguna yang juga menjalankan program di luar chroot. Kalau tidak, proses chroot dapat melacak proses non-chroot dan melakukan apa pun dengan cara itu.
Gilles 'SO- stop being evil'

10

Gunakan mesin virtual. Kurang dari itu tidak memberikan banyak keamanan.

Beberapa tahun yang lalu saya mungkin menyarankan pengguna khusus chroot atau semacamnya. Tetapi perangkat keras telah menjadi lebih kuat, dan perangkat lunak mesin virtual menjadi lebih mudah digunakan. Selain itu, serangan di luar rak semakin canggih. Tidak ada alasan lagi untuk tidak pergi jauh-jauh ke sini.

Saya akan merekomendasikan menjalankan VirtualBox. Anda dapat mengatur mesin virtual dalam beberapa menit, kemudian menginstal distribusi Linux di dalamnya. Satu-satunya pengaturan non-standar yang saya sarankan adalah pengaturan jaringan: buat antarmuka "NAT" (untuk berkomunikasi dengan dunia) dan antarmuka "host saja" (sehingga Anda dapat dengan mudah menyalin file ke dan dari host, dan ssh ke VM). Nonaktifkan antarmuka NAT saat Anda menjalankan program siswa¹ Anda; aktifkan hanya ketika Anda menginstal atau meningkatkan paket perangkat lunak.

Di dalam mesin virtual, buat satu pengguna per siswa.

¹ Anda dapat membatasi antarmuka NAT ke daftar putih pengguna, tetapi itu lebih canggih daripada yang Anda butuhkan dalam pengaturan sederhana, to-the-point.


2

di sini adalah penjelasan yang sangat menyeluruh tentang mengapa menggunakan Chroot masih merupakan opsi yang sangat layak, dan mengapa sistem operasi penuh atau virtualisasi perangkat keras penuh terutama berlebihan dalam skenario tertentu.

tidak lebih dari mitos bahwa Chroot bukan fitur keamanan. ada alat yang akan membangun sistem file chroot secara otomatis untuk Anda, dan Chroot dibangun ke dalam banyak aplikasi utama sebagai fitur keamanan yang disengaja.

bertentangan dengan kepercayaan populer, tidak setiap situasi memerlukan virtualisasi penuh sistem operasi, atau simulasi penuh perangkat keras. ini bisa berarti memiliki lebih banyak permukaan serangan untuk dicoba dan ditutup. pada gilirannya, berarti sistem yang kurang aman . (konon untuk administrator sistem yang kurang berpengetahuan)

aturannya cukup sederhana: jangan masukkan apa pun ke dalam chroot yang tidak perlu. jangan jalankan daemon sebagai root. jangan menjalankan daemon karena setiap pengguna menjalankan daemon di luar chroot.

hapus semua aplikasi tidak aman, binari setuid, menggantung symlink / hardlink tanpa pemilik. remount folder yang tidak perlu menggunakan nosuid, noexec dan nodev. membangun versi stabil terbaru dari daemon yang berjalan dari sumber. dan yang terpenting, amankan sistem basis!


2

Saya akan menambahkan ini, baik setelah pertanyaan secara resmi dijawab: MAGIC: Malicious Aging in Circuits / Cores , yang sayangnya terkunci di balik paywall ACM. Hasilnya kertas adalah bahwa jejak yang sangat kecil di sirkuit yang digunakan saat ini menua saat digunakan, dan akhirnya rusak. Dengan menemukan instruksi yang benar dan mengulanginya berulang-ulang, seorang penyerang bisa membuat IC gagal.

Tidak satu pun dari VM atau kotak pasir atau wadah atau chroot jail akan mencegah perusakan perangkat keras semacam ini. Para penulis makalah ini menemukan urutan instruksi seperti itu, dan perangkat keras yang berusia percobaan mengalami kegagalan, tetapi mereka tidak memberikan instruksi, sehingga mungkin tidak menjadi ancaman nyata untuk sementara waktu.


1

Pada BSD berasal unix (termasuk Mac OS X) ada fasilitas yang disebut sandbox. Kata halaman buku itu

KETERANGAN
Fasilitas kotak pasir memungkinkan aplikasi untuk secara sukarela membatasi akses mereka ke sumber daya sistem operasi. Mekanisme keselamatan ini dimaksudkan untuk membatasi potensi kerusakan jika kerentanan dieksploitasi. Ini bukan pengganti untuk kontrol akses sistem operasi lain.

Ini terpisah dari chrootfasilitas yang juga tersedia.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.