Sandbox আর mandatory access control — seccomp, SELinux আর secure boot

১ · Sandbox কী — আক্রান্ত প্রোগ্রামকেও ঘেরাটোপে রাখা

পর্ব ৪৬ থেকে ৪৮-এ দেখেছেন OS কীভাবে প্রশ্ন করে “এই ব্যবহারকারী কি এই ফাইল পড়তে পারবেন?” — access matrix, Linux-এর rwx অনুমতি, authentication আর memory-সুরক্ষা। কিন্তু একটি কঠিন বাস্তবতা আছে। আপনার PDF reader আপনারই নামে চলে। আপনার যে সব ফাইল পড়ার অনুমতি আছে, PDF reader-এরও আছে। এখন ধরুন, ইমেইলে আসা একটি বিশেষভাবে বানানো PDF ফাইল reader-এর কোনো বাগ কাজে লাগিয়ে তার ভেতরে নিজের কোড চালিয়ে দিল। তখন সেই কোড আপনার সব ফাইল, ব্রাউজারের পাসওয়ার্ড আর SSH key পর্যন্ত পৌঁছাতে পারে — কারণ OS-এর চোখে এটি “আপনি”।

Sandbox-এর চিন্তা এখান থেকেই। প্রশ্নটি বদলে যায়: “এই প্রোগ্রামের কাজ করতে আসলে কী কী লাগে?” PDF দেখাতে লাগে একটি ফাইল পড়া আর স্ক্রিনে আঁকা। নেটওয়ার্ক, আপনার home ফোল্ডারের বাকি ফাইল, নতুন প্রোগ্রাম চালানো — কোনোটাই লাগে না। তাহলে আগেভাগেই সেগুলো কেড়ে নেওয়া হোক। পরে বাগ কাজে লাগিয়ে কেউ ঢুকলেও সে একটি ছোট ঘরে আটকে থাকবে। ১৯৭৫ সালে Jerome Saltzer আর Michael Schroeder তাঁদের বিখ্যাত গবেষণাপত্রে এই নীতির নাম দেন principle of least privilege: প্রতিটি প্রোগ্রাম আর ব্যবহারকারী কাজের জন্য ন্যূনতম যতটুকু ক্ষমতা দরকার, ঠিক ততটুকু পাবে। Sandbox হলো সেই নীতির হাতে-কলমে প্রয়োগ।

যেকোনো sandbox তিনটি প্রশ্নের উত্তর দেয়: (১) প্রোগ্রাম kernel-কে কী কী অনুরোধ করতে পারবে (কোন system call), (২) কোন রিসোর্সে হাত দিতে পারবে (কোন ফাইল, port, ডিভাইস), আর (৩) কী দেখতে পাবে (অন্য প্রসেস, নেটওয়ার্ক, পুরো file system — নাকি শুধু নিজের অংশ)। প্রোগ্রামের kernel-এর কাছে যাওয়ার যত পথ খোলা, তার সমষ্টিকে বলে attack surface. Sandbox এই পৃষ্ঠ ছোট করে।

বড় প্রোগ্রাম প্রায়ই নিজেকে দুই ভাগে ভাগ করে — একে বলে privilege separation. একটি ছোট, বিশ্বস্ত “broker” প্রসেস বেশি ক্ষমতা রাখে আর সাবধানে যাচাই করে কাজ করে; ঝুঁকিপূর্ণ কাজ (অচেনা ডেটা parse করা, ওয়েবপেজ আঁকা) করে প্রায় ক্ষমতাহীন একটি sandboxed প্রসেস, যে দরকারে IPC-তে (পর্ব ১২) broker-এর কাছে অনুরোধ পাঠায়। আধুনিক ব্রাউজার এই নকশার সবচেয়ে বড় উদাহরণ। এটি পর্ব ৬-এর policy আর mechanism আলাদা রাখার নীতিরই প্রয়োগ: kernel যন্ত্র দেয় (seccomp, LSM), আর প্রতিটি প্রোগ্রাম বা distro নিজের নীতি লেখে।

২ · বাস্তবের sandbox — ব্রাউজার, মোবাইল, ডেস্কটপ আর WebAssembly

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

৩ · seccomp — system call-এর দরজায় ছাঁকনি

পর্ব ৫-এ দেখেছেন, user-space প্রোগ্রাম kernel-এর কাছে যা চায়, সবই system call-এর দরজা দিয়ে চায়। Linux-এ কয়েকশো syscall আছে, কিন্তু একটি সাধারণ প্রোগ্রাম তার অল্প কয়েকটিই ব্যবহার করে। বাকি প্রতিটি দরজা kernel-এর কোডের একটি অংশ খুলে রাখে — আর kernel-এর বাগ মানে পুরো সিস্টেম। seccomp (secure computing) প্রসেসকে বলতে দেয়: “এখন থেকে আমি শুধু এই কয়েকটি দরজা ব্যবহার করব; অন্য কিছু চাইলে আমাকে থামিয়ে দিন।” একবার বসালে প্রসেস নিজে, এমনকি পরে আক্রান্ত হলেও, এই সীমা আর সরাতে পারে না।

প্রথম রূপ: strict mode (২০০৫)

Linux 2.6.12 (২০০৫)-এ Andrea Arcangeli seccomp আনেন, মূলত অন্যের কম্পিউটারে অবিশ্বস্ত হিসাব চালানোর একটি প্রকল্পের জন্য। এই strict mode-এ অনুমোদিত syscall মাত্র চারটি: read, write, _exit (শুধু exit, exit_group নয়) আর sigreturn. অর্থাৎ আগে থেকে খোলা file descriptor-এ পড়া-লেখা আর বেরিয়ে যাওয়া — ব্যস। অন্য যেকোনো syscall করলেই kernel প্রসেসটিকে SIGKILL দিয়ে শেষ করে। নিচের প্রোগ্রামে সন্তান-প্রসেস strict mode চালু করে, একটি write() করে, তারপর একটি ফাইল খুলতে চায়; বাবা waitpid() দিয়ে দেখে সন্তানের কী হলো।

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <sys/prctl.h>
#include <sys/wait.h>
#include <linux/seccomp.h>

