یہاں ایک پروگرام ہے جو خود کو محدود کرنے کے بعد دو فائلوں کو پڑھنے کی کوشش کرتا ہے۔
without landlock:
read /etc/hostname ok
read /tmp/secret.txt ok
with landlock, /etc allowed:
read /etc/hostname ok
read /tmp/secret.txt FAILED (Permission denied)
کوئی جڑ نہیں ہے، کوئی کنٹینر نہیں، کوئی ترتیب فائلیں، اور کوئی ڈیمن نہیں ہے۔ پروگرام نے دانا سے زیادہ تر فائل سسٹم تک اپنی رسائی ختم کرنے کو کہا، اور کرنل نے اس کی تعمیل کی۔
یہ لینڈ لاک ہے، جسے 2021 سے زیادہ تر لوگوں کے نوٹس کیے بغیر کرنل میں شامل کیا گیا ہے۔ یہ مضمون چار حیرتوں کو بیان کرتا ہے جو شروع سے پروگرام بنانے اور چلانے کے بعد سب سے پہلے لوگوں پر حملہ کرتے ہیں۔
انڈیکس
آپ کو کیا ضرورت ہے
اس کے ساتھ چلنے کے لیے، آپ کو 5.13 یا اس سے زیادہ کا دانا، معیاری ہیڈر، اور ایک C کمپائلر کی ضرورت ہوگی۔ اور کچھ نہیں، خاص طور پر جڑ نہیں۔
grep landlock /sys/kernel/security/lsm
ls /usr/include/linux/landlock.h
پہلا حکم اہم ہے۔ یہاں تک کہ اگر لینڈ لاک کو دانا میں مرتب کیا گیا ہے، تب بھی یہ غیر فعال ہو سکتا ہے۔ اس کی وجہ یہ ہے کہ لینکس سیکیورٹی ماڈیول کا بوٹ کے وقت فعال ہونا ضروری ہے۔ یہ کمپیوٹر فائل پڑھتا ہے۔ lockdown,capability,landlock,yama,apparmor.
اگر landlock یہ آپ سے غائب ہے۔ براہ کرم شامل کریں۔ lsm=landlock, کرنل کمانڈ لائن میں موجودہ فہرست میں آگے بڑھیں اور ریبوٹ کریں۔ Ubuntu 22.04 سے فعال رہا ہے، حالانکہ موجودہ Fedora اور Arch kernels بھی اس کی حمایت کرتے ہیں۔ grep اوپر والا واحد جواب ہے جو آپ کے کمپیوٹر کے لیے اہمیت رکھتا ہے۔
ذیل کی ہر چیز کو ایک عام صارف کے طور پر چلایا گیا تھا بغیر سوڈو کے kernel 5.15.0-190-generic پر Ubuntu 22.04.5 پر gcc 11.4 کے ساتھ مرتب کیا گیا تھا۔
لینڈ لاک کہاں واقع ہے؟
لینکس سیکیورٹی ماڈیولز فریم ورک ہیں، پالیسیاں نہیں۔ فائل کو کھولنے، پروسیس بنانے، یا قابل عمل میموری کی نقشہ سازی کرنے سے پہلے دانا ایل ایس ایم ہک کو فیصلے کے مقام پر کال کرتا ہے، اور جو بھی ماڈیول لوڈ ہوتا ہے اس کا جواب ہاں یا نہیں میں دیتا ہے۔
SELinux اور AppArmor دو ایسے ہیں جن کے بارے میں زیادہ تر لوگوں نے سنا ہے، اور دونوں ایڈمنسٹریٹر ٹولز ہیں۔ روٹ والا کوئی شخص پالیسی لکھتا ہے، سسٹم اسے لوڈ کرتا ہے، اور پروگرام اس پالیسی کے مطابق رہتا ہے۔
لینڈ لاک اس کو الٹ دیتا ہے۔ یہ پہلا LSM ہے جو بغیر اجازت کے رن ٹائم کے وقت خود پر لاگو ہو سکتا ہے۔ آپ کو اپنے منتظم کو قائل کرنے کی ضرورت نہیں ہے کہ آپ کا پروگرام پالیسی کے لیے اہل ہے۔ پروگرام فی الحال اس سے کم مانگتا ہے، اور دانا اسے کم کر دیتا ہے۔
"کم پوچھیں” مکمل ڈیزائن ہے۔ لینڈ لاک صرف رسائی کو ہٹا سکتا ہے۔ ایسی کوئی چیز دینے کے لیے کوئی کال نہیں ہے جو آپ کے پاس پہلے سے نہیں ہے۔ یہی وجہ ہے کہ غیر مراعات یافتہ عملوں کی نمائش محفوظ ہے۔
3 سسٹم کالز اور کوئی لائبریری نہیں۔
لینڈ لاک تین سسٹم کالز ہیں اور glibc ان میں سے کسی کو بھی نہیں لپیٹتا ہے، لہذا ہم انہیں براہ راست بذریعہ کال کرتے ہیں: syscall():
static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }
static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }
static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }
landlock_create_ruleset اعلان کریں کہ قواعد کے سیٹ کی نمائندگی کرنے والے فائل ڈسکرپٹر کو منظم کرنے اور واپس کرنے کے لئے کس قسم کی رسائی ہے۔ landlock_add_rule ڈائرکٹری کی شکل میں ایک استثناء شامل کریں جسے آپ رکھنا چاہتے ہیں۔ آخر کار landlock_restrict_self کالنگ کے عمل کے لیے ہر چیز کو مستقل بنا دیتا ہے۔
کہ handled_access_fs رولسیٹ پراپرٹیز میں فیلڈز وہ ہیں جہاں لوگ اسے پیچھے کی طرف حاصل کرتے ہیں۔ یہ کیا اجازت دیتا ہے درج نہیں ہے۔ یہ فہرست کرتا ہے کہ رسائی کی وہ اقسام جن کے لیے یہ اصول سیٹ ذمہ دار ہے، اور اس فہرست میں موجود کسی بھی چیز کو کہیں بھی مسترد کر دیا جائے گا سوائے ان راستوں کے جنہیں آپ واضح طور پر شامل کرتے ہیں۔ اگر آپ پڑھنے کی رسائی کو ہینڈل کرتے ہیں، تو آپ پورے فائل سسٹم تک پڑھنے کی رسائی سے محروم ہوجائیں گے جب تک کہ آپ دوبارہ اصول شامل نہیں کرتے ہیں۔
پروگرام جو آپ کو محدود کرتے ہیں۔
یہاں پوری کہانی ہے:
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#define READ_RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR)
static int create_ruleset(const struct landlock_ruleset_attr *attr)
{ return syscall(__NR_landlock_create_ruleset, attr, sizeof(*attr), 0); }
static int add_rule(int fd, const struct landlock_path_beneath_attr *pb)
{ return syscall(__NR_landlock_add_rule, fd, LANDLOCK_RULE_PATH_BENEATH, pb, 0); }
static int restrict_self(int fd)
{ return syscall(__NR_landlock_restrict_self, fd, 0); }
static int allow_read(int ruleset_fd, const char *path)
{
struct landlock_path_beneath_attr pb = { .allowed_access = READ_RIGHTS };
int rc;
pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
if (pb.parent_fd < 0) { perror(path); return -1; }
rc = add_rule(ruleset_fd, &pb);
close(pb.parent_fd);
return rc;
}
static void try_read(const char *path)
{
int fd = open(path, O_RDONLY);
if (fd < 0)
printf(" read %-24s FAILED (%s)n", path, strerror(errno));
else
{ printf(" read %-24s okn", path); close(fd); }
}
int main(void)
{
struct landlock_ruleset_attr attr = { .handled_access_fs = READ_RIGHTS };
int ruleset_fd = create_ruleset(&attr);
if (ruleset_fd < 0) { perror("landlock_create_ruleset"); return 1; }
if (allow_read(ruleset_fd, "/etc") < 0) return 1;
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
if (restrict_self(ruleset_fd)) { perror("landlock_restrict_self"); return 1; }
close(ruleset_fd);
printf("with landlock, /etc allowed:n");
try_read("/etc/hostname");
try_read("/tmp/secret.txt");
return 0;
}
بنائیں اور چلائیں۔
gcc -Wall -o sandbox sandbox.c
echo "hunter2" > /tmp/secret.txt
./sandbox
with landlock, /etc allowed:
read /etc/hostname ok
read /tmp/secret.txt FAILED (Permission denied)
دو تفصیلات اہم ہیں۔ قواعد پاتھ سٹرنگز کے بجائے اوپن فائل ڈسکرپٹرز کے ذریعے ڈائریکٹریز کا حوالہ دیتے ہیں۔ O_PATH لہذا آپ ایک ہینڈل حاصل کرسکتے ہیں یہاں تک کہ اگر آپ کے پاس ڈائرکٹری میں ہی پڑھنے کی اجازت نہیں ہے۔ اور restrict_self یہ کال کرنے کے عمل کے لیے فوری طور پر نافذ ہوتا ہے اور اسے کالعدم نہیں کیا جا سکتا۔
کیوں no_new_privs درکار ہے۔
لے لو۔ prctl کال کرنے پر پروگرام کام کرنا بند کر دیتا ہے۔
landlock_restrict_self -> Operation not permitted
کہ EPERMاور یہ جان بوجھ کر ہے۔ PR_SET_NO_NEW_PRIVS دانا کو بتاتا ہے کہ یہ عمل اور اس کی اولاد کبھی بھی اس کے ذریعے مراعات حاصل نہیں کر سکتی: execveیہ سیٹوئڈ بائنریز چلا کر سینڈ باکس کے عمل کو فرار ہونے سے روکنا ہے۔
اس ضمانت کے بغیر، محدود عمل چل سکتے ہیں۔ sudo متبادل طور پر، ہم نے ابھی جو پابندیاں لگائی ہیں ان سے آزاد ہونے کے لیے ایک سیٹوئڈ پروگرام استعمال کریں۔ لینڈ لاک خود کو لاگو کرنے سے انکار کرتا ہے، بجائے اس میں سوراخ کے ساتھ ایک سینڈ باکس فراہم کرتا ہے۔ سیٹ no_new_privs سب سے پہلے، ہر بار.
اصول ایک دوسرے کو آپس میں جوڑتے ہیں لیکن کبھی توسیع نہیں کرتے
یہ وہ پراپرٹیز ہیں جو آپ کو ملتی ہیں۔ ایک اصول سیٹ لاگو کریں جو اجازت دیتا ہے: /etcپھر دوسرا الاؤنس لگائیں۔ /tmpاس بارے میں پوچھیں کہ آپ کس تک پہنچ سکتے ہیں۔
after first ruleset: /etc=ok /tmp=Permission denied
after second ruleset: /etc=Permission denied /tmp=Permission denied
دوسرا اصول سیٹ شامل نہیں کیا گیا ہے۔ /tmp. اسے لے گیا /etcاور تمہارے لیے کچھ نہیں بچا۔
ہر ایک restrict_self یہ پہلے سے لاگو ہونے والی ہر چیز کو جوڑتا ہے۔ قوانین کے پہلے سیٹ کی اجازت ہے۔ /etc اور باقی انکاری تھے۔ دوسری کی اجازت ہے /tmp اور باقیوں نے انکار کیا۔ جو بچتا ہے وہ ان دونوں کا ملاپ ہے، یعنی خالی پن۔
لہذا لینڈ لاک سینڈ باکس شافٹ ہے۔ کوئی بھی ایپلیکیشن صرف سخت کر سکتی ہے، ڈھیلی نہیں، اور کہیں بھی کوئی API آپریشنز نہیں ہیں جو ایک محدود عمل کر سکتا ہے۔ اگر کسی عمل کے لیے دو ڈائریکٹریوں تک رسائی درکار ہوتی ہے، تو دونوں اصولوں کو لاگو کرنے سے پہلے ایک اصول میں شامل کیا جاتا ہے۔
اس کا مطلب یہ بھی ہے کہ آپ اپنا خیال نہیں بدل سکتے۔ ایک طویل عرصے سے چلنے والا عمل جو شروع میں خود محدود ہوتا ہے، بعد میں یا تو خود یا دوسروں کی طرف سے نہیں دیا جا سکتا، جب تک کہ کوئی نیا عمل شروع نہ کیا جائے۔
جو آپ کے بچوں کو وراثت میں ملتا ہے۔
حدود میں شامل ہیں: fork بغیر پوچھے:
parent: /etc=ok /tmp/secret.txt=Permission denied
forked child: /etc=ok /tmp/secret.txt=Permission denied
بچے بالکل اپنے والدین کے لینڈ لاک ڈومین کے وارث ہوں گے اور اسے غیر چیک کرنے کے لیے کوئی جھنڈا نہیں ہوگا۔ ایک ہی بات پر لاگو ہوتا ہے۔ execveیہ نقطہ ہے no_new_privs: نیا پروگرام پہلے سے ہی پچھلے پروگرام کے قائم کردہ سینڈ باکس کے اندر شروع ہوتا ہے۔
یہ وہ چیز ہے جو لینڈ لاک کو غیر تحریری مواد کی پیکنگ کے لیے مفید بناتی ہے۔ اگر آپ اپنے آپ کو محدود کرتے ہیں اور پھر اس پر عمل کرتے ہیں جس کو آپ شامل کرنا چاہتے ہیں، تو آپ یہ جانے بغیر کہ حدود موجود ہیں حدود کے اندر چلیں گے۔
کہ exec جال
ہم نے بھی جال بچھائے۔ اوپر والے پروگرام کو لے لیں۔ /etc اسے اجازت دیں اور کچھ بھی کرنے کی کوشش کریں۔
allowed: /etc
execl(/usr/bin/cat) failed: Permission denied
بائنری چلانے کے لیے آپ کو اسے پڑھنا ہوگا۔ یہ اصول سیٹ درج ذیل کو سنبھالتا ہے: LANDLOCK_ACCESS_FS_READ_FILEتو دانا چیک کرتا ہے: /usr/bin/cat آپ اسے پڑھ سکتے ہیں، لیکن اس کے بارے میں کوئی اصول نہیں ہیں۔ /usrپروگرام شروع ہونے سے پہلے مسترد کر دیں۔
شامل کریں /usr اگر آپ اسے اسی اصول پر لاگو کرتے ہیں تو یہ کام کرے گا۔
allowed: /etc and /usr
devils-dell
عام سبق یہ ہے کہ آپ کے لینڈ لاک سینڈ باکس میں آپ کے عمل سے متعلقہ ہر چیز پر مشتمل ہونا چاہیے، اور وہ سیٹ آپ کے خیال سے بڑا ہے۔ بائنری، اس کا مترجم، کوئی بھی مشترکہ لائبریریاں جو لوڈ کی گئی ہیں، اور کوئی بھی ترتیب جو شروع میں پڑھی جاتی ہے۔ ldd بائنریز فہرستوں کے ساتھ شروع کرنے کے لیے ایک اچھی جگہ ہیں۔
ایسا پروگرام لپیٹنا جو آپ نے نہیں لکھا
جانشینی exec یہ وہی ہے جو لینڈ لاک کو آپ کے اپنے کوڈ سے آگے مفید بناتا ہے۔ اگر آپ خود کو محدود کرتے ہیں اور پھر جو کچھ بھی آپ شامل کرنا چاہتے ہیں اسے چلاتے ہیں، یہ آپ کے تعاون یا جانے بغیر سینڈ باکس کے اندر چلے گا۔
دستیاب ریپرز کو مندرجہ بالا پروگرام میں شامل کرنے کی ضرورت ہے۔ ہینڈل LANDLOCK_ACCESS_FS_EXECUTE پڑھنے کی اجازت کے ساتھ سسٹم ڈائرکٹری میں درکار بائنریز کی اجازت دیں، پھر صارف کی طرف سے درخواست کردہ ورکنگ ڈائرکٹری کی اجازت دیں۔
#define RIGHTS (LANDLOCK_ACCESS_FS_READ_FILE | LANDLOCK_ACCESS_FS_READ_DIR |
LANDLOCK_ACCESS_FS_EXECUTE)
static int add_path(int ruleset_fd, const char *path)
{
struct landlock_path_beneath_attr pb = { .allowed_access = RIGHTS };
int rc;
pb.parent_fd = open(path, O_PATH | O_CLOEXEC);
if (pb.parent_fd < 0)
return -1;
rc = syscall(__NR_landlock_add_rule, ruleset_fd,
LANDLOCK_RULE_PATH_BENEATH, &pb, 0);
close(pb.parent_fd);
return rc;
}
int main(int argc, char **argv)
{
struct landlock_ruleset_attr attr = { .handled_access_fs = RIGHTS };
const char *base[] = { "/usr", "/lib", "/lib64", "/bin", "/etc" };
int fd, i;
if (argc < 3) { fprintf(stderr, "usage: %s DIR CMD...n", argv[0]); return 2; }
fd = syscall(__NR_landlock_create_ruleset, &attr, sizeof(attr), 0);
if (fd < 0) { perror("create_ruleset"); return 1; }
for (i = 0; i < (int)(sizeof(base) / sizeof(*base)); i++)
add_path(fd, base[i]);
if (add_path(fd, argv[1]) < 0) { perror(argv[1]); return 1; }
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("prctl"); return 1; }
if (syscall(__NR_landlock_restrict_self, fd, 0)) { perror("restrict_self"); return 1; }
close(fd);
execvp(argv[2], &argv[2]);
fprintf(stderr, "%s: %sn", argv[2], strerror(errno));
return 1;
}
لوپ کیا نظر انداز کرتا ہے add_path واپس آتا ہے، تو وہی بائنری آپ کے سسٹم پر کام کرے گی۔ /lib64 یا /bin یہ یا تو موجود نہیں ہے یا علامتی طور پر کہیں اور جڑا ہوا ہے۔ صارف کے نام کی ڈائرکٹری کی جانچ پڑتال کی گئی ہے کیونکہ بعد میں ایک الجھن زدہ مسترد کرنے کے بجائے اب ایک خرابی واقع ہونی چاہئے۔
اب cat اور ls آپ صرف ورکنگ ڈائرکٹری دیکھ سکتے ہیں اور کچھ نہیں۔
mkdir -p /tmp/work && echo "project data" > /tmp/work/notes.txt
./llrun /tmp/work cat /tmp/work/notes.txt
./llrun /tmp/work cat /tmp/secret.txt
./llrun /tmp/work ls /home
project data
cat: /tmp/secret.txt: Permission denied
ls: cannot open directory '/home': Permission denied
نہ ہی پروگرام میں ترمیم کی گئی تھی، نہ دوبارہ مرتب کی گئی تھی، نہ ہی رضامندی کی درخواست کی گئی تھی۔ bwrap اسی طرح کے ٹولز پروگرام کے ارد گرد ماؤنٹس اور صارف کے نام کی جگہیں بنا کر اس نتیجے تک پہنچتے ہیں۔ یہ تقریباً 60 لائنوں پر ایک LSM کے لیے کم رقم مانگ کر حاصل کیا جاتا ہے جس میں انسٹال کرنے کے لیے کچھ بھی نہیں ہے۔
وہ راستہ تلاش کریں جس کی آپ کے پروگرام کی ضرورت ہے۔
سینڈ باکسز کے بارے میں مشکل حصہ API نہیں ہے۔ یہ ایک فہرست ہے۔ پروگرام توقع سے زیادہ کثرت سے کھلتا ہے، اور بھولے ہوئے راستے عملدرآمد کے دوران کہیں ناکامیوں کے طور پر ظاہر ہوتے ہیں۔
دو ٹولز فہرست بناتے ہیں: ldd ایک مشترکہ لائبریری فراہم کرتا ہے جسے پڑھنے کے قابل ہونا چاہیے ورنہ پروگرام شروع نہیں ہوگا۔
ldd /usr/bin/cat
linux-vdso.so.1 (0x00007fff85f39000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4f61bb5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4f61e0a000)
strace باقی سب کچھ فراہم کرتا ہے۔ سب سے پہلے، پروگرام کو بغیر کسی پابندی کے چلائیں اور جو کھلتا ہے اسے جمع کریں۔
strace -e trace=openat cat /etc/hostname 2>&1 | grep -oE '"/[^"]+"' | sort -u
"/etc/hostname"
"/etc/ld.so.cache"
"/lib/x86_64-linux-gnu/libc.so.6"
"/usr/lib/locale/locale-archive"
ایک پروگرام کے چار راستے ہیں جو ایک فائل کو پرنٹ کرتا ہے، جن میں سے صرف ایک درخواست کردہ فائل ہے۔ لنکر کیشے، سی لائبریری، اور لوکیل آرکائیوز سبھی کی ضرورت ہے اور اس لیے ریپر کے ذریعے اجازت دی جاتی ہے۔ /usr، /lib اور /etc اپنی پسند کی اجازت دینے سے پہلے۔
ایک بار محدود، strace یہ آپ کو یہ بھی بتاتا ہے کہ مسترد کیا ہوتا ہے۔
strace -f -e trace=openat ./llrun /tmp/work cat /tmp/secret.txt 2>&1 | grep EACCES
openat(AT_FDCWD, "/tmp/secret.txt", O_RDONLY) = -1 EACCES (Permission denied)
یہی لوپ ہے۔ بھاگو اور پڑھو۔ EACCES اس بات کا تعین کریں کہ آیا قطار میں کوئی راستہ اصول سیٹ کے اندر آتا ہے یا پروگرام کو اس راستے تک نہیں پہنچنا چاہیے، پھر دہرائیں۔ لینڈ لاک خود اس دانا پر کچھ نہیں لکھتا، لہذا strace یہ ڈیبگر ہے۔ 6.15 میں دانا آڈٹ سب سسٹم کے ذریعے مسترد ہونے کی اطلاع دیتا ہے، لہذا غیر موجود لاگز کو تلاش کرنے سے پہلے اپنا ورژن چیک کریں۔
ABI ورژن استعمال میں ہے۔
لینڈ لاک 5.13 کے بعد سے بڑھ گیا ہے، لہذا آپ جن خصوصیات کے بارے میں پڑھتے ہیں وہ آپ کے دانا میں نہیں ہوسکتی ہیں۔ براہ راست پوچھیں:
int v = syscall(__NR_landlock_create_ruleset, NULL, 0,
LANDLOCK_CREATE_RULESET_VERSION);
یہ مشین رپورٹ کرتی ہے۔ 1یہ 5.13 کا اصل ورژن ہے اور 13 فائل سسٹم تک رسائی فراہم کرتا ہے۔
grep -oE "LANDLOCK_ACCESS_FS_[A-Z_]+" /usr/include/linux/landlock.h | sort -u
LANDLOCK_ACCESS_FS_EXECUTE LANDLOCK_ACCESS_FS_MAKE_BLOCK
LANDLOCK_ACCESS_FS_MAKE_CHAR LANDLOCK_ACCESS_FS_MAKE_DIR
LANDLOCK_ACCESS_FS_MAKE_FIFO LANDLOCK_ACCESS_FS_MAKE_REG
LANDLOCK_ACCESS_FS_MAKE_SOCK LANDLOCK_ACCESS_FS_MAKE_SYM
LANDLOCK_ACCESS_FS_READ_DIR LANDLOCK_ACCESS_FS_READ_FILE
LANDLOCK_ACCESS_FS_REMOVE_DIR LANDLOCK_ACCESS_FS_REMOVE_FILE
LANDLOCK_ACCESS_FS_WRITE_FILE
تازہ ترین ورژن فائل پیرنٹنگ، تراشنا، TCP بائنڈنگز اور کنکشنز، اور ڈیوائس ioctls کا احاطہ کرنے والے نیٹ ورک کے اصولوں کے لیے کنٹرولز کا اضافہ کرتا ہے۔ ہر ایک اپنے اپنے ABI ٹکرانے سے ٹکراتا ہے، لہذا نئی اجازتوں کے خواہشمند پروگراموں کو استفسار کرنے اور ورژن کو فرض کرنے کی بجائے کارکردگی کو قربان کرنا پڑے گا۔ چلانے والا دانا اس بات کے لیے اجازتیں پاس کرتا ہے کہ اسے اس کے بارے میں معلوم نہیں ہے۔ landlock_create_ruleset ناکام EINVALاگر آپ پہلے ورژن کو چیک نہیں کرتے ہیں تو ڈیبگ کرنے کے لیے یہ ایک مبہم غلطی ہے۔
نتیجہ
اب آپ بغیر کسی اجازت یا ترتیب کے اندر سے کسی عمل کو سینڈ باکس کر سکتے ہیں، اور آپ نے چار حیران کن چیزیں سیکھی ہیں: no_new_privs پہلے آتا ہے یا کچھ بھی لاگو نہیں ہوتا ہے۔ اصول سیٹ جمع نہیں ہوتے بلکہ ایک دوسرے کو آپس میں جوڑتے ہیں، اس لیے ایک اصول سیٹ بنائیں جس میں سب کچھ ہو۔ بچوں کی خصوصیات وراثت سے ہوتی ہیں۔ اور پڑھنے کی حد ٹوٹ گئی ہے۔ exec جب تک بائنری راستوں کی بھی اجازت نہ ہو۔
آپ یہاں سے چند سمت جا سکتے ہیں۔ شامل کریں LANDLOCK_ACCESS_FS_WRITE_FILE کو handled_access_fs ایک ایسا پروگرام بنائیں جو بڑے پیمانے پر پڑھ سکے، لیکن صرف ایک ڈائرکٹری میں لکھ سکے۔ اپنے آپ کو محدود کریں اور پھر اس پروگرام کو لپیٹنے کے لیے کال کریں جسے آپ نے نہیں لکھا۔ execve. یا دیکھیں کیا ہوتا ہے۔ strace مستردوں کی اطلاع دینا ان راستوں کی فہرست بنانے کا تیز ترین طریقہ ہے جن کی آپ کے حقیقی پروگرام کو درحقیقت ضرورت ہے۔
ایپیلاگ
لینڈ لاک کے بارے میں دلچسپ سوال یہ نہیں ہے کہ یہ کیا کرتا ہے۔ یہ ایسی چیز ہے جس کا اظہار نہیں کیا جا سکتا۔ قواعد سیٹ ایک راستے کا نام دیتا ہے، لہذا اجازت یونٹ فائل سسٹم پر ایک مقام ہے بجائے اس کے کہ صارف کی طرف سے پاس کردہ مخصوص فائل۔ میں آپ کو بتا سکتا ہوں کہ اس عمل کو نیچے پڑھا جا سکتا ہے۔ /etc. اس کا مطلب یہ نہیں ہے کہ یہ عمل صرف ایک فائل کو پڑھ سکتا ہے جسے صارف نے ابھی منتخب کیا ہے اور دوسری نہیں۔
وہ خلا ہے جہاں میں نے آخری بار ایک ڈیسک ٹاپ OS بنانے میں اپنا وقت صرف کیا تھا جس میں ایسی خصوصیات کی حمایت کی گئی تھی جہاں اجازتیں مقام کے بارے میں قواعد کے بجائے ایک آبجیکٹ کے ہینڈل کے طور پر پہنچی تھیں، اور ڈیبین ماحولیاتی نظام اب بھی اس کے نیچے کام کرتا ہے۔ لینڈ لاک بہت ساری چیزیں کرتا ہے، اور جہاں لینڈ لاک رک جاتا ہے وہیں ڈیزائن دلچسپ ہو جاتا ہے۔
میں نظام اور اس کے اسرار کے بارے میں thechris.in پر لکھتا ہوں۔