এমন কোনও শেল আছে যা কোডটি স্বাক্ষরিত হয়েছে তা নিশ্চিত করে পরীক্ষা করে?


19

আমি এই সপ্তাহে পাওয়ারশেলের সাথে ঘোরাঘুরি করছি এবং আবিষ্কার করেছি যে আপনার স্ক্রিপ্টগুলিতে স্বাক্ষর করতে হবে যাতে সেগুলি চালানো যায়। লিনাক্সে কি এমন কোনও সুরক্ষিত কার্যকারিতা রয়েছে যা বাশ স্ক্রিপ্টগুলি চালানো থেকে রোধ করার সাথে সম্পর্কিত?

এর মতো কেবলমাত্র কার্যকারিতা, যে সম্পর্কে আমি সচেতন তা হ'ল এসএসএইচকে একটি নির্দিষ্ট কী প্রয়োজন।


2
আমার কাছে প্যাকেজ সাইন ইন করার জন্য কিছুটা অ্যাড-হক সমাধানের মতো মনে হচ্ছে। আমি জানি না যে উইন্ডোজে লিনাক্সের মতো ক্রিপ্টোগ্রাফিক প্যাকেজ স্বাক্ষর আছে কিনা।
ওয়াইল্ডকার্ড

6
@ leeand00 একটি স্ক্রিপ্ট একটি সফ্টওয়্যার প্যাকেজের একটি বিশেষ কেস এবং আমি এই কেসটিকে একত্রে দেখানোর কোনও বিন্দু দেখতে পাচ্ছি না।
গিলস 'অশুভ হওয়া বন্ধ করুন'

2
আমি যে পদ্ধতিটি সবচেয়ে বেশি পছন্দ করি তা হ'ল ChromeOS এটি করে noexec- কেবলমাত্র একটি ডিএম-ভার্টি স্বাক্ষরিত ব্লক ডিভাইসে কেবল পঠনযোগ্য পার্টিশনে ফ্ল্যাগযুক্ত না হওয়া ফাইল সিস্টেমকে রেখে দেওয়া।
চার্লস ডাফি

1
সোর্স.অ্যান্ড্রয়েড / সুরক্ষা / যাচাই করা বুট Android এর সেই (প্রাথমিকভাবে ChromeOS) বৈশিষ্ট্যটি গ্রহণ করার বিষয়ে কথা বলে।
চার্লস ডাফি

1
আপনি বাশকে কমান্ডগুলির একচ্ছত্র হিসাবে বিবেচনা করতে পারেন যা কমান্ড লাইন ইন্টারফেসে ম্যানুয়াল টাইপ করা যেতে পারে। আপনি যখনই কমান্ড লাইনে বিষয়বস্তু টাইপ করতে পারেন তখন স্ক্রিপ্টগুলিকে সীমাবদ্ধ করার বিষয়টি কী?
ডিং-ইয়ি চেন

উত্তর:


11

আপনি যদি স্ক্রিপ্টগুলি চালানোর জন্য ব্যবহারকারীর ক্ষমতাকে লক করে থাকেন sudoতবে আপনি digestকার্যকারিতাটি ব্যবহার করতে পারেন ।
আপনি কোনও স্ক্রিপ্ট / এক্সিকিউটেবলের হ্যাশ নির্দিষ্ট করতে পারেন sudoersযা sudoকার্যকর করার আগে যাচাই করা হবে । সাইন ইন করার মতো না হলেও এটি আপনাকে একটি প্রাথমিক গ্যারান্টি দেয় যে স্ক্রিপ্টটি কমপক্ষে sudoers এছাড়াও সংশোধন না করে পরিবর্তন করা হয়নি।

যদি একটি কমান্ডের নামটি একটি ডাইজেস্ট_স্পেকের সাথে উপসর্গ করা থাকে তবে নির্দিষ্ট SHA-2 ডাইজেস্ট ব্যবহার করে যাচাই করা গেলে কমান্ডটি কেবলমাত্র সাফল্যের সাথে মিলবে। এটি এমন পরিস্থিতিতে কার্যকর হতে পারে যেখানে ব্যবহারকারীকে অনুরোধ করা sudo কমান্ড বা এর মূল ডিরেক্টরিতে লেখার অ্যাক্সেস পায়। নিম্নলিখিত ডাইজেস্ট ফর্ম্যাটগুলি সমর্থিত: sha224, sha256, sha384 এবং sha512। স্ট্রিংটি হেক্স বা বেস 64 ফরম্যাটে নির্দিষ্ট করা যেতে পারে (বেস 64 আরও কমপ্যাক্ট)। ওপেনসেল, শসুম, শে 2২৪ সস, শা 256sum, sha384sum, sha512sum এর মতো হেক্স ফর্ম্যাটে SHA-2 হজম তৈরি করতে সক্ষম বেশ কয়েকটি ইউটিলিটি রয়েছে।