int main(void) {
    fflush(stdout);                      /* empty the buffer before fork */
    pid_t pid = fork();
    if (pid == 0) {                      /* child: lock itself down */
        if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT) != 0) {
            perror("prctl");
            _exit(1);
        }
        const char *m = "child: strict mode on, write() still works\n";
        write(STDOUT_FILENO, m, strlen(m));          /* allowed */
        open("/etc/hostname", O_RDONLY);             /* NOT allowed */
        write(STDOUT_FILENO, "child: never printed\n", 21);
        _exit(0);
    }
    int st;
    waitpid(pid, &st, 0);
    if (WIFSIGNALED(st))
        printf("parent: child killed by signal %d (%s)\n",
               WTERMSIG(st), strsignal(WTERMSIG(st)));
    else
        printf("parent: child exited normally, code %d\n", WEXITSTATUS(st));
    return 0;
}

prctl: Invalid argument
parent: child exited normally, code 1

child: strict mode on, write() still works
parent: child killed by signal 9 (Killed)

দ্বিতীয় রূপ: seccomp-bpf filter (২০১২)

Strict mode এত কড়া যে প্রায় কোনো বাস্তব প্রোগ্রাম এতে চলে না। Chrome-এর renderer sandbox-এর প্রয়োজনে Google-এর Will Drewry একটি নমনীয় রূপ তৈরি করেন, যা Linux 3.5 (২০১২)-এ যুক্ত হয়: seccomp-bpf. এখানে প্রসেস একটি ছোট প্রোগ্রাম kernel-কে দেয়, লেখা BPF (Berkeley Packet Filter)-এর ভাষায় — যে ভাষা আসলে নেটওয়ার্ক প্যাকেট ছাঁকার জন্য তৈরি হয়েছিল। প্রতিটি syscall-এর সময় kernel একটি ছোট কাঠামো seccomp_data বানায় — তাতে থাকে syscall নম্বর (nr), CPU আর্কিটেকচার (arch), নির্দেশের ঠিকানা আর ৬টি argument-এর কাঁচা মান — তারপর filter চালিয়ে একটি রায় নেয়:

এছাড়া SECCOMP_RET_TRACE (debugger-কে জানানো) আর SECCOMP_RET_USER_NOTIF (user-space-এর একটি তত্ত্বাবধায়ক প্রসেসকে সিদ্ধান্ত নিতে দেওয়া, Linux 5.0 থেকে) আছে। দুটি জিনিস মনে রাখুন। এক, filter উত্তরাধিকারে যায়: fork-এর সন্তান আর execve-র পরের প্রোগ্রামও একই filter-এ আটকা। দুই, filter শুধু যোগ করা যায়, সরানো যায় না। কয়েকটি filter থাকলে সবগুলো চলে, আর সবচেয়ে কড়া রায়টি জেতে (KILL > TRAP > ERRNO > … > LOG > ALLOW). নিচের ডায়াগ্রামে একটি allowlist filter-এর ভেতর দিয়ে চারটি ভিন্ন syscall-এর যাত্রা দেখুন:

1A = seccomp_data.arch2if A != X86_64      -> KILL_PROCESS3A = seccomp_data.nr4if A == 0   (read)  -> ALLOW5if A == 1   (write) -> ALLOW6if A == 231 (exit_group) -> ALLOW7if A == 63  (uname) -> ERRNO(EPERM)8default             -> KILL_PROCESS

এবার আসল কোডে একই allowlist — strict mode-এর মতোই কয়েকটি syscall, কিন্তু filter দিয়ে, তাই এই container-এর ভেতরেও চলে (filter-এর ওপর filter বসানো যায়):

#include <stdio.h>
#include <string.h>
#include <stddef.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/prctl.h>
#include <sys/wait.h>
#include <sys/syscall.h>
#include <linux/filter.h>
#include <linux/seccomp.h>
#define ALLOW(n) BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_##n, 0, 1), \
                 BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW)
int main(void) {
    struct sock_filter f[] = {           /* allowlist: like strict mode */
        BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)),
        ALLOW(read), ALLOW(write), ALLOW(exit), ALLOW(exit_group),
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),  /* default */
    };
    struct sock_fprog prog = { sizeof f / sizeof f[0], f };
    fflush(stdout);                      /* empty the buffer before fork */
    pid_t pid = fork();
    if (pid == 0) {
        prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
        if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog) != 0) _exit(1);
        write(STDOUT_FILENO, "child: filter on, write() allowed\n", 34);
        open("/etc/hostname", O_RDONLY);             /* openat: not in list */
        write(STDOUT_FILENO, "child: never printed\n", 21);
        _exit(0);
    }
    int st;  waitpid(pid, &st, 0);
    if (WIFSIGNALED(st))
        printf("parent: child killed by signal %d (%s)\n", WTERMSIG(st), strsignal(WTERMSIG(st)));
    else
        printf("parent: child exited, code %d\n", WEXITSTATUS(st));
}

child: filter on, write() allowed
parent: child killed by signal 31 (Bad system call)

৪ · ERRNO, no_new_privs আর বাস্তবে seccomp বসানো

সব নিষেধ মৃত্যুদণ্ড হওয়ার দরকার নেই। অনেক প্রোগ্রাম কোনো syscall ব্যর্থ হলে বিকল্প পথ নেয় — তাই container runtime-গুলো সাধারণত নিষিদ্ধ syscall-এ EPERM ফেরত দেয়। নিচের প্রোগ্রাম শুধু একটি syscall (uname) আটকায়, বাকি সব চলতে দেয়, আর এবার আর্কিটেকচারও যাচাই করে:

#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <stddef.h>
#include <unistd.h>
#include <sys/prctl.h>
#include <sys/utsname.h>
#include <sys/syscall.h>
#include <linux/audit.h>
#include <linux/filter.h>
#include <linux/seccomp.h>

