সচরাচর জিজ্ঞাস্য

আমি কি থ্রেড ব্যবহার করতে পারি?

হ্যাঁ, থ্রেড স্যান্ডবক্স 2 এ সমর্থিত।

সব থ্রেড স্যান্ডবক্স করা আবশ্যক

Linux যেভাবে কাজ করে তার কারণে, seccomp-bpf নীতি শুধুমাত্র বর্তমান থ্রেডে প্রয়োগ করা হয়: এর মানে এই নীতিটি অন্য বিদ্যমান থ্রেডগুলিতে প্রয়োগ করা হয় না, তবে ভবিষ্যতের থ্রেডগুলি এই নীতির উত্তরাধিকারী হবে:

• আপনি যদি প্রথম মোডে স্যান্ডবক্স 2 ব্যবহার করেন যেখানে execve() এর আগে স্যান্ডবক্সিং সক্ষম করা হয়, তবে সমস্ত থ্রেড নীতির উত্তরাধিকারী হবে এবং কোনও সমস্যা নেই। এটি স্যান্ডবক্সিংয়ের পছন্দের মোড।
• আপনি যদি দ্বিতীয় মোডটি ব্যবহার করেন যেখানে নির্বাহক set_enable_sandbox_before_exec(false) করেছে এবং Sandboxee নির্বাহককে বলে যখন এটি SandboxMeHere() দিয়ে স্যান্ডবক্স করতে চায়, নিশ্চিত করুন ফিল্টারটি সমস্ত থ্রেডে প্রয়োগ করা হয়েছে। অন্যথায়, একটি স্যান্ডবক্স পালানোর ঝুঁকি রয়েছে: দূষিত কোড একটি স্যান্ডবক্সযুক্ত থ্রেড থেকে একটি আনস্যান্ডবক্সড থ্রেডে স্থানান্তরিত হতে পারে৷

দ্রষ্টব্য: Linux কার্নেল TSYNC পতাকাটি 3.17 সংস্করণে প্রবর্তন করেছে, যা সমস্ত থ্রেডে একটি নীতি প্রয়োগ করার অনুমতি দেয়। এই পতাকাটির আগে, শুধুমাত্র থ্রেড-বাই-থ্রেড ভিত্তিতে নীতি প্রয়োগ করা সম্ভব ছিল। যদি স্যান্ডবক্স2 সনাক্ত করে যে এটি TSYNC- সমর্থন ছাড়াই একটি কার্নেলে চলছে এবং আপনি একটি মাল্টি-থ্রেডেড প্রোগ্রাম থেকে SandboxMeHere() কল করেন, তাহলে স্যান্ডবক্স 2 বাতিল হয়ে যাবে, কারণ এটি স্যান্ডবক্সের নিরাপত্তার সাথে আপস করবে।

আমি কিভাবে আমার স্যান্ডবক্সী কম্পাইল করা উচিত?

আপনি যদি সতর্ক না হন, তাহলে অনেক নির্ভরতা এবং পার্শ্বপ্রতিক্রিয়া (অতিরিক্ত সিস্কাল, ফাইল অ্যাক্সেস, এমনকি নেটওয়ার্ক সংযোগ) উত্তরাধিকার সূত্রে পাওয়া সহজ যা স্যান্ডবক্সিংকে কঠিন করে তোলে (সকল পার্শ্ব প্রতিক্রিয়া ট্র্যাক করা) এবং কম নিরাপদ (কারণ সিস্কাল এবং ফাইল নীতিগুলি আরও বিস্তৃত)। কিছু কম্পাইল বিকল্প এই ধরনের সমস্যা কমাতে সাহায্য করতে পারে:

• গতিশীল লিঙ্কিং এড়াতে স্থিরভাবে স্যান্ডবক্সি বাইনারি কম্পাইল করুন যা প্রচুর syscalls ব্যবহার করে ( open / openat , mmap , ইত্যাদি)।

• যেহেতু Bazel ডিফল্টরূপে pie যোগ করে, কিন্তু স্ট্যাটিক এটির সাথে বেমানান, তাই cc_binary নিয়মে নিম্নলিখিত বিকল্পগুলির মাধ্যমে এটিকে জোর করে বন্ধ করতে বৈশিষ্ট্য পতাকা ব্যবহার করার কথা বিবেচনা করুন:

  linkstatic = 1,
  features = [
      "fully_static_link",  # link libc statically
      "-pie",
  ],
  

যাইহোক: স্ট্যাটিক ব্যবহার করলে ASLR হিপ এনট্রপি (30 বিট থেকে 8 বিট) হ্রাস করার নেতিবাচক দিক রয়েছে, শোষণকে সহজ করে তোলে। আপনার স্যান্ডবক্স বাস্তবায়ন এবং নীতির উপর নির্ভর করে কোনটি পছন্দনীয় তা সাবধানে সিদ্ধান্ত নিন:

• স্ট্যাটিক নয় : ভাল হিপ ASLR, প্রাথমিক কোড এক্সিকিউশন পেতে সম্ভাব্য কঠিন কিন্তু কম কার্যকর স্যান্ডবক্স নীতির খরচে, থেকে বের হওয়া সম্ভাব্য সহজ।
• স্ট্যাটিক : খারাপ হিপ ASLR, প্রাথমিক কোড এক্সিকিউশন পেতে সম্ভাব্য সহজ কিন্তু একটি আরও কার্যকর স্যান্ডবক্স নীতি, যা থেকে বের হওয়া সম্ভাব্য কঠিন।