http://www.sudo.ws/man/1.8.13/sudoers.man.html


এসই লিনাক্স সম্পর্কে পড়া না করে এবং এটি সঠিকভাবে না করা পর্যন্ত এটি আমাকে ধরে রাখবে।
leeand00

13

হ্যা এবং না.

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

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

এমন কোনও বিশেষ ব্যবস্থা নেই যা সফ্টওয়্যার প্যাকেজগুলিকে একক করে যা একটি সফ্টওয়্যার প্যাকেজগুলির মধ্যে একটি একক স্ক্রিপ্ট নিয়ে থাকে যা দেশীয় নির্বাহযোগ্য, একটি ডেটা ফাইল বা একাধিক ফাইল সমন্বিত থাকে। তেমনি কোনও সাধারণ স্ক্রিপ্ট ইন্টারপ্রেটারের মধ্যে স্বাক্ষর যাচাইকরণও নির্মিত হয় না, কারণ কোনও সফ্টওয়্যার প্যাকেজ যাচাই করা কোনও স্ক্রিপ্ট চালানো থেকে সম্পূর্ণ orthogonal উদ্বেগ।

আমি মনে করি উইন্ডোজ তাদের উত্স সহ ফাইলগুলি টীকায়িত করে এবং এমন একটি ফাইল চালানোর জন্য ব্যবহারকারীর নিশ্চিতকরণ প্রয়োজন যা "স্থানীয়" এর পরিবর্তে "ডাউনলোড" হয়েছে file লিনাক্সে আসলে একই ধরণের ব্যবস্থা নেই। নিকটতম জিনিসটি হল এক্সিকিউশন অনুমতি: একটি ডাউনলোড করা ফাইলের এক্সিকিউশন অনুমতি নেই, ব্যবহারকারীর স্পষ্টরূপে এটি সক্ষম করতে হবে ( chmod +xকমান্ড লাইনে বা কোনও ফাইল ম্যানেজারের সমতুল্য ক্রিয়া)।


2
এফডব্লিউআইডাব্লু, এই পাওয়ারশেলের শীর্ষে কেবল স্বাক্ষরিত স্ক্রিপ্টগুলি সম্পাদন করতে (নীতি সেটিংস দ্বারা) কনফিগার করা যায় এবং এই নীতিটি কনফিগার করা যায় যাতে সমস্ত স্ক্রিপ্টগুলি স্বাক্ষর করতে হবে বা কেবল "দূরবর্তী উত্স" স্ক্রিপ্টগুলি, বা কোনও স্ক্রিপ্ট নেই। কী পরিচালনা এবং কেন্দ্রীয় নীতি পরিচালনার সাথে এটি কোনও এডি পরিবেশে সেরা কাজ করে। এটা তোলে করতে bypassed হতে :-)
স্টিফেন হ্যারিস

@ স্টেফেনহরিস আচ্ছা হ্যাঁ যদি আপনি এটি বাইপাসে সেট করেন ...
লীয়ানডে

@ লীয়ানড00 - স্পষ্টতই বেস64 এর এনকোডিংটি একটি বাইপাস হিসাবেও কাজ করে তবে আমি জানি না যে পাওয়ারশেলের নতুন সংস্করণগুলিতে এটি বন্ধ হয়েছে কিনা।
স্টিফেন হ্যারিস

1
@ leeand00 - কিছু মজাদার জন্য ডার্কোপরেটর. com/blog/2013/3/5/… দেখুন :-) মূলত কমান্ড লাইনে বেস 64 এনকোডড স্ক্রিপ্টটি প্যারামিটার হিসাবে পাস করুন :-) মোড়কের পক্ষে যথেষ্ট সহজ!
স্টিফেন হ্যারিস

2
SeLinux তাদের উত্স সহ ফাইলগুলি টীকা দেয়। এটি এর অন্যতম প্রধান প্রাঙ্গণ।
loa_in_

10

লিনাক্স ডিজিটাল স্বাক্ষরের উপর ভিত্তি করে ব্যাশ স্ক্রিপ্টগুলির সীমাবদ্ধ করার ক্ষমতা সরবরাহ করে না।