int main(void) {
    struct sock_filter f[] = {           /* a tiny BPF program */
        BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, arch)),
        BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),   /* wrong arch */
        BPF_STMT(BPF_LD | BPF_W | BPF_ABS, offsetof(struct seccomp_data, nr)),
        BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_uname, 0, 1),
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),  /* uname */
        BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),          /* the rest */
    };
    struct sock_fprog prog = { sizeof f / sizeof f[0], f };
    struct utsname u;
    printf("before: uname() = %d, sysname = %s\n", uname(&u), u.sysname);
    if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) != 0) { perror("no_new_privs"); return 1; }
    if (prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog) != 0) { perror("seccomp"); return 1; }
    int r = uname(&u);
    int e = errno;
    printf("after:  uname() = %d, errno = %d (%s)\n", r, e, strerror(e));
    printf("after:  getpid() still allowed: %s\n", getpid() > 0 ? "yes" : "no");
    return 0;
}

before: uname() = 0, sysname = Linux
after:  uname() = -1, errno = 1 (Operation not permitted)
after:  getpid() still allowed: yes

no_new_privs — কেন filter বসানোর আগে লাগে

Filter বসানোর আগে দুই প্রোগ্রামেই prctl(PR_SET_NO_NEW_PRIVS, 1) ডাকা হয়েছে। এটি প্রসেসে একটি পতাকা বসায়: এই প্রসেস আর তার উত্তরসূরিরা execve দিয়ে আর কখনো নতুন ক্ষমতা পাবে না — setuid বিট (পর্ব ৪৭) বা ফাইলের capability আর কাজ করবে না। পতাকাটি একবার বসালে আর নামানো যায় না। কেন seccomp-এর জন্য এটি দরকার? না থাকলে একজন সাধারণ ব্যবহারকারী filter দিয়ে কোনো setuid-root প্রোগ্রামের syscall-এ ভুয়া ফল দিয়ে তাকে বিভ্রান্ত করতে পারতেন। তাই kernel-এর নিয়ম: CAP_SYS_ADMIN ক্ষমতা না থাকলে seccomp filter বসাতে হলে আগে no_new_privs লাগবে। এটি Linux 3.5-এ seccomp-bpf-এর সাথেই এসেছে, আর এখন systemd বা Docker-এ আলাদা বিকল্প হিসেবেও পাওয়া যায়।

বাস্তবে কেউ হাতে BPF লেখে না

উপরের মতো কাঁচা BPF শেখার জন্য ভালো, কিন্তু বাস্তবে ব্যবহার হয় libseccomp লাইব্রেরি বা তৈরি করা profile. আপনার নিজের সার্ভারে সবচেয়ে সহজ রক্ষাকবচ সম্ভবত systemd-এর sandbox বিকল্পগুলো — একটি সার্ভিস ফাইলে কয়েকটি লাইন:

[Service]
ExecStart=/usr/local/bin/myapp
# (systemd allows comments only on their own lines, never after a value)
# never run a web app as root
User=myapp
# the no_new_privs flag
NoNewPrivileges=yes
# seccomp allowlist of common syscall groups, plus the arch check from above
SystemCallFilter=@system-service
SystemCallArchitectures=native
# keep only "bind port < 1024" in the bounding set
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
# /usr, /etc read-only; /home invisible; its own /tmp; one writable folder
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
ReadWritePaths=/var/lib/myapp

তারপর systemd-analyze security myapp.service চালালে systemd প্রতিটি বিকল্প দেখে একটি “exposure” নম্বর দেয় — কোন সুরক্ষা বাকি আছে, তার তালিকাসহ। Container-এর জগতে Docker নিজের ডিফল্ট seccomp profile (পর্ব ৫-এ উল্লেখ করা) প্রতিটি container-এ বসায়: একটি allowlist, যার বাইরের কয়েক ডজন ঝুঁকিপূর্ণ syscall (যেমন kernel module লোড, ঘড়ি বদলানো) EPERM পায়। --security-opt seccomp=profile.json দিয়ে নিজের profile দেওয়া যায়। উল্টো দিকে, --privileged বা seccomp=unconfined এই সুরক্ষা প্রায় পুরোটাই তুলে দেয় — এগুলো দেখলে আগে প্রশ্ন করুন, সত্যিই কি দরকার।

৫ · আরও ইট — capability, namespace, Landlock আর chroot-এর সীমা

Linux capabilities. পুরোনো Unix-এ ক্ষমতা ছিল দুই রকম: root (সব) আর বাকিরা (প্রায় কিছু না)। Linux 2.2 (১৯৯৯) থেকে root-এর ক্ষমতা প্রায় ৪০টি টুকরোয় ভাগ করা: CAP_NET_BIND_SERVICE (১০২৪-এর নিচের port-এ বসা), CAP_NET_RAW (কাঁচা প্যাকেট, যেমন ping), CAP_SYS_TIME (ঘড়ি বদলানো), CAP_SYS_MODULE (kernel module লোড), CAP_SYS_ADMIN (এত বিচিত্র কাজের অনুমতি যে kernel ডেভেলপাররাই একে ঠাট্টা করে “নতুন root” বলেন)। একটি ওয়েব সার্ভারের ৮০ নম্বর port-এ বসতে শুধু প্রথমটি লাগে; বাকি সব ছেঁটে ফেললে সার্ভার আক্রান্ত হলেও আক্রমণকারী module লোড বা ঘড়ি বদলাতে পারবে না। প্রতিটি প্রসেসের কয়েকটি capability-সেট থাকে — সবচেয়ে গুরুত্বপূর্ণ effective (এখন যা খাটে, CapEff) আর bounding (ভবিষ্যতে সর্বোচ্চ যা পাওয়া সম্ভব, CapBnd). এগুলো একটি ৬৪-bit সংখ্যার bit হিসেবে লেখা হয়: bit n চালু মানে capability নম্বর n আছে। (পর্ব ৪৬-এর access matrix-এর capability list থেকে এটি আলাদা জিনিস।)

Namespace. seccomp ঠিক করে প্রসেস কী করতে পারবে; namespace ঠিক করে সে কী দেখতে পাবে। PID namespace-এ প্রসেস শুধু নিজের দলের প্রসেস দেখে, mount namespace-এ নিজের file system-এর দৃশ্য, network namespace-এ নিজের নেটওয়ার্ক, user namespace-এ নিজের UID-জগৎ। Container এই namespace আর cgroup দিয়েই তৈরি — বিস্তারিত পর্ব ৫১-এ।

