Protection — domain, access matrix, ACL আর capability

১ · Protection বনাম security — ভেতরের নিয়ম আর বাইরের হুমকি

একটি কম্পিউটারে একসাথে বহু process চলে, বহু মানুষ লগইন করেন, আর সবাই একই ডিস্ক, একই মেমরি, একই নেটওয়ার্ক ভাগ করে নেন। আপনার browser যেন আপনার ব্যাংকিং অ্যাপের মেমরি পড়তে না পারে; একজন ছাত্রের প্রোগ্রাম যেন অন্য ছাত্রের ফাইল মুছতে না পারে; একটি বাগওয়ালা driver যেন পুরো সিস্টেম নষ্ট না করে। এই নিয়মগুলো যে ব্যবস্থা ঠিক করে আর প্রয়োগ করে, তার নাম protection.

সীমারেখাটি পরিষ্কার নয়, আর পাঠ্যবইভেদে আলাদা। তবে মনে রাখার সহজ উপায়: protection হলো mechanism — নিয়ম প্রয়োগের যন্ত্র; security হলো সেই যন্ত্র ব্যবহার করে বাস্তব হুমকির বিরুদ্ধে পুরো সিস্টেমকে টিকিয়ে রাখার নীতি ও চর্চা। পর্ব ৬-এ দেখেছিলেন policy আর mechanism আলাদা রাখার নীতি — protection-এ সেটিই কেন্দ্রীয়: OS দেয় নমনীয় mechanism, আর কোন ফাইল কে পড়বে সেই policy ঠিক করেন ব্যবহারকারী, admin বা প্রতিষ্ঠান।

Protection-এর লক্ষ্য

• ভুল থেকে বাঁচানো: বেশিরভাগ ক্ষতি আসে বাগ থেকে, ষড়যন্ত্র থেকে নয়। একটি ভুল pointer যেন শুধু নিজের process-কে নষ্ট করে — পর্ব ৩০-এ দেখা base/limit register বা পর্ব ৩২-এর page table-এর protection bit এই কাজই করে।
• নীতি প্রয়োগ: “হিসাব-শাখার ফাইল শুধু হিসাব-শাখা পড়বে” — এমন নিয়ম লেখা যায় আর OS প্রতিবার তা প্রয়োগ করে।
• ক্ষতি সীমিত রাখা: একটি অংশ ভাঙলে ক্ষতি যেন সেখানেই থামে — একটি আক্রান্ত web server যেন পুরো মেশিনের মালিক না হয়।

২ · নকশার নীতি — least privilege থেকে defense in depth

১৯৭৫ সালে MIT-র Jerome Saltzer আর Michael Schroeder Proceedings of the IEEE-এ প্রকাশ করেন “The Protection of Information in Computer Systems”. Multics প্রকল্পের অভিজ্ঞতা থেকে লেখা এই গবেষণাপত্রের আটটি নকশা-নীতি আজও OS, browser, cloud আর smartphone-এর নিরাপত্তা-নকশার ভাষা। নিচের টেবিলে সেই আটটি (প্রথম আট সারি), আর তার পরে আরও তিনটি প্রচলিত নীতি, যেগুলো অন্য উৎস থেকে এসেছে:

Least privilege — সবচেয়ে বেশি ব্যবহৃত নীতি

একটি ছোট উদাহরণে নীতিটির শক্তি দেখুন। একটি web server-কে port 80 বা 443-এ শুনতে হয়; Unix-এ ১০২৪-এর নিচের port খুলতে বিশেষ অধিকার লাগে। পুরোনো সহজ উপায়: পুরো server root হিসেবে চালানো। তখন server-এর একটি বাগ মানে আক্রমণকারীর হাতে পুরো মেশিন। Least privilege-এর উপায় তিনটি: (১) root হিসেবে শুরু করে port খুলেই সাধারণ user-এ নেমে যাওয়া — nginx আর Apache-এর মূল process এভাবেই worker-দের সাধারণ user-এ চালায়; (২) শুধু “নিচের port খোলার” অধিকারটি দেওয়া — Linux-এর CAP_NET_BIND_SERVICE (অংশ ৭); (৩) systemd-এর socket activation-এ port খোলে systemd, আর server হাতে পায় শুধু একটি খোলা socket — অর্থাৎ একটি capability.

৩ · Protection domain — কে, কী, কতটা

Protection-এর ভাষায় সিস্টেম দুই রকম জিনিস দিয়ে তৈরি। Object — যাকে রক্ষা করতে হবে: hardware object (CPU, মেমরির অংশ, প্রিন্টার, ডিস্ক) আর software object (ফাইল, প্রোগ্রাম, semaphore, socket). প্রতিটি object-এর একটি অনন্য নাম আর কিছু নির্দিষ্ট কাজ আছে — ফাইলে read, write, execute; প্রিন্টারে print; semaphore-এ wait আর signal. আর subject — যে কাজ করতে চায়: সাধারণত একটি process.

Domain হতে পারে একজন ব্যবহারকারী (Unix-এর user ID), একটি process (seL4-এ process-এর হাতের capability-গুলোই তার domain), বা একটি procedure (language-based protection, অংশ ৯)।

Need-to-know মানতে হলে — static বনাম dynamic association

• Static association: একটি process-এর domain তার পুরো জীবন ধরে একই। সমস্যা: একটি process-এর কাজের বিভিন্ন ধাপে বিভিন্ন অধিকার দরকার — শুরুতে একটি config ফাইল পড়া, পরে শুধু লগ লেখা। Domain স্থির হলে সব ধাপের অধিকার শুরু থেকেই দিতে হয়, যা need-to-know ভাঙে। তাই static ব্যবস্থায় domain-এর ভেতরের অধিকার বদলানোর একটি উপায় লাগে।
• Dynamic association: process চলার মাঝে এক domain থেকে আরেকটিতে যেতে পারে — domain switching. কোন domain থেকে কোনটিতে যাওয়া যাবে, সেটিও একটি নিয়ন্ত্রিত অধিকার (অংশ ৪-এর switch).