বাইনারি এক্সিকিউটেবলের অনুমোদনের বিষয়ে কিছু কাজ রয়েছে। তথ্যের জন্য https://lwn.net/Articles/488906/ দেখুন ।


কোনও হ্যাকির কাজের আশপাশে পরামর্শ না দিয়ে সরাসরি উত্তরের পক্ষে যান।
ব্যবহারকারী 394

8

এক কথায়, "না"।

লিনাক্স আসলে এক্সিকিউটেবল এবং স্ক্রিপ্টগুলির মধ্যে পার্থক্য করে না; #!শুরুতে একটি উপায় কার্নেল কি প্রোগ্রাম ইনপুট নির্ণয় করা চালানোর জন্য বলতে কিন্তু এটা একমাত্র উপায় একটি স্ক্রিপ্ট সম্পাদন করতে পারে না।

সুতরাং, উদাহরণস্বরূপ, যদি আমার কাছে স্ক্রিপ্ট থাকে

$ cat x
#!/bin/sh 
echo hello

তাহলে আমি কমান্ড দিয়ে এটি চালাতে পারি

$ ./x

এটি কার্নেলটিকে এটি ব্যবহার করে #!চালিত করতে এবং তার /bin/sh xপরিবর্তে কার্যকরভাবে চালিত করবে ।

তবে আমি এই বৈকল্পিকগুলির মধ্যেও চালাতে পারি :

$ sh ./x
$ bash ./x
$ cat x | sh
$ cat x | bash
$ sh < x

অথবা এমনকি

. ./x

এমনকি যদি কার্নেল execস্তরটিতে সাইন ইন করতে প্রয়োগ করার চেষ্টা করেও আমরা কেবলমাত্র পরামিতি হিসাবে স্ক্রিপ্টের সাহায্যে দোভাষী চালিয়ে এটি এড়াতে পারি।

এর অর্থ হ'ল স্বাক্ষরকারী কোডটি দোভাষীর মধ্যেই থাকতে হবে। এবং কোন ব্যবহারকারী স্বাক্ষরকারী প্রয়োগকারী কোড ছাড়া শেলটির নিজস্ব অনুলিপি তৈরি করতে বাধা দেবে ?

এর স্ট্যান্ডার্ড সমাধানটি সাইন ব্যবহার করা নয়, তবে বাধ্যতামূলক অ্যাক্সেস কন্ট্রোলগুলি (ম্যাক) ব্যবহার করার জন্য SELinux। ম্যাক সিস্টেমের সাহায্যে প্রতিটি ব্যবহারকারীকে স্তর সঞ্চালন ও সংক্রমণের জন্য ঠিক কী অনুমোদিত তা আপনি নির্দিষ্ট করতে পারবেন। সুতরাং, উদাহরণস্বরূপ, আপনি বলতে পারেন যে "সাধারণ ব্যবহারকারীরা যে কোনও কিছু চালাতে পারে তবে ওয়েব সার্ভার এবং সিজিআই প্রক্রিয়াগুলি কেবল /var/httpdডিরেক্টরি থেকে স্টাফ অ্যাক্সেস করতে পারে ; বাকি সমস্ত কিছুই প্রত্যাখ্যান করা হয়"।


1
This means that signing code would have to be in the interpreter itself. And what would stop a user from compiling their own copy of a shell without the signing enforcement code?কোনও স্বাক্ষরবিহীন এক্সিকিউটেবলের মৃত্যুদণ্ড কার্যকর না করার ফলে এটি করা যাবে, যদি ব্যবহারকারীটির স্বাক্ষর কী না থাকে। ইতিমধ্যে এর জন্য বিভিন্ন * নিক্স প্রকল্প রয়েছে।
আলজি

2

লিনাক্স ডিস্ট্রোসের সাধারণত gnupg থাকে । আমার কাছে এটির মতো শোনার মতো যা আপনি চান তা হ'ল একটি সরল ব্যাশের মোড়ক যা আর্গুমেন্টের স্ক্রিপ্টের বিপরীতে বিচ্ছিন্ন জিপিজি স্বাক্ষর পরীক্ষা করে এবং চেকটি সফল হলে কেবল স্ক্রিপ্টটি চালিয়ে যায়:

#!/bin/sh
gpgv2 $1.asc && bash "$@"

কেবলমাত্র এটিই উপস্থাপন করে না এমন একটি স্ক্রিপ্ট চালানো যা কেউ সবে তৈরি করেছে ... নিজেরাই ...
leeand00