Landlock. SELinux বা AppArmor-এর নীতি লেখেন সিস্টেম প্রশাসক, root হিসেবে। কিন্তু একটি সাধারণ প্রোগ্রাম যদি নিজেই বলতে চায় “আমি শুধু এই দুটি ফোল্ডারে হাত দেব”? Linux 5.13 (২০২১)-এ যুক্ত Landlock ঠিক এটি দেয় — অধিকারবিহীন (unprivileged) প্রসেসের নিজের জন্য ফাইল-প্রবেশের sandbox, root ছাড়াই। পরের সংস্করণগুলোতে আরও নিয়ম যোগ হয়েছে (যেমন TCP port-এ bind/connect নিয়ন্ত্রণ), তাই প্রোগ্রাম আগে kernel-কে জিজ্ঞেস করে কোন “ABI সংস্করণ” সমর্থিত। ব্যবহারের ধাপ তিনটি:

/* 1. which kinds of access will this ruleset govern? */
struct landlock_ruleset_attr attr = {
    .handled_access_fs = LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_WRITE_FILE /* | ... */ };
int rs = syscall(SYS_landlock_create_ruleset, &attr, sizeof attr, 0);

/* 2. add one rule: reading is allowed beneath /usr/share/myapp */
struct landlock_path_beneath_attr pb = {
    .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE,
    .parent_fd = open("/usr/share/myapp", O_PATH | O_CLOEXEC) };
syscall(SYS_landlock_add_rule, rs, LANDLOCK_RULE_PATH_BENEATH, &pb, 0);

/* 3. lock myself in (no_new_privs first, just like seccomp) */
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
syscall(SYS_landlock_restrict_self, rs, 0);   /* irreversible, inherited */

chroot কেন নিরাপত্তার সীমানা নয়। chroot("/srv/jail") প্রসেসকে বলে “এখন থেকে / মানে /srv/jail”. পুরোনো অনেক গাইডে একে “chroot jail” বলা হয়, যেন এটি কারাগার। আসলে এটি শুধু path খোঁজার শুরুর বিন্দু বদলায়, আর কিছু না। প্রসেস তখনো একই UID, একই capability, একই PID আর নেটওয়ার্ক-জগৎ, আর সব syscall হাতে পায়। ফলে root ক্ষমতা থাকলে chroot-এর বাইরে বেরোনোর একাধিক সুপরিচিত পথ আছে; root ছাড়াও chroot-এর ভেতরের প্রসেস বাইরের প্রসেসকে signal পাঠাতে বা নেটওয়ার্কে যেতে পারে। Linux-এর নিজের chroot(2) man পাতা স্পষ্ট বলে, এটি কোনো নিরাপত্তা-উদ্দেশ্যে তৈরি নয় — না প্রসেসকে পুরো sandbox করতে, না file system-এর syscall সীমিত করতে। প্রতিরক্ষার সঠিক পথ: mount namespace + pivot_root (container যেভাবে করে), root-ক্ষমতা ছেড়ে দেওয়া, তার ওপর seccomp আর LSM.

এবার এই পাতার রানার-কন্টেইনারের নিজের sandbox-অবস্থা দেখা যাক — শুধু-পড়ার কমান্ড, কিছু বদলায় না:

echo "== seccomp, no_new_privs and capabilities of this shell =="
grep -E '^(CapEff|CapBnd|NoNewPrivs|Seccomp|Seccomp_filters):' /proc/self/status
echo "== which LSMs are active? =="
if [ -r /sys/kernel/security/lsm ]; then
    cat /sys/kernel/security/lsm; echo
else
    echo "/sys/kernel/security/lsm: not visible here (common inside a container)"
fi
echo "AppArmor enabled : $(cat /sys/module/apparmor/parameters/enabled 2>/dev/null || echo unknown)"
echo "SELinux fs found : $([ -d /sys/fs/selinux ] && echo yes || echo no)"
echo "my AppArmor label: $(cat /proc/self/attr/apparmor/current 2>/dev/null || echo none)"
echo "== the bounding set, decoded =="
capsh --decode="$(awk '/^CapBnd/ {print $2}' /proc/self/status)"

== seccomp, no_new_privs and capabilities of this shell ==
CapEff:	0000000000000000
CapBnd:	00000000800405fb
NoNewPrivs:	0
Seccomp:	2
Seccomp_filters:	1
== which LSMs are active? ==
/sys/kernel/security/lsm: not visible here (common inside a container)
AppArmor enabled : Y
SELinux fs found : no
my AppArmor label: crun (unconfined)
== the bounding set, decoded ==
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

৬ · DAC বনাম MAC — মালিক ঠিক করবেন, না নীতি?

পর্ব ৪৭-এর rwx অনুমতি হলো DAC (Discretionary Access Control): ফাইলের মালিক নিজের বিবেচনায় ঠিক করেন কে পড়বে, কে লিখবে। chmod 644 দিলে সবাই পড়তে পারে — মালিকের ইচ্ছা। সমস্যা দুটি। এক, মালিকের নামে চলা যেকোনো প্রোগ্রাম মালিকের সব ক্ষমতা পায়; আক্রান্ত PDF reader-ও chmod চালাতে পারে। দুই, root সব DAC নিয়মের ঊর্ধ্বে। MAC (Mandatory Access Control)-এ সিদ্ধান্ত নেয় সিস্টেমের কেন্দ্রীয় নীতি, যা প্রশাসক লোড করেন আর kernel প্রয়োগ করে; ফাইলের মালিক তা ঢিলা করতে পারেন না, আর ভালোভাবে নকশা করা নীতিতে root-এর প্রসেসও নিজের নির্দিষ্ট গণ্ডির বাইরে যেতে পারে না।