আগের পর্বগুলোর সাথে যোগ — ring আর dual mode

সবচেয়ে মৌলিক domain-ভাগ আপনি আগেই দেখেছেন: পর্ব ৪-এর protection ring আর পর্ব ৫-এর user mode/kernel mode. সেখানে domain মাত্র দুটি, আর domain switch-এর একমাত্র বৈধ দরজা system call (বা interrupt/exception) — process নিজের ইচ্ছামতো kernel-এর যেকোনো জায়গায় লাফ দিতে পারে না, শুধু নির্দিষ্ট প্রবেশপথে ঢোকে। এই পর্বের domain সেই ধারণারই সূক্ষ্ম রূপ: user mode-এর ভেতরেই হাজার রকম domain.

Unix-এ domain = user ID, আর setuid = domain switch

Unix-এ একটি process-এর domain মোটামুটি তার effective user ID (আর group ID-গুলো) দিয়ে ঠিক হয়। Domain বদলের চেনা পথ setuid: কোনো executable ফাইলের setuid bit চালু থাকলে, যে-ই সেটি exec করুক, নতুন প্রোগ্রাম চলে ফাইলের মালিকের effective UID নিয়ে। যেমন passwd প্রোগ্রাম সাধারণত root-এর মালিকানায় setuid — সাধারণ ব্যবহারকারী এটি চালালে process সাময়িকভাবে root-এর domain-এ যায়, যাতে শুধু পাসওয়ার্ড-ফাইলে নিজের লাইনটি বদলাতে পারে। এটি access matrix-এর ভাষায় একটি “switch” অধিকার — সব ব্যবহারকারীর domain থেকে একটি নির্দিষ্ট, সতর্কভাবে লেখা প্রোগ্রামের মাধ্যমে root-এর domain-এ ঢোকার দরজা। Setuid, sudo, real/effective/saved UID আর তার ঝুঁকিগুলো বিস্তারিত আছে পর্ব ৪৭-এ।

৪ · Access matrix — এক টেবিলে পুরো নিয়ম

১৯৭১ সালে Butler Lampson তাঁর “Protection” নামের গবেষণাপত্রে protection-এর একটি সাধারণ মডেল দেন, যা পরে access matrix নামে পরিচিত হয়; ১৯৭২ সালে G. Scott Graham আর Peter Denning মডেলটিকে আরও বিস্তারিত করেন — কোন অধিকার কে কীভাবে দিতে বা কেড়ে নিতে পারবে, তার নিয়মসহ। (মডেলের নামকরণ আর খুঁটিনাটির কৃতিত্ব বিভিন্ন বইয়ে একটু ভিন্নভাবে দেওয়া হয়; মূল ধারণা এই দুই কাজেরই।)

বিশেষ অধিকার — matrix নিজেকে কীভাবে বদলায়

কে matrix বদলাতে পারবে, তাও matrix-এর ভেতরেই লেখা থাকে চারটি বিশেষ অধিকারে:

• Copy (*): ঘরে r* থাকলে domain শুধু পড়তেই পারে না, “r” অধিকারটি একই কলামের অন্য কোনো সারিতে (অন্য domain-কে) দিতে পারে। প্রকারভেদ: transfer (দিলে নিজের থেকে মুছে যায়) আর limited copy (দেওয়া কপিতে * থাকে না, তাই সে আর এগিয়ে দিতে পারে না)।
• Owner: কোনো ঘরে “owner” থাকলে সেই domain ওই কলামের যেকোনো ঘরে অধিকার যোগ বা মুছতে পারে — ফাইলের মালিক যেমন chmod দিয়ে অন্যদের অধিকার বদলান।
• Control: শুধু domain-object-এ প্রযোজ্য। access(i, j)-তে “control” থাকলে D_i সারি D_j-এর যেকোনো অধিকার মুছতে পারে — একজন প্রধান যেমন নিজের অধীন বিভাগের অধিকার নিয়ন্ত্রণ করেন। Copy আর owner বদলায় কলাম, control বদলায় সারি.
• Switch: domain-কেও কলাম হিসেবে রাখা হয়; access(i, j)-তে “switch” থাকলে D_i-এর process D_j-তে চলে যেতে পারে। এভাবে dynamic association-ও একই টেবিলে।

Matrix-কে নিজেই নিজের অধিকারে রক্ষা করা — এটিই মডেলের সৌন্দর্য। তবে এর একটি গভীর সীমা আছে: অধিকারের নিয়ম যথেষ্ট সাধারণ হলে “এই অধিকার কি কখনো কোনো অবাঞ্ছিত domain-এ পৌঁছাতে পারে?” প্রশ্নটির সাধারণ কোনো algorithm নেই (ভাবনার প্রশ্ন ৪)।

একটি পূর্ণ উদাহরণ — চারটি domain, তিনটি ফাইল, একটি প্রিন্টার

এই পর্বের বাকি অংশে এই matrix-টিই ব্যবহার হবে। সংকেত: r = read, w = write, p = print, o = owner, s = switch, c = control, * = copy.

Switch-গুলো একটি দিকযুক্ত graph বানায়: D4 → D1 → D2 → D3, আর D3 থেকে কোথাও যাওয়া যায় না। “D_x কি (switch করে) O-তে op করতে পারে?” প্রশ্নের উত্তর তাই একটি graph-এর reachability প্রশ্ন: D_x থেকে switch-পথে পৌঁছানো যায় এমন কোনো domain-এর O-কলামে op আছে কি না। নিচের stepper চারটি প্রশ্ন ধাপে ধাপে মেলায়।