2

তাত্ক্ষণিক মনে আসা পাল্টা প্রশ্নটি হ'ল "আপনি ব্যবহারকারীদের তারা যে প্রোগ্রামগুলি লিখেছেন তা চালানো থেকে কেন কখনও বাধা দিতে চান ? " বেশ কয়েকটি সম্ভাবনা রয়েছে:

  1. কে প্রথমে কোডটি রচনা করেছেন তা সনাক্ত করা আক্ষরিক অসম্ভব স্ক্রিপ্ট ফাইলটির মালিক হ'ল যে কেউ প্রকৃতপক্ষে সেই ফাইলটির বিষয়বস্তু সেভ করেছে সেখান থেকে নির্বিশেষে। সুতরাং স্বাক্ষর প্রয়োগ করা একটি নিশ্চিতকরণ ডায়লগ বাক্সের জটিল বিকল্প: "আপনি কি নিশ্চিত যে আপনি এটি করতে চান?" লিনাক্সে এই সমস্যার অংশটি স্বাক্ষরিত স্বাক্ষরিত প্যাকেজগুলির সাথে স্বচ্ছভাবে সমাধান করা হয় এবং ব্যবহারকারীদের ডিফল্টরূপে সীমিত অ্যাক্সেস রয়েছে তা দ্বারা হ্রাস করা হয়। ব্যবহারকারীর এটিও আশা করা যায় যে অন্যের কোড চালানো বিপজ্জনক হতে পারে *।
  2. একই শিরাতে স্ক্রিপ্টে স্বাক্ষর করা কোনও ফাইল সংরক্ষণের চেয়ে অনেক জটিল কাজ operation সর্বোত্তম ক্ষেত্রে এটি ব্যবহারকারীকে উপলব্ধি করতে প্ররোচিত করে যে তারা কোনও নথিতে স্বাক্ষর করার অনুরূপ কোনও ক্রিয়া করছে, এবং চালিয়ে যাওয়ার আগে এটি কী বলেছে তা খতিয়ে দেখা উচিত। সম্ভবত এটি ব্যবহারকারীকে স্ক্রিপ্টটি চালানোর অনুমতি দেওয়ার জন্য খুব ন্যূনতম প্রযুক্তিগত দক্ষতার বিষয়টি নিশ্চিত করে । সবচেয়ে খারাপ ক্ষেত্রে এটি তারা যা চায় তা চালানোর জন্য হুপের দীর্ঘ সিরিজের মধ্য দিয়ে ঝাঁপিয়ে পড়ার ইচ্ছাকে প্রদর্শন করে। প্রযুক্তিগত দক্ষতা লিনাক্স * তে ধরে নেওয়া হয়।
  3. সম্ভবত তাদের কমান্ড লাইনে ক্রমান্বয়ে কমান্ড টাইপ / আটকানোর সময় লোকেরা স্পষ্টতই দূষিত কোডটি সনাক্ত করবে likely সাধারণত অনাদি কিছু করার জন্য প্রয়োজনীয় কমান্ডের সিরিজের তুলনায় কপি করা এবং আটকানো বোঝানো প্লেটেক্সট স্নিপেটগুলি সাধারণত। ব্যবহারকারী সাবধানতার সাথে প্রতিটি লাইন আলাদাভাবে অনুলিপি করে কাস্ট করতে পারেন, কী ঘটেছিল তা বুঝতে পেরে। কোনও স্ক্রিপ্টের মাধ্যমে এটি ব্যবহারকারীর কোডের দিকে মোটেও নজর নেই। এটি দ্বাদশবার করার পরে স্বচ্ছলতার অতি সাধারণ ব্যয়ে স্বাক্ষরিত স্ক্রিপ্টগুলির একটি দরকারী অ্যাপ্লিকেশন হতে পারে।

* বেশি লোক লিনাক্স ব্যবহার শুরু করার সাথে সাথে এটি সম্ভবত কম এবং সত্য হয়ে উঠছে


1

সিস্টেমগুলি পৃথকভাবে বিকশিত হওয়ার কারণটি হ'ল লিনাক্সের 'এক্সিকিউটিভ' ফাইল বৈশিষ্ট্য রয়েছে এবং উইন্ডোজ এক্সিকিউটিভিটি নির্ধারণ করতে ফাইল এক্সটেনশন ব্যবহার করে।