Linux-এ দুটি একসাথে চলে: kernel আগে DAC যাচাই করে, DAC অনুমতি দিলে তারপর LSM (Linux Security Modules)-এর hook-এ MAC নীতি যাচাই হয়। দুটিতেই “হ্যাঁ” লাগবে। MAC কখনো DAC-এর নিষেধ উল্টে দেয় না — শুধু বাড়তি নিষেধ যোগ করে।

Bell–LaPadula — গোপনীয়তার মডেল

১৯৭৩ সালে MITRE-এর David Bell আর Leonard LaPadula মার্কিন প্রতিরক্ষা বিভাগের প্রয়োজনে একটি গাণিতিক মডেল দেন — Bell–LaPadula মডেল — যার লক্ষ্য একটাই: গোপন তথ্য যেন নিচের স্তরে চুঁইয়ে না পড়ে। প্রতিটি ব্যবহারকারী বা প্রসেস (subject)-এর একটি ছাড়পত্র-স্তর, আর প্রতিটি ফাইল (object)-এর একটি শ্রেণি: Unclassified < Confidential < Secret < Top Secret. দুটি নিয়ম:

• Simple security property — “no read up”: নিজের স্তরের চেয়ে উঁচু শ্রেণির ফাইল পড়া যাবে না।
• ★-property — “no write down”: নিজের স্তরের চেয়ে নিচু শ্রেণির ফাইলে লেখা যাবে না।

দ্বিতীয় নিয়মটিই চতুর। Secret স্তরের একজন অফিসার Secret ফাইল পড়তে পারেন — কিন্তু তিনি (বা তাঁর নামে চলা কোনো ক্ষতিকর প্রোগ্রাম) যদি সেই তথ্য একটি Unclassified ফাইলে লিখে দেন, সবাই পড়ে ফেলবে। No write down এই ফাঁস বন্ধ করে।

Biba — অখণ্ডতার মডেল

১৯৭৭ সালে Kenneth Biba উল্টো প্রশ্ন করেন: তথ্য ফাঁস নয়, বিশ্বস্ত তথ্য যেন অবিশ্বস্ত উৎস দিয়ে নষ্ট না হয়। Biba-র নিয়ম Bell–LaPadula-র ঠিক উল্টো: “no read down” (নিচু-অখণ্ডতার, যেমন ইন্টারনেট থেকে আসা, ডেটা পড়ে উঁচু-অখণ্ডতার প্রসেস নিজেকে দূষিত করবে না) আর “no write up” (নিচু-অখণ্ডতার প্রসেস সিস্টেম ফাইলে লিখতে পারবে না)। Windows-এর integrity level-এর ডিফল্ট নিয়ম (Low প্রসেস Medium ফাইলে লিখতে পারে না) Biba-র “no write up”-এর একটি সরল প্রয়োগ।

দুটি মডেল একসাথে খাটালে প্রসেস কেবল নিজের স্তরেই পড়তে-লিখতে পারে — নিরাপদ, কিন্তু অচল। তাই বাস্তব সিস্টেম মডেলগুলোর অংশবিশেষ নেয়। SELinux-এর MLS নীতি Bell–LaPadula-ধরনের স্তর দিতে পারে, কিন্তু সাধারণ সার্ভারে যে অংশটি সবচেয়ে বেশি কাজে আসে তা হলো type enforcement — পরের অংশ।

৭ · SELinux — label, type enforcement আর denial পড়া

SELinux তৈরি করে মার্কিন NSA, ২০০০ সালে মুক্ত সফটওয়্যার হিসেবে প্রকাশ করে। একে kernel-এ আনার আলোচনা থেকেই জন্ম নেয় LSM কাঠামো, যা Linux 2.6 (২০০৩)-এ যুক্ত হয়। আজ Fedora, RHEL, CentOS Stream, Rocky/AlmaLinux আর Android-এ এটি ডিফল্টে চালু।

সবকিছুর একটি label. SELinux-এ প্রতিটি প্রসেস আর প্রতিটি ফাইল, socket, port-এর একটি security context থাকে, চার ভাগে: user:role:type:level. যেমন Apache ওয়েব সার্ভারের প্রসেস system_u:system_r:httpd_t:s0, আর ওয়েবসাইটের ফাইল system_u:object_r:httpd_sys_content_t:s0. প্রতিদিনের কাজে প্রায় সব সিদ্ধান্ত হয় তৃতীয় ভাগ — type — দিয়ে; প্রসেসের type-কে বলে domain. শেষ ভাগ s0 হলো MLS/MCS স্তর, যা দিয়ে একই type-এর দুটি container-কে আলাদা রাখা হয় (যেমন s0:c123,c456). Label ফাইল সিস্টেমের extended attribute-এ জমা থাকে, তাই নাম বদলালেও label ফাইলের সাথেই যায়।

Type enforcement. নীতি (policy) হলো হাজারো allow নিয়মের সংকলন, যেমন (সরলীকৃত):

allow httpd_t httpd_sys_content_t : file { read open getattr };
allow httpd_t httpd_log_t         : file { append open };

অর্থ: httpd_t domain-এর প্রসেস httpd_sys_content_t type-এর ফাইল পড়তে পারবে, লগ ফাইলে শুধু যোগ করতে পারবে। যা লেখা নেই, তা নিষেধ — default deny. ফলে Apache-তে বাগ কাজে লাগিয়ে কেউ ঢুকলেও, প্রসেস root হলেও, সে /home-এর ফাইল, /etc/shadow বা SSH key পড়তে পারে না, কারণ httpd_t-এর জন্য সেই type-এর কোনো allow নেই। ডিফল্ট “targeted” নীতিতে শুধু নেটওয়ার্ক-সার্ভিসের মতো ঝুঁকিপূর্ণ প্রোগ্রামগুলো নিজস্ব domain-এ আটকা থাকে; সাধারণ ব্যবহারকারীর প্রোগ্রাম চলে unconfined_t-এ।