1 ask: D1 read F3 ?  check row D12      switch D1 → D2, check row D23      switch D2 → D3, check row D34 ask: D3 print P ?5 ask: D4 print P ?6 ask: D1 write F1 ?

নিচের simulator একই matrix-এ breadth-first search চালিয়ে প্রশ্নগুলোর উত্তর আর সবচেয়ে ছোট switch-পথ দেয়, তারপর copy অধিকারের একটি প্রয়োগ দেখায়:

// Access matrix, domains as objects. Rows = domains, columns = objects.
// r read, w write, p print, o owner, s switch (into that domain), c control, * copy flag
const M = {
  D1: { F1: "r",   F2: "r*", D2: "s" },
  D2: { F2: "r",   P: "p",   D3: "s" },
  D3: { F1: "r",   F3: "orw" },
  D4: { F1: "orw", F3: "r",  D1: "s", D3: "c" },
};
const cols = ["F1", "F2", "F3", "P", "D1", "D2", "D3", "D4"];
const has = (d, o, r) => (M[d][o] || "").includes(r);
const word = { r: "read", w: "write", p: "print" };
console.log("    " + cols.map(c => c.padEnd(5)).join(""));
for (const d in M) console.log(d.padEnd(4) + cols.map(c => (M[d][c] || "-").padEnd(5)).join(""));

function query(start, right, obj) {           // breadth-first search over switch rights
  const prev = { [start]: null }, queue = [start];
  while (queue.length) {
    const d = queue.shift();
    if (has(d, obj, right)) {
      const path = [];
      for (let x = d; x; x = prev[x]) path.unshift(x);
      return "GRANTED via " + path.join(" -> ");
    }
    for (const n in M) if (has(d, n, "s") && !(n in prev)) { prev[n] = d; queue.push(n); }
  }
  return "DENIED (no reachable domain has it)";
}
const asks = [["D1", "r", "F3"], ["D1", "w", "F1"], ["D2", "p", "P"],
              ["D3", "p", "P"], ["D4", "p", "P"], ["D3", "r", "F2"]];
console.log("\nquery          result");
for (const [d, r, o] of asks) console.log(`${d} ${word[r]} ${o}?`.padEnd(15) + query(d, r, o));
// copy right: D1 holds r* on F2, so it may put "r" for F2 into another row
if (has("D1", "F2", "r*")) M.D3.F2 = "r";
console.log("\nafter D1 copies r(F2) to D3:\n" + "D3 read F2?".padEnd(15) + query("D3", "r", "F2"));

    F1   F2   F3   P    D1   D2   D3   D4   
D1  r    r*   -    -    -    s    -    -    
D2  -    r    -    p    -    -    s    -    
D3  r    -    orw  -    -    -    -    -    
D4  orw  -    r    -    s    -    c    -    

query          result
D1 read F3?    GRANTED via D1 -> D2 -> D3
D1 write F1?   DENIED (no reachable domain has it)
D2 print P?    GRANTED via D2
D3 print P?    DENIED (no reachable domain has it)
D4 print P?    GRANTED via D4 -> D1 -> D2
D3 read F2?    DENIED (no reachable domain has it)

after D1 copies r(F2) to D3:
D3 read F2?    GRANTED via D3

৫ · Matrix বাস্তবে কীভাবে রাখা হয় — global table, ACL, capability আর lock–key

বাস্তব সিস্টেমে matrix বিশাল আর বেশিরভাগ ঘর খালি (sparse), তাই পুরো টেবিল রাখা অসম্ভব। চারটি প্রচলিত উপায়:

1. Global table: শুধু ভরা ঘরগুলোর <domain, object, rights-set> ত্রয়ীর তালিকা। সরল, কিন্তু বিশাল, আর “সবাই পড়বে” ধরনের নিয়মে প্রতিটি domain-এর আলাদা entry লাগে।
2. Access control list (ACL): matrix-কে কলাম ধরে কাটা। প্রতিটি object-এর সাথে একটি তালিকা: <domain, rights-set>, খালি ঘর বাদ। সাথে একটি ডিফল্ট সেট রাখা যায় (“বাকি সবার জন্য”)। ব্যবহারকারীর চিন্তার সাথে মেলে — “আমার এই ফাইল কে কে পড়বে?”
3. Capability list (C-list): matrix-কে সারি ধরে কাটা। প্রতিটি domain-এর হাতে একটি তালিকা: <object, rights-set>. তালিকার প্রতিটি উপাদান একটি capability — object-এর নাম আর অধিকার একসাথে বাঁধা একটি টোকেন। Process শুধু টোকেন দেখিয়ে কাজ চায়; টোকেন থাকা মানেই অনুমতি।
4. Lock–key: মাঝামাঝি পথ। প্রতিটি object-এর একটি lock-এর তালিকা (অনন্য বিট-প্যাটার্ন), প্রতিটি domain-এর একটি key-এর তালিকা। Domain-এর কোনো key object-এর কোনো lock-এর সাথে মিললে access. Key-গুলো OS-এর হাতে থাকে, process নিজে বদলাতে পারে না; আর একটি lock মুছে দিলে সেই key-ধারী সবার অধিকার একসাথে বাতিল।

নিচের stepper একই matrix থেকে দুই দৃশ্য বের করে, আর দেখায় কোন প্রশ্নের উত্তর কোন দৃশ্যে সহজ।

1 full access matrix2 cut column F1 → ACL(F1)3 cut column F3 → ACL(F3)4 cut row D1 → C-list(D1)5 cut row D4 → C-list(D4)6 revoke D1's read on F1