এটি একটি দুর্ভাগ্যজনক পছন্দ কারণ কম্পাইলার স্ট্যাটিক PIE (পজিশন ইন্ডিপেন্ডেন্ট এক্সিকিউটেবল) সমর্থন করে না। বাইনারি একটি গতিশীল বস্তু হওয়ার মাধ্যমে PIE প্রয়োগ করা হয় এবং এটি কার্যকর করার আগে গতিশীল লোডার এটিকে একটি এলোমেলো অবস্থানে ম্যাপ করে। তারপর, যেহেতু হিপটি ঐতিহ্যগতভাবে বাইনারির বেস অ্যাড্রেসের পরে একটি এলোমেলো অফসেটে স্থাপন করা হয় (এবং brk syscall দিয়ে প্রসারিত), এর মানে স্ট্যাটিক বাইনারিগুলির জন্য হিপ ASLR এনট্রপি শুধুমাত্র এই অফসেট কারণ কোন PIE নেই।

এই কম্পাইলিং বিকল্পগুলির উদাহরণের জন্য, স্ট্যাটিক উদাহরণ দেখুন BUILD.bazel : static_bin.cc স্ট্যাটিকভাবে কম্পাইল করা হয়েছে, যা আমাদেরকে একটি খুব শক্ত syscall নীতি থাকতে দেয়। এটি স্যান্ডবক্সিং তৃতীয় পক্ষের বাইনারিগুলির জন্যও সুন্দরভাবে কাজ করে।

আমি কি 32-বিট x86 বাইনারি স্যান্ডবক্স করতে পারি?

স্যান্ডবক্স 2 শুধুমাত্র একই আর্কিটেকচার স্যান্ডবক্স করতে পারে যার সাথে এটি সংকলিত হয়েছিল।

উপরন্তু, Sandbox2 থেকে 32-বিট x86-এর সমর্থন মুছে ফেলা হয়েছে। আপনি যদি একটি 32-বিট x86 বাইনারি বা 64-বিট x86 বাইনারি 32-বিট সিস্ক্যাল তৈরি করে (int 0x80 এর মাধ্যমে) স্যান্ডবক্সে একটি 64-বিট x86 এক্সিকিউটর ব্যবহার করার চেষ্টা করেন, উভয়ই একটি স্যান্ডবক্স লঙ্ঘন তৈরি করবে যা দ্বারা চিহ্নিত করা যেতে পারে। আর্কিটেকচার লেবেল [X86-32]।

এই আচরণের পিছনে কারণ হল যে syscall সংখ্যাগুলি আর্কিটেকচারের মধ্যে আলাদা এবং যেহেতু syscall নীতি নির্বাহকের আর্কিটেকচারে লেখা আছে, তাই স্যান্ডবক্সীর জন্য একটি ভিন্ন আর্কিটেকচারের অনুমতি দেওয়া বিপজ্জনক হবে। প্রকৃতপক্ষে, এটি একটি আপাতদৃষ্টিতে ক্ষতিকারক সিস্ক্যালকে অনুমতি দিতে পারে যার প্রকৃত অর্থ হল আরেকটি আরও ক্ষতিকারক সিস্ক্যাল স্যান্ডবক্সকে পালানোর জন্য খুলতে পারে।

একটি নির্বাহক প্রক্রিয়া অনুরোধ করতে পারে এমন স্যান্ডবক্সের সংখ্যার কোন সীমা আছে কি?

প্রতিটি স্যান্ডবক্সী উদাহরণের জন্য (ফর্কসার্ভার থেকে নতুন প্রক্রিয়া তৈরি করা হয়েছে), একটি নতুন থ্রেড তৈরি করা হয়েছে - সেখানেই সীমাবদ্ধতা রয়েছে।

একজন নির্বাহক কি একাধিক স্যান্ডবক্স তৈরির অনুরোধ করতে পারেন?

না। একটি 1:1 সম্পর্ক রয়েছে – একটি এক্সিকিউটর ইনস্ট্যান্স স্যান্ডবক্সীর পিআইডি সঞ্চয় করে, স্যান্ডবক্স ইনস্ট্যান্সের সাথে Comms ইনস্ট্যান্স পরিচালনা করে ইত্যাদি।

আমি কেন forkserver.cc-এর ভিতরে "ফাংশন ইমপ্লিমেন্ট করা হয়নি" পাব?

Sandbox2 শুধুমাত্র যুক্তিসঙ্গতভাবে নতুন কার্নেল চালানো সমর্থন করে। আমাদের বর্তমান কাট-অফ হল 3.19 কার্নেল, যদিও এটি ভবিষ্যতে পরিবর্তিত হতে পারে। এর কারণ হ'ল আমরা অপেক্ষাকৃত নতুন কার্নেল বৈশিষ্ট্যগুলি ব্যবহার করছি যার মধ্যে ব্যবহারকারীর নামস্থান এবং TSYNC পতাকা সহ seccomp রয়েছে।

আপনি যদি প্রোড চালাচ্ছেন, তাহলে এটিকে সমস্যা করা উচিত নয়, যেহেতু প্রায় পুরো ফ্লিট একটি নতুন যথেষ্ট কার্নেল চালাচ্ছে। আপনি যদি এই সঙ্গে কোন সমস্যা আছে, আমাদের সাথে যোগাযোগ করুন.

আপনি যদি ডেবিয়ান বা উবুন্টুতে চালান, আপনার কার্নেল আপডেট করা চালানোর মতোই সহজ:

sudo apt-get install linux-image-<RECENT_VERSION>