তিনটি মোড. Enforcing — নীতি প্রয়োগ হয়, নিষেধ মানে EACCES. Permissive — নীতি হিসাব হয় আর প্রতিটি “নিষেধ হতো” ঘটনা লগ হয়, কিন্তু কাজটি চলতে দেওয়া হয়; শুধু সমস্যা খোঁজার জন্য। Disabled — SELinux নেই, নতুন ফাইল label-ও পায় না, তাই পরে চালু করতে পুরো ফাইল সিস্টেম আবার label করতে হয়। পরিস্থিতি দেখার শুধু-পড়ার কমান্ড (উদাহরণ আউটপুট, Fedora/RHEL-ধরনের সিস্টেম):

$ getenforce
Enforcing
$ sestatus | head -5
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
$ ps -eZ | grep httpd | head -1
system_u:system_r:httpd_t:s0       1234 ?        00:00:00 httpd
$ ls -Z /var/www/html/
  system_u:object_r:httpd_sys_content_t:s0 index.html
unconfined_u:object_r:user_home_t:s0       report.html

দ্বিতীয় ফাইলটির label অদ্ভুত — user_home_t, যেন সে home ফোল্ডারে আছে। খুব পরিচিত একটি ঘটনা: প্রশাসক ফাইলটি নিজের home-এ বানিয়ে mv দিয়ে এনেছেন। mv label সহ ফাইল সরায়; cp নতুন ফাইল বানায়, যা গন্তব্য ফোল্ডারের label পায়। নিচে kernel কীভাবে সিদ্ধান্ত নেয়, ধাপে ধাপে দেখুন:

Denial পড়া — audit2why-র কাজ

Denial-এর লগ প্রথমে ভয়ংকর দেখায়, কিন্তু এটি একটি কাঠামোবদ্ধ বাক্য। সাধারণত /var/log/audit/audit.log-এ থাকে (উদাহরণ, পড়ার সুবিধার জন্য লাইন ভাঙা):

type=AVC msg=audit(1729900000.123:456): avc:  denied  { read } for
  pid=1234 comm="httpd" name="report.html" dev="nvme0n1p3" ino=789012
  scontext=system_u:system_r:httpd_t:s0
  tcontext=unconfined_u:object_r:user_home_t:s0
  tclass=file permissive=0

পড়ার নিয়ম: { read } = কোন অনুমতি চাওয়া হয়েছিল; comm = কোন প্রোগ্রাম; scontext = কে চাইছে; tcontext = কার কাছে; tclass = বস্তুর শ্রেণি; permissive=0 = সত্যিই আটকানো হয়েছে। ausearch -m AVC -ts recent | audit2why প্রতিটি denial-এর সম্ভাব্য কারণ বলে — যেমন “Missing type enforcement (TE) allow rule”, বা কোনো boolean বন্ধ আছে (যেমন httpd_can_network_connect_db, যা চালু করলে ওয়েব সার্ভার ডেটাবেসে সংযোগ করতে পারে)। এরপর সমাধানের ক্রম মোটামুটি এরকম:

1. Label ভুল? restorecon -Rv <path>; নতুন জায়গায় ওয়েবসাইট রাখলে স্থায়ী নিয়ম: semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?", তারপর restorecon. (chcon-এর পরিবর্তন পরের relabel-এ মুছে যায়।)
2. বৈধ কাজ, কিন্তু ডিফল্টে বন্ধ? উপযুক্ত boolean খুঁজে setsebool -P <name> on.
3. সার্ভিস অন্য port-এ? semanage port -a -t http_port_t -p tcp 9876 (port-টি আগেই অন্য type-এ থাকলে -a-এর বদলে -m).
4. সত্যিই নতুন নিয়ম দরকার? audit2allow একটি নীতি-module প্রস্তাব করতে পারে — কিন্তু অন্ধভাবে বসালে “যা ভেঙেছিল, সব অনুমতি দাও” হয়ে যায়। প্রতিটি লাইন পড়ে বুঝে তবেই।

৮ · AppArmor — path দিয়ে লেখা profile, আর দুটির তুলনা

AppArmor-এর শুরু ১৯৯০-এর দশকের শেষে Immunix কোম্পানির “SubDomain” নামে; পরে Novell/SUSE এটি এগিয়ে নেয়, আর ২০০৭ সাল থেকে Ubuntu-তে এটি ডিফল্ট। Debian, SUSE আর তাদের উত্তরসূরিরাও এটি ব্যবহার করে। Linux 2.6.36 (২০১০)-এ এটি মূল kernel-এ যুক্ত হয়। SELinux যেখানে প্রতিটি ফাইলে label লাগায়, AppArmor সেখানে প্রতিটি প্রোগ্রামের জন্য একটি profile লেখে, আর profile-এ নিয়ম লেখা হয় ফাইলের path দিয়ে। নিজের একটি প্রোগ্রামের জন্য profile দেখতে এরকম (সরলীকৃত):

#include <tunables/global>