বেশিরভাগ বাস্তব OS দুটিকে মেলায়: প্রথমবার access-এর সময় ACL যাচাই হয়, আর সফল হলে process একটি capability হাতে পায়, যা দিয়ে পরের সব কাজ চলে। Unix-এর open() ঠিক তাই — ACL (permission bit) যাচাই করে একটি file descriptor দেয়; Windows-এর CreateFile() DACL যাচাই করে একটি handle দেয়। পরের দুই অংশে দুটি দিক আলাদা করে দেখা যাক।

৬ · ACL বাস্তবে — Unix-এর ৯টি বিট, POSIX ACL আর Windows DACL

Unix-এর owner/group/other — সংকুচিত ACL

পর্ব ৩ আর ৪১-এ দেখা rwx permission আসলে একটি খুব ছোট, নির্দিষ্ট মাপের ACL: ঠিক তিনটি entry — মালিক, ফাইলের group, আর বাকি সবাই — প্রতিটিতে r, w, x. পুরো ACL-এর বদলে ৯টি বিট (আর setuid, setgid, sticky মিলিয়ে ১২টি) inode-এ ধরে যায়, যাচাইও দ্রুত। দাম: “শুধু রহিম আর করিম পড়বে, বাকি group নয়” — এমন নিয়ম তিন entry-তে লেখা যায় না, admin-কে নতুন group বানাতে হয়।

Kernel-এর নিয়মও ACL-এর মতো ক্রমানুসারী: process-এর effective UID ফাইলের মালিক হলে শুধু owner-বিট দেখা হয়; না হলে process-এর কোনো group ফাইলের group হলে শুধু group-বিট; না হলে other-বিট। তাই ----rw-rw- ফাইলের মালিক নিজে পড়তে পারেন না, যদিও “অন্যরা” পারে — owner entry মিলে গেছে, সেখানে অধিকার নেই, তাই উত্তর “না” (ব্যতিক্রম: root, যার জন্য Linux-এ CAP_DAC_OVERRIDE এই যাচাই এড়িয়ে যায়)। নিচের bash block এই ৯টি বিটকে একটি তিন-entry-র তালিকা হিসেবে পড়ে, আর getfacl/setfacl থাকলে বাড়তি ACL-ও দেখায়:

# Unix permission bits = a tiny, fixed-size ACL: owner, group, other
umask 022
echo "salary sheet" > report.txt
chmod 640 report.txt                       # owner rw-, group r--, other ---
ls -l report.txt
stat -c 'mode=%A octal=%a owner=%U group=%G' report.txt

p=$(stat -c %A report.txt)                 # e.g. -rw-r-----
echo "--- the same 9 bits read as an access list ---"
u=$(stat -c %U report.txt); g=$(stat -c %G report.txt)
printf 'ACE 1  %-22s : %s\n' "user $u (owner)" "${p:1:3}"
printf 'ACE 2  %-22s : %s\n' "group $g" "${p:4:3}"
printf 'ACE 3  %-22s : %s\n' "other (everyone else)" "${p:7:3}"

chmod o+r report.txt                       # edit one entry of the list
echo "after chmod o+r -> $(stat -c %A report.txt)"

if command -v getfacl >/dev/null && command -v setfacl >/dev/null; then
  if setfacl -m u:nobody:r report.txt 2>/dev/null; then
    getfacl -p report.txt
    ls -l report.txt                       # a '+' after the mode = extended ACL
  else
    echo "setfacl exists, but this file system does not accept ACLs"
  fi
else
  echo "getfacl/setfacl are not installed here (package 'acl' on Linux)"
fi
rm -f report.txt

-rw-r----- 1 wandbox wandbox 13 Oct 25 20:11 report.txt
mode=-rw-r----- octal=640 owner=wandbox group=wandbox
--- the same 9 bits read as an access list ---
ACE 1  user wandbox (owner)   : rw-
ACE 2  group wandbox          : r--
ACE 3  other (everyone else)  : ---
after chmod o+r -> -rw-r--r--
getfacl/setfacl are not installed here (package 'acl' on Linux)

POSIX ACL — নাম ধরে বাড়তি entry

তিন entry-র সীমা পেরোতে বহু Unix-ধরনের সিস্টেম POSIX 1003.1e-এর খসড়া থেকে আসা ACL সমর্থন করে (মানটি ১৯৯০-এর দশকের শেষে প্রত্যাহার হলেও খসড়ার নকশাই বাস্তবে চলছে)। Linux-এ ext4, XFS, Btrfs-এর মতো file system-এ এটি পাওয়া যায়। নমুনা (পূর্ণ Linux-এ, ব্যবহারকারী rahim আর group accounts আছে ধরে নিয়ে; এখানে চালানো যায় না):

$ setfacl -m u:rahim:r report.txt        # রহিমকে শুধু পড়ার entry
$ setfacl -m g:accounts:rw report.txt    # accounts group-কে পড়া-লেখা
$ getfacl report.txt
# file: report.txt
# owner: karim
# group: staff
user::rw-
user:rahim:r--
group::r--
group:accounts:rw-
mask::rw-
other::---

$ ls -l report.txt
-rw-rw----+ 1 karim staff 13 Oct 26 10:00 report.txt
$ setfacl -x u:rahim report.txt          # রহিমের entry মুছে ফেলা (revoke)
$ setfacl -b report.txt                  # সব বাড়তি entry মুছে আবার ৯টি বিট

দুটি জিনিস লক্ষ করুন। ls -l-এ মোডের পরে + মানে “এর বাইরেও ACL আছে” — শুধু ৯টি বিট দেখে সিদ্ধান্ত নেবেন না। আর mask: নামযুক্ত entry আর group entry-র সর্বোচ্চ সীমা; তখন ls -l-এর মাঝের তিনটি বিট আসলে mask দেখায়। ডিরেক্টরিতে “default” ACL রাখলে ভেতরের নতুন ফাইল তা উত্তরাধিকার পায়। macOS আর NFSv4-ধরনের ACL Windows-এর মডেলের কাছাকাছি, কমান্ডও আলাদা (macOS-এ chmod +a, ls -le).