সুতরাং উইন্ডোজে ব্যবহারকারীর একটি ".exe", ".bat", ".scr" এক্সটেনশান সহ কোনও ফাইল ডাউনলোড করার কৌশলটি সহজ, যা ডিফল্টরূপে লুকানো থাকবে । সেই ফাইলটিতে ডাবল-ক্লিক করা আপনাকে সালিসি কোড কার্যকর করতে দেয় give সুতরাং এই ঝুঁকি হ্রাস করতে উত্স ট্র্যাকিং এবং এক্সিকিউটেবল / স্ক্রিপ্ট স্বাক্ষরের একটি বৃহত প্রক্রিয়া নির্মিত হয়েছিল।

লিনাক্সে, আপনি ব্যবহারকারীর কাছে একটি ফাইল পেতে সক্ষম হতে পারেন, তবে আপনি সহজেই 'এক্সিকিউট' বিট সেট করতে বাধ্য করতে পারবেন না। অতিরিক্তভাবে, পুরো ফাইল সিস্টেমগুলি 'নোেক্সেক' তৈরি করা সম্ভব।

আপনি যে কোনও ক্ষেত্রে দোভাষীর সাহায্যে স্পষ্টভাবে স্ক্রিপ্ট চালাতে পারেন। আপনি রানটাইমের সময় শেল স্ক্রিপ্টগুলি তৈরি করতে এবং এগুলিকে "sh" তে পাইপ করতে পারেন, বা "sh -c" চালাতে পারেন।


0

কাস্টম অনুসারে, অনেক সংরক্ষণাগার প্রোগ্রাম অন্তর্ভুক্ত ফাইলগুলিতে এক্সিকিউট বিট সংরক্ষণ করে না। এটি স্বেচ্ছাচারী এক্সিকিউটেবলগুলি চালানো অসম্ভব করে তোলে। ভাল প্রায়.

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

যদিও এটি খুব বেশি নয়, এটি কেবলমাত্র কার্নেল এবং শেল দিয়ে * নিক্সে অবিশ্বস্ত এক্সিকিউটেবলগুলি চালানো প্রতিরোধকে কভার করে ।

যেমন আমি একটি মন্তব্যে উল্লেখ করেছি, সুরক্ষার আরও একটি স্তর রয়েছে SeLinux- যা নিয়মের একটি সেটের ভিত্তিতে ফাইলগুলির উত্সকে ট্র্যাক করে। একটি সেট আপ SeLinuxউদাহরণস্বরূপ, রুটকে ইন্টারনেট থেকে ডাউনলোড করা এক্সিকিউটেবল বিট সেট সহ একটি এক্সিকিউটেবল চালানোর অনুমতি দেয় না, এমনকি আপনি ফাইলটি অনুলিপি করে সরিয়ে ফেললেও। একটি নিয়ম যুক্ত করতে পারে যে এই জাতীয় ফাইলগুলি কেবলমাত্র অন্য বাইনারি দিয়ে চালানো যেতে পারে যা আপনার স্বাক্ষরটি যাচাই করবে, আপনার প্রশ্নে উল্লিখিত মত নয় unlike

সুতরাং, শেষ পর্যন্ত এটি সাধারণভাবে প্রাক-ইনস্টল করা সরঞ্জামগুলির কনফিগারেশনের বিষয়, এবং উত্তর হ্যাঁ


অনেক সংরক্ষণাগার প্রোগ্রাম অন্তর্ভুক্ত ফাইলগুলিতে বিট নির্বাহ করে না .. ঠিক আছে, যখন আপনি আসলে সংরক্ষণাগারটির জন্য এটি ব্যবহার করতে চান তখন এই ধরনের প্রতিবন্ধকতা। সৌভাগ্যবশত tar নেই বিট চালানো সংরক্ষণ।
pjc50

আপনি ব্যবহার করতে হবে tar -p উৎস
loa_in_

-p, --preserve-permissions, --same-permissionsমানে ফাইল অনুমতি সম্পর্কে তথ্য উত্তোলন (
সুপারিউজারের

না, আপনার পি-র দরকার নেই। ম্যান পেজটি কী বলেছে তা আমি দেখতে পাচ্ছি, তবে যা হয় তা তা নয়। touch permtest; chmod +x permtest; tar cf permtest.tar.gz permtest; rm permtest; tar xf permtest.tar.gz; ls -l permtest- এটি এখানে কার্যকর হয়, এবং আমি মূল নয়।
ডোমেন

আমি আমার উত্তরটি তখন উন্নত করার চেষ্টা করব।
loa_in_
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.