/usr/local/bin/myapp {
  #include <abstractions/base>

  /usr/local/bin/myapp      mr,     # map + read its own binary
  /etc/myapp/**             r,      # read its config
  /var/lib/myapp/**         rw,     # its data
  network inet stream,              # TCP only
  deny /home/**             rwx,    # never touch home directories
}

প্রতিটি profile দুই মোডের একটিতে থাকে: enforce (নিয়ম প্রয়োগ, লঙ্ঘন আটকানো ও লগ) আর complain (শুধু লগ — SELinux-এর permissive-এর মতো, কিন্তু প্রতিটি profile আলাদাভাবে)। নতুন profile লেখার স্বাভাবিক পথ: complain মোডে প্রোগ্রাম চালিয়ে সব কাজ করা, লগ থেকে aa-logprof দিয়ে নিয়ম বাছাই, তারপর aa-enforce. অবস্থা দেখার কমান্ড (উদাহরণ আউটপুট, root লাগে):

$ sudo aa-status
apparmor module is loaded.
58 profiles are loaded.
52 profiles are in enforce mode.
   /usr/bin/man
   /usr/sbin/cupsd
   ...
6 profiles are in complain mode.
   ...
2 processes have profiles defined.
2 processes are in enforce mode.
   /usr/sbin/cupsd (1187)
   /usr/sbin/cups-browsed (1203)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
$ sudo journalctl -k | grep 'apparmor="DENIED"' | tail -1
... apparmor="DENIED" operation="open" profile="/usr/local/bin/myapp"
    name="/home/rahim/notes.txt" requested_mask="r" denied_mask="r" ...

শেষ লাইনটি SELinux-এর AVC-র মতোই পড়ুন: কোন profile, কোন কাজ (open), কোন path, কোন অনুমতি। Docker-ও Ubuntu-তে প্রতিটি container-এ নিজের docker-default AppArmor profile বসায়। (আগের bash ব্লকের crun (unconfined) label-টিও এই ব্যবস্থারই চিহ্ন।)

বাস্তবে বড় কথা হলো নিজের distro যেটি দেয়, সেটি চালু রাখা আর তার লগ পড়তে শেখা। একই kernel-এ capability, Yama, Landlock, lockdown-এর মতো ছোট LSM পাশাপাশি চলে, আর SELinux বা AppArmor-এর মতো বড় মডিউলের একটি সাধারণত প্রধান থাকে।

৯ · Secure Boot আর measured boot গভীরে — key, shim, TPM আর attestation

এ পর্যন্ত যত sandbox দেখলেন, সবই kernel-এর ওপর ভরসা করে। কিন্তু kernel নিজেই যদি বদলানো হয়? পর্ব ৭-এ দেখেছেন Secure Boot বুটের প্রতিটি ধাপের স্বাক্ষর যাচাই করে একটি chain of trust বানায়। এবার দেখব key-গুলো কে রাখে, কে কাকে বদলাতে পারে, Linux কীভাবে এতে ঢোকে, আর “যাচাই” ছাড়াও “মাপা” কেন দরকার।

চার স্তরের key-ব্যবস্থা

PK না থাকলে firmware থাকে “Setup Mode”-এ — তখন যে-কেউ key বসাতে পারে; PK বসালে “User Mode”, আর তখন প্রতিটি পরিবর্তনে উপরের স্তরের স্বাক্ষর লাগে। তাই ক্ষতিকর প্রোগ্রাম OS থেকে চুপচাপ নিজের key db-তে ঢোকাতে পারে না। অভিজ্ঞ মালিক চাইলে firmware-এর মেনু থেকে Setup Mode-এ নিয়ে পুরো key-শিকল নিজের key দিয়ে বদলাতে পারেন (Linux-এ sbctl-এর মতো tool দিয়ে)। তবে সাবধান: অনেক graphics কার্ডের firmware (option ROM) Microsoft-এর key-তে স্বাক্ষরিত, তাই সেই key সরালে কিছু কম্পিউটারে স্ক্রিনই আসে না — এটি কেবল নিজের হার্ডওয়্যার ভালো করে জেনে, ব্যাকআপ রেখে করার কাজ।

Linux-এর পথ: shim, MOK আর স্বাক্ষরিত module

shim Microsoft-এর UEFI CA দিয়ে স্বাক্ষরিত, আর ভেতরে distro-র নিজের সার্টিফিকেট বহন করে। এর সাথে আছে MOK (Machine Owner Key) তালিকা: মালিকের নিজের key, যা firmware-এর NVRAM-এ এমনভাবে জমা থাকে যে OS চালু হওয়ার পরে সরাসরি বদলানো যায় না। নিজে বানানো driver (যেমন DKMS দিয়ে তৈরি কোনো Wi-Fi বা graphics module) চালাতে চাইলে পথটি এরকম: একটি key জোড়া বানিয়ে module স্বাক্ষর করা; mokutil --import key.der দিয়ে একটি পাসওয়ার্ডসহ অনুরোধ রাখা; রিবুটে নীল রঙের MokManager স্ক্রিনে শারীরিকভাবে উপস্থিত মালিক সেই পাসওয়ার্ড দিয়ে নিশ্চিত করেন। এই শেষ ধাপটিই নিরাপত্তা — দূর থেকে চলা কোনো প্রোগ্রাম নিজে নিজে key যোগ করতে পারে না।

Kernel-এ module signing চালু থাকলে প্রতিটি .ko ফাইলের শেষে একটি স্বাক্ষর থাকে, আর kernel তার বিশ্বস্ত key-তালিকা (kernel-এ বসানো key, আর db/MOK থেকে আসা key) দিয়ে যাচাই করে। স্বাক্ষর না মিললে modprobe জানায় “Key was rejected by service”. Secure Boot চালু থাকলে অনেক distro kernel-এর lockdown মোডও চালু করে: root-ও তখন স্বাক্ষরবিহীন module, /dev/mem-এ লেখা বা স্বাক্ষরবিহীন kernel-এ kexec করতে পারে না। যুক্তিটি সরল — বুটে kernel যাচাই করে লাভ কী, যদি চলার পরে root যেকোনো কোড kernel-এ ঢোকাতে পারে?

বাতিল করার কাজ (revocation)-এ একটি ব্যবহারিক সমস্যা ছিল: dbx-এর জায়গা firmware-এর ছোট NVRAM-এ সীমিত। ২০২০ সালের BootHole-এর পর অসংখ্য পুরোনো GRUB-এর hash বাতিল করতে গিয়ে এটি স্পষ্ট হয়। তাই ২০২১ সালে shim-এ SBAT যুক্ত হয়: প্রতিটি bootloader-এ একটি “generation” নম্বর লেখা থাকে, আর একটি ছোট variable-এ সর্বনিম্ন গ্রহণযোগ্য generation; একটি সংখ্যা বাড়িয়েই পুরোনো সব সংস্করণ একসাথে বাতিল করা যায়। নিচে পুরো শিকলটি দেখুন:

Measured boot আর TPM — যাচাইয়ের পাশাপাশি হিসাব রাখা

Secure Boot একটি দারোয়ান: স্বাক্ষর মিললে ঢুকতে দেয়, নইলে আটকায় — কিন্তু কে ঢুকল, তার খাতা রাখে না। Measured boot হলো সেই খাতা। প্রতিটি ধাপ পরের ধাপকে চালানোর আগে তার hash নেয় আর TPM (Trusted Platform Module) চিপের একটি PCR (Platform Configuration Register)-এ “extend” করে: PCR_নতুন = SHA-256(PCR_{পুরোনো} ‖ পরিমাপ)। PCR-এ সরাসরি কোনো মান লেখা যায় না, আর রিবুট ছাড়া শূন্যও করা যায় না। ফলে শেষ মান একটি আঙুলের ছাপ — কোন কোড, কোন ক্রমে চলেছে। নিয়মিত ব্যবহৃত কয়েকটি PCR: PCR 0 (firmware-এর কোড), PCR 4 (bootloader-এর কোড), PCR 7 (Secure Boot-এর অবস্থা আর কোন key-তে যাচাই হলো)। প্রতিটি পরিমাপ একটি event log-এও লেখা থাকে, যা পরে আবার হিসাব করে PCR-এর সাথে মেলানো যায়।

একটি খেলনা উদাহরণ — ফাইলের বদলে তিনটি ছোট টেক্সট: shim, grub আর kernel; বদলানো বুটে grub-এর জায়গায় এক অক্ষর আলাদা grud. প্রতিটির SHA-256 নিয়ে PCR-এ extend করা হয়েছে (পুরো ৩২ বাইটের মান জুড়ে), টেবিলে শুধু প্রথম ৮টি hex অঙ্ক (একটি scratch স্ক্রিপ্টে হিসাব করা):

GRUB-এর একটি অক্ষর (বাইট) বদলালেই সেই ধাপ থেকে পরের সব PCR আলাদা হয়ে যায় — kernel হুবহু এক হলেও। এই মাপ তিনভাবে কাজে লাগে:

• Sealing: TPM একটি গোপন key (যেমন ডিস্ক-এনক্রিপশনের key) এই শর্তে রাখে — “PCR 7-এর মান এটি হলে তবেই ছাড়বে”। বুট-শিকল বদলালে PCR বদলায়, TPM key ছাড়ে না। Windows-এর BitLocker TPM দিয়ে ঠিক এভাবে ডিস্ক খোলে; তাই firmware আপডেট, মাদারবোর্ড বদলানো বা Secure Boot সেটিং বদলানোর পর প্রায়ই ৪৮ অঙ্কের recovery key চায়। Linux-এ একই কাজ systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7-এর মতো কমান্ডে।
• Remote attestation: দূরের একটি সার্ভার একটি এলোমেলো সংখ্যা (nonce) পাঠায়; TPM নিজের attestation key দিয়ে “PCR-এর মান + nonce” স্বাক্ষর করে (একে বলে quote). সার্ভার event log আবার হিসাব করে মিলিয়ে দেখে যন্ত্রটি জানা-ভালো অবস্থায় বুট হয়েছে কি না — যেমন অফিসের নেটওয়ার্কে ঢোকার আগে, বা ক্লাউডের সার্ভারে।
• তদন্ত: কোনো অস্বাভাবিকতা ধরা পড়লে event log থেকে বোঝা যায় কোন ধাপে পরিমাপ বদলেছে।

TPM-এর আরও কিছু কাজ: হার্ডওয়্যার এলোমেলো-সংখ্যা উৎপাদন, এমন key রাখা যা কখনো চিপের বাইরে খোলা অবস্থায় আসে না, আর পিন বারবার ভুল দিলে সাময়িক তালা (dictionary-attack সুরক্ষা)। TPM আলাদা চিপ হতে পারে, বা CPU-র firmware-এর ভেতরে (fTPM). Windows 11 ইনস্টলের শর্তে TPM 2.0 থাকা এর গুরুত্ব সাধারণ ব্যবহারকারীর কাছেও পৌঁছে দিয়েছে। ঝুঁকি বেশি এমন ল্যাপটপে শুধু-TPM-এর বদলে TPM + PIN ব্যবহার ভালো অভ্যাস — তখন key ছাড়তে মালিকের উপস্থিতিও লাগে।

ফোনে: Android-এর Verified Boot partition-গুলোর hash স্বাক্ষরিত vbmeta-তে রাখে, dm-verity দিয়ে চলার সময় যাচাই করে আর পুরোনো দুর্বল সংস্করণে ফেরা ঠেকায়। iPhone-এ Boot ROM থেকে kernel পর্যন্ত প্রতিটি ধাপ Apple-এর key-তে যাচাই হয়। খুঁটিনাটি নির্মাতা ও সংস্করণভেদে আলাদা।

১০ · AI-এর যুগে নিরাপত্তা-পরামর্শ — দ্রুত “সমাধান”-এর দাম

নিরাপত্তা-ব্যবস্থা মাঝে মাঝে কাজ আটকায় — ওয়েবসাইটে 403, container-এ “Operation not permitted”, নতুন driver লোড হয় না। তখন AI-কে জিজ্ঞেস করলে প্রায়ই সবচেয়ে ছোট উত্তরটি আসে: সুরক্ষাটি বন্ধ করুন। উত্তরটি “কাজ করে” — যেমন দরজার তালা খুলে রাখলে চাবি হারানোর সমস্যা মেটে। AI আপনার লগ দেখে না, আপনার distro জানে না, আর পুরোনো ফোরাম-পোস্টের অভ্যাস নকল করে।

AI-এর নিরাপত্তা-পরামর্শ প্রয়োগের আগে — চেকলিস্ট

• নিজের distro, সংস্করণ আর সক্রিয় LSM (/sys/kernel/security/lsm বা getenforce / aa-status) AI-কে জানিয়েছি
• আসল denial লগ (AVC বা apparmor="DENIED") পড়েছি — অনুমানের ওপর সমাধান নয়
• প্রস্তাবিত কমান্ড man পাতা বা distro-র অফিসিয়াল ডকুমেন্টেশনে মিলিয়েছি
• সমাধানটি সুরক্ষা চালু রেখেই কাজ করে — setenforce 0, --privileged, Secure Boot off বা chmod 777 নয়
• seccomp filter বা profile বদলালে একটি ছোট পরীক্ষা-প্রোগ্রামে, আর LOG / complain মোডে আগে চালিয়ে দেখেছি
• সমাধানের পর আবার enforcing / enforce মোডে পুরো কাজটি পরীক্ষা করেছি আর লগে নতুন denial নেই