Windows — security descriptor, DACL আর ACE

Windows NT শুরু থেকেই (১৯৯৩) পূর্ণ ACL-এর ওপর দাঁড়িয়ে। প্রতিটি securable object — ফাইল, registry key, process, thread, named pipe — একটি security descriptor রাখে, যাতে থাকে মালিকের SID (security identifier — ব্যবহারকারী বা group-এর অনন্য পরিচয়), একটি DACL (discretionary ACL — কে কী পারবে) আর একটি SACL (কোন access-এর audit log লেখা হবে)। DACL হলো ACE-এর ক্রমিক তালিকা; প্রতিটি ACE “allow” বা “deny”, একটি SID আর একটি access mask (read, write, delete, change permissions…)।

• যাচাইয়ের ক্রম: ACE-গুলো পর্যায়ক্রমে দেখা হয়, যতক্ষণ না চাওয়া সব অধিকার মঞ্জুর হয় বা কোনো deny মেলে; স্বাভাবিক (canonical) ক্রমে স্পষ্ট deny আগে বসে।
• Fail-safe default: কোনো ACE না মিললে access বাতিল; খালি DACL মানে কেউ কিছু পারে না। কিন্তু DACL একদম না থাকলে (NULL DACL) সবাই সব পারে — একটি পুরোনো বিপজ্জনক ফাঁদ।
• Inheritance আর handle: ফোল্ডারের ACE সন্তান-ফাইলে যায়; আর যাচাই হয় খোলার সময়ে, মঞ্জুর হওয়া অধিকার handle-এ জমা থাকে — Unix-এর fd-এর মতো।

PS> icacls C:\Data\report.txt
C:\Data\report.txt OFFICE\karim:(F)
                   OFFICE\accounts:(R,W)
                   BUILTIN\Administrators:(I)(F)
                   NT AUTHORITY\SYSTEM:(I)(F)

PS> icacls C:\Data\report.txt /grant "OFFICE\rahim:(R)"    # একটি allow ACE যোগ
PS> icacls C:\Data\report.txt /remove "OFFICE\rahim"        # সেই entry মুছে ফেলা
PS> (Get-Acl C:\Data\report.txt).Access | Format-Table IdentityReference, AccessControlType, FileSystemRights

(F) = full control, (R,W) = পড়া ও লেখা, (I) = ফোল্ডার থেকে উত্তরাধিকারসূত্রে পাওয়া ACE. Unix-এর তুলনায় Windows-এর ACL অনেক বেশি সূক্ষ্ম, কিন্তু সেই কারণেই ভুল কনফিগারেশনও সহজ — ভাবনার প্রশ্ন ২ দেখুন।

৭ · Capability বাস্তবে — জাল করা যায় না এমন টোকেন

Capability-র ধারণাটি স্পষ্ট করে প্রথম লেখেন Jack Dennis আর Earl Van Horn, ১৯৬৬ সালে (“Programming Semantics for Multiprogrammed Computations”). মূল শর্ত একটিই: capability জাল করা যাবে না। Process যদি নিজে একটি টোকেন বানিয়ে “আমার কাছে F3-এ লেখার অধিকার আছে” বলতে পারে, পুরো ব্যবস্থা অর্থহীন। এটি নিশ্চিত করার তিন পথ:

• Tagged hardware: মেমরির প্রতিটি word-এর সাথে একটি বাড়তি tag বিট — “এটি capability”. সাধারণ instruction tag-যুক্ত word বদলাতে পারে না, শুধু বিশেষ instruction পারে। ইতিহাসে Burroughs-এর B5000 পরিবারের মতো tagged মেশিন, Cambridge-এর CAP কম্পিউটার, IBM System/38 আর Intel iAPX 432 এ ধরনের নকশার উদাহরণ; আধুনিক গবেষণায় CHERI (আরও গভীরে দেখুন)।
• Kernel-এর ভেতরে রাখা: capability-র আসল তালিকা থাকে kernel-এর মেমরিতে; process-এর হাতে থাকে শুধু সেই তালিকার একটি সূচক (index). Process সূচক বানাতে পারে, কিন্তু kernel-এর টেবিলে না থাকা অধিকার বানাতে পারে না। CMU-র Hydra থেকে seL4 পর্যন্ত এবং — চেনা উদাহরণ — Unix-এর file descriptor এই পথে চলে।
• Cryptographic টোকেন: capability-তে একটি গোপন key দিয়ে বানানো চিহ্ন থাকে, বদলালে ধরা পড়ে — যেমন Amoeba OS, বা ক্লাউডের pre-signed URL.

File descriptor — আপনার প্রতিদিনের capability

পর্ব ৪১-এ দেখেছেন, open() একটি ছোট পূর্ণসংখ্যা — file descriptor — ফেরত দেয়, যা process-এর fd টেবিলের একটি সূচক; টেবিলের entry kernel-এর open-file table-এর একটি রেকর্ডকে নির্দেশ করে, যাতে খোলার মোড (read-only, write-only, read-write) লেখা থাকে। অর্থাৎ fd = object (কোন ফাইল) + অধিকার (কোন মোড), kernel-রক্ষিত — capability-র সংজ্ঞাই। আর permission যাচাই হয় শুধু open()-এর সময়ে; পরে read()/write() শুধু fd-এর মোড দেখে। নিচের প্রোগ্রাম এটি সরাসরি দেখায়:

#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>
#include <unistd.h>

int main(void) {
    const char *path = "budget.txt";
    FILE *f = fopen(path, "w");
    if (!f) { perror("fopen"); return 1; }
    fputs("budget 2026: 42 crore\n", f);
    fclose(f);
    int fd = open(path, O_RDONLY);             /* the permission check happens HERE */
    if (fd < 0) { perror("open"); return 1; }
    printf("1. open(O_RDONLY) granted, fd is %s\n", fd > 2 ? "a small int > 2" : "?");
    chmod(path, 0);                            /* owner now removes ALL permissions */
    struct stat st;
    stat(path, &st);
    printf("2. chmod done, mode is now %03o\n", (unsigned)(st.st_mode & 0777));

    int fd2 = open(path, O_RDONLY);            /* a NEW open is checked again */
    printf("3. new open(): %s\n", fd2 < 0 ? strerror(errno) : "granted");
    char buf[64];
    ssize_t n = read(fd, buf, sizeof buf - 1); /* the OLD fd still works */
    buf[n > 0 ? n : 0] = '\0';
    printf("4. read() on the old fd: %zd bytes: %s", n, buf);

    ssize_t w = write(fd, "x", 1);             /* the fd carries only the read right */
    printf("5. write() on the old fd: %s\n", w < 0 ? strerror(errno) : "ok");
    close(fd);
    unlink(path);
    return 0;
}

1. open(O_RDONLY) granted, fd is a small int > 2
2. chmod done, mode is now 000
3. new open(): Permission denied
4. read() on the old fd: 22 bytes: budget 2026: 42 crore
5. write() on the old fd: Bad file descriptor

Capability-র delegation-ও fd-তে আছে: fork()-এ সন্তান fd পায়, আর Unix domain socket-এর SCM_RIGHTS বার্তায় একটি খোলা fd অন্য process-কে পাঠানো যায় — গ্রহীতা ফাইলটি নিজে খুলতে না পারলেও। Windows-এ DuplicateHandle() একই কাজ করে। উল্টো সতর্কতা: exec বা domain switch-এর আগে দরকারহীন fd বন্ধ না করলে তা নতুন প্রোগ্রামে চলে যায় — তাই O_CLOEXEC (পর্ব ১০)।

Capsicum, seL4 আর Fuchsia — capability-কেন্দ্রিক সিস্টেম

• Capsicum: Robert Watson ও সহকর্মীদের নকশা (USENIX Security, ২০১০), FreeBSD-তে যুক্ত। cap_enter() ডাকার পর process আর global নাম (যেমন /etc/passwd) দিয়ে নতুন কিছু খুলতে পারে না, শুধু হাতে থাকা fd দিয়ে কাজ করে; cap_rights_limit() দিয়ে প্রতিটি fd-এর অধিকার আরও ছোট করা যায়।
• seL4: একটি microkernel, যার সঠিকতা গাণিতিকভাবে প্রমাণিত (formal verification, ২০০৯)। Thread, address space, IPC endpoint, মেমরি — সব kernel object শুধু capability দিয়ে ছোঁয়া যায়।
• Fuchsia (Zircon kernel): Google-এর এই OS-এ process সব kernel object-কে অধিকারের বিটসহ handle দিয়ে ছোঁয়; কপি করার সময় অধিকার কমানো যায়, বাড়ানো নয়, আর প্রতিটি process শুধু তাকে দেওয়া namespace দেখে।

সতর্কতা — Linux-এর “capabilities” আলাদা জিনিস

Linux-এ (kernel ২.২ থেকে, ১৯৯৯) “capabilities” নামে একটি ব্যবস্থা আছে, কিন্তু তা Dennis–Van Horn-এর অর্থের capability নয়। পুরোনো Unix-এ ক্ষমতা ছিল দুই ভাগে — root (UID 0) সব পারে, বাকিরা কিছুই না। Linux root-এর ক্ষমতাকে প্রায় ৪০টি আলাদা অধিকারে ভেঙেছে: CAP_NET_BIND_SERVICE (১০২৪-এর নিচের port খোলা), CAP_CHOWN, CAP_DAC_OVERRIDE (ফাইল-permission এড়ানো), CAP_SYS_ADMIN (বহু admin কাজের বিশাল গুচ্ছ) ইত্যাদি। এগুলো process-এর বৈশিষ্ট্য — কোনো নির্দিষ্ট object-এর নাম বহন করে না, হস্তান্তরযোগ্য টোকেনও নয়; আসলে privilege. Least privilege-এর চমৎকার উপায়, কিন্তু capability-ভিত্তিক মডেল নয়।

প্রতিটি process-এর কয়েকটি capability-সেট থাকে: Permitted (যা সর্বোচ্চ চালু করতে পারে), Effective (এখন যা kernel সত্যিই যাচাইয়ে গোনে), Inheritable আর Ambient (exec-এর পরে কী থাকবে), আর Bounding (এই process আর তার বংশধর কখনো যা পেতে পারবে তার ঊর্ধ্বসীমা)। এগুলো /proc/self/status-এ ৬৪-বিট hex mask হিসেবে দেখা যায় — বিট n = capability নম্বর n. নিচের block সেগুলো পড়ে নিজেই decode করে, আর capsh থাকলে তার সাথে মিলিয়ে দেখে:

# Linux capabilities: root's power split into separate bits (bit n = one capability)
grep '^Cap' /proc/self/status
names=(chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
  linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
  sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot sys_nice
  sys_resource sys_time sys_tty_config mknod lease audit_write audit_control setfcap
  mac_override mac_admin syslog wake_alarm block_suspend audit_read perfmon bpf
  checkpoint_restore)                      # bit numbers 0..40, from linux/capability.h

decode() {                                 # hex mask -> list of names
  local v=$((16#$1)) out="" i
  for ((i = 0; i < ${#names[@]}; i++)); do
    if (( (v >> i) & 1 )); then out+="cap_${names[i]} "; fi
  done
  out=${out% }; echo "${out:-(none)}"
}
echo "--- decoded ---"
for f in CapEff CapPrm CapBnd; do
  hex=$(awk -v k="$f:" '$1 == k {print $2}' /proc/self/status)
  echo "$f = 0x$hex -> $(decode "$hex")"
done

if command -v capsh >/dev/null; then       # cross-check with the libcap tool
  echo "--- capsh --decode of CapBnd ---"
  capsh --decode="$(awk '$1 == "CapBnd:" {print $2}' /proc/self/status)"
fi

CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	00000000800405fb
CapAmb:	0000000000000000
--- decoded ---
CapEff = 0x0000000000000000 -> (none)
CapPrm = 0x0000000000000000 -> (none)
CapBnd = 0x00000000800405fb -> cap_chown cap_dac_override cap_fowner cap_fsetid cap_kill cap_setgid cap_setuid cap_setpcap cap_net_bind_service cap_sys_chroot cap_setfcap
--- capsh --decode of CapBnd ---
0x00000000800405fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap

৮ · ACL বনাম capability — delegation, confused deputy আর revocation

Confused deputy — কার অধিকারে কাজটি হলো?

১৯৮৮ সালে Norm Hardy ACM Operating Systems Review-এ একটি ছোট কিন্তু প্রভাবশালী লেখা প্রকাশ করেন: “The Confused Deputy (or why capabilities might have been invented)”. ঘটনাটি Tymshare নামের একটি time-sharing কোম্পানির সিস্টেমে। একটি compiler-এর নিজস্ব ডিরেক্টরিতে লেখার অধিকার ছিল, কারণ সেখানে সে প্রতিটি ব্যবহারের বিল একটি ফাইলে ((SYSX)BILL) লিখত। ব্যবহারকারী compiler চালানোর সময় debug-আউটপুটের জন্য একটি ফাইলের নাম দিতে পারতেন। একজন ব্যবহারকারী আউটপুট-ফাইলের নাম দিলেন (SYSX)BILL — compiler নিজের অধিকারে ফাইলটি খুলে তাতে debug-আউটপুট লিখে বিলের তথ্য নষ্ট করে দিল। ব্যবহারকারীর নিজের সেই ফাইলে লেখার অধিকার ছিল না; compiler-এর ছিল — কিন্তু অন্য কাজের জন্য। Compiler “বিভ্রান্ত প্রতিনিধি”: সে দুই প্রভুর (নিজের আর ব্যবহারকারীর) কাজ করছিল, আর কোন কাজটি কার অধিকারে, তা আলাদা করতে পারেনি।

U        : write own files ............ yes
U        : write (SYSX)BILL ........... NO
compiler : write (SYSX)BILL ........... yes  (to record billing)
compiler : write any file U names ..... ?    (it runs with ITS rights)

U        → compile("prog.f", out = "mydebug.txt")
compiler → open("mydebug.txt", write)   kernel checks COMPILER's rights
kernel   → granted
result   : output lands in U's file — looks fine

U        → compile("prog.f", out = "(SYSX)BILL")
compiler → open("(SYSX)BILL", write)    kernel checks COMPILER's rights
kernel   → granted   (the compiler may write there!)
result   : billing records overwritten by debug text

U        → fd = open("mydebug.txt", write)  checked with U's OWN rights
U        → compile("prog.f", out = fd)      passes the capability
compiler → write(fd, ...)                   no name lookup, no own rights used
U tries  → open("(SYSX)BILL", write) → DENIED, so U has no fd to pass

compiler holds: fd_bill  (its own capability, used ONLY for billing)
compiler holds: fd_out   (received from U, used ONLY for output)
designation (which file) and authority (may I?) travel together
→ the deputy can no longer be confused about whose right it uses

একই সমস্যা আজ setuid প্রোগ্রাম, web-এর CSRF আর ক্লাউড-সেবায় দেখা যায় (ভাবনার প্রশ্ন ৩)। প্রতিরক্ষার সাধারণ নিয়ম: অনুরোধকারীর অধিকারে কাজ করুন (যেমন setuid প্রোগ্রাম ব্যবহারকারীর দেওয়া ফাইল খোলার আগে সাময়িকভাবে real UID-এ নেমে আসে), আর নামের বদলে খোলা handle নিন।

Revocation — দেওয়া অধিকার ফিরিয়ে নেওয়া

অধিকার কেড়ে নেওয়ার নকশা চারটি প্রশ্নে ভাগ হয়:

ACL-এ চারটিই সহজ: object-এর তালিকায় গিয়ে entry মুছুন বা বদলান — পরের যাচাই থেকে কার্যকর। Capability-তে কঠিন, কারণ টোকেন domain-গুলোর হাতে ছড়িয়ে আছে। প্রচলিত কৌশল:

• Reacquisition: capability-গুলো সময়ে সময়ে মুছে ফেলা হয়; process আবার চায়, অধিকার বাতিল হলে পায় না — ক্লাউডের স্বল্পমেয়াদি access token-এর ধারণা।
• Back-pointer: object তার সব capability-র দিকে pointer রাখে, যাতে সবগুলো খুঁজে বাতিল করা যায়; সাধারণ, কিন্তু খরচ বেশি (বইগুলো MULTICS-এর উদাহরণ দেয়)।
• Indirection: capability নির্দেশ করে একটি global টেবিলের entry-কে, আর entry object-কে; entry মুছলে সব capability একসাথে অকেজো, তবে selective revocation হয় না।
• Key: object-এর একটি master key, capability তৈরির সময় তার কপি বসে; master key বদলালে পুরোনো সব capability অচল। কয়েকটি key রাখলে selective revocation-ও সম্ভব।

Unix-এর fd এর কোনোটিই পুরোপুরি দেয় না — chmod-এর পরেও খোলা fd চলে। ব্যবহারিক উপায়: process-টি পুনরায় চালু করা। BSD-র revoke() system call একটি device-এর সব খোলা fd অকেজো করে — বিরল একটি তাৎক্ষণিক revocation.

৯ · RBAC, DAC বনাম MAC, আর language-based protection

Role-based access control (RBAC)

বড় প্রতিষ্ঠানে প্রতিটি মানুষকে আলাদা আলাদা ফাইলে অধিকার দেওয়া অসম্ভব হয়ে ওঠে — কেউ বদলি হলে শত শত entry বদলাতে হয়। RBAC-এ অধিকার দেওয়া হয় role-কে (যেমন “হিসাবরক্ষক”, “শাখা-ব্যবস্থাপক”, “নিরীক্ষক”), আর মানুষকে দেওয়া হয় role. বদলি মানে শুধু role বদল। Access matrix-এর ভাষায় role হলো একটি domain, আর মানুষ সেই domain-এ ঢোকার অধিকার পান। ধারণাটিকে ১৯৯০-এর দশকে NIST-এর গবেষকেরা (David Ferraiolo, Richard Kuhn প্রমুখ) একটি মানসম্মত মডেলে রূপ দেন। Separation of duty সহজে লেখা যায় — “যে বিল তৈরি করে, সে একই বিল অনুমোদন করতে পারবে না।” উদাহরণ: Solaris-এর RBAC, Windows-এর group ও Active Directory-র role-ধরনের ব্যবহার, Kubernetes-এর RBAC, আর database-এর role (DBMS কোর্সের নিরাপত্তা পর্বে GRANT/REVOKE — ঠিক এই পর্বের access matrix-এর SQL রূপ)।

Discretionary বনাম mandatory

• DAC (discretionary access control): object-এর মালিক নিজের ইচ্ছায় (discretion) অধিকার দেন — Unix permission, POSIX ACL, Windows DACL. Matrix-এর owner আর copy অধিকার এই মডেলের মূল। দুর্বলতা: মালিকের নামে চলা যেকোনো প্রোগ্রাম — একটি ক্ষতিকর অ্যাপও — মালিকের মতোই অধিকার দিয়ে দিতে পারে।
• MAC (mandatory access control): একটি কেন্দ্রীয় নীতি, যা মালিকও বদলাতে পারেন না — যেমন “গোপন”-লেবেলের তথ্য “সাধারণ”-লেবেলের ফাইলে লেখা যাবে না (Bell–LaPadula মডেল, ১৯৭০-এর দশক)। আধুনিক রূপ SELinux, AppArmor, macOS ও iOS-এর sandbox প্রোফাইল, Windows-এর integrity level. DAC আর MAC সাধারণত একসাথে চলে: দুটিই “হ্যাঁ” বললে তবেই access — defense in depth. বিস্তারিত পর্ব ৪৯-এ।

Language-based protection — কম্পাইলার আর runtime-ও পাহারাদার

Kernel-এর protection-এর একক সাধারণত একটি process বা ফাইল। কিন্তু একই process-এর ভেতরে অনেক অংশ — একটি browser-এর ভেতরের বিভিন্ন সাইটের script, একটি অ্যাপের ভেতরের তৃতীয়-পক্ষের plugin. এখানে protection দিতে পারে programming language আর তার runtime: type safety (একটি পূর্ণসংখ্যাকে pointer বানানো যায় না), array-র সীমা যাচাই, আর মডিউলের দৃশ্যমানতা। একটি memory-safe ভাষায় object reference নিজেই এক ধরনের capability — যার হাতে reference নেই, সে object ছুঁতে পারে না।

Java-র উদাহরণ (সংক্ষেপে): JVM লোড করা bytecode আগে verifier দিয়ে যাচাই করে, যাতে জাল pointer বা ভুল type-এর কাজ না থাকে; class loader ঠিক করে কোড কোথা থেকে এসেছে। পুরোনো Java-তে SecurityManager প্রতিটি সংবেদনশীল কাজে কল-stack-এর প্রতিটি frame-এর অধিকার দেখত (stack inspection) — confused deputy ঠেকানোর একটি ভাষা-স্তরের চেষ্টা। মডেলটি জটিল আর কম-ব্যবহৃত প্রমাণিত হয়: Java 17-এ deprecated (JEP 411), JDK 24-এ স্থায়ীভাবে নিষ্ক্রিয় (JEP 486). আজ অবিশ্বস্ত কোড চলে আলাদা process বা container-এ, OS-এর sandbox দিয়ে — language-এর সুরক্ষা তার পরিপূরক, বিকল্প নয়।

১০ · AI-এর যুগে protection আর permission

“Permission denied” দেখে AI-কে জিজ্ঞেস করলে প্রায়ই সবচেয়ে দ্রুত — আর সবচেয়ে বিপজ্জনক — সমাধান আসে। বারবার দেখা ভুলগুলো:

AI-এর উত্তর মানার আগে — চেকলিস্ট

• প্রস্তাবিত অধিকার ঠিক কোন user/group-কে আর কোন ফাইলে — নিজে লিখে নিয়েছি, “সবাই” বা 777 নেই
• কমান্ড আমার OS আর distro-র জন্য কি না — man setfacl, man 7 capabilities বা Microsoft-এর icacls ডকুমেন্টেশনে মিলিয়েছি
• বদলের আগে আর পরে ls -l/getfacl/icacls-এর আউটপুট রেখেছি, যাতে ফিরিয়ে নিতে পারি
• অধিকার দেওয়ার পর একটি অননুমোদিত user দিয়ে পরীক্ষা করে দেখেছি যে সে এখনো আটকায় (শুধু “এখন কাজ করছে” যথেষ্ট নয়)
• চলমান process-এর খোলা fd-এর কথা মাথায় রেখেছি — revoke করার পর দরকার হলে সেবাটি পুনরায় চালু করেছি
• Access matrix-এর প্রশ্নে AI-এর উত্তর হাতে switch-পথ এঁকে (বা simulator-এ) যাচাই করেছি