লিনাক্সের জন্য কি কোনও এনক্রিপ্টযুক্ত লেখার জন্য কেবল ফাইল সিস্টেম রয়েছে?


14

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

লিনাক্স এ কি এমন একটি জিনিস বিদ্যমান? বা যদি তা না হয় তবে এনক্রিপ্ট হওয়া লগ ফাইলগুলি তৈরি করার সেরা বিকল্পটি কী হতে পারে?

আমার বর্তমান কাজের ভিত্তিতে কেবলমাত্র পাইপগুলির মাধ্যমে তথ্যগুলি পাইপ করা নিয়ে gpg --encryptকাজ করে যা কাজ করে তবে খুব জটিল, কারণ আপনি সহজেই সামগ্রিকভাবে ফাইল সিস্টেমটিতে অ্যাক্সেস পেতে পারবেন না, আপনাকে প্রতিটি ফাইল gpg --decryptম্যানুয়ালি পাইপ করতে হবে ।


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

আমি আরও একধাপ এগিয়ে যেতে চাই এবং ডেটা একেবারে অ্যাক্সেসযোগ্য না হয়ে কেবল এটি তৈরি করা প্রক্রিয়াতেই নয়, এমনকি রুট করতেও চাই না। জিপিজি সহ সর্বজনীন কী এনক্রিপশন এটি করে তবে আমি ফাইল সিস্টেম স্তরে এটি করার একটি উপায় অনুসন্ধান করছি।
গ্রুমবেল

উত্তর:


4

... আমি চাই সিস্টেমটি সম্পূর্ণরূপে আপস করা অবস্থায় থাকলেও ডেটা অ্যাক্সেসযোগ্য না হয়।

যদি সম্ভব না হয়. যদি সিস্টেমটি সম্পূর্ণরূপে আপস করে থাকে তবে "সংজ্ঞা দ্বারা" এতে যে কোনও কিছু অ্যাক্সেসযোগ্য - এনক্রিপশন কী সহ।

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

সিস্টেমের বাইরে আপনি যে ডেটাটি সুরক্ষিত করতে চান সেগুলি আপনাকে পাঠাতে হবে + যদি আপনি একেবারে রুটটি না পেতে চান তবে সেই সিস্টেমে কোনও মধ্যস্থতাকারী মাধ্যমটিতে এটি লিখবেন না। rsyslogলগিং সম্পর্কিত ক্ষেত্রে সুস্পষ্টভাবে এটিকে সমর্থন করে এবং আপনি ওপেনভিপিএন stunnel, বা এর অনুরূপ উত্স এবং সিঙ্কের মধ্যে সংযোগটি এনক্রিপ্ট করতে পারেন । আমি নিশ্চিত যে সেখানে অন্য "একমুখী" স্থানান্তর বিকল্প রয়েছে।


1
অনুগ্রহ করে পড়ুন en.wikipedia.org/wiki/Public-key_cryptography
rakslice

"কারণ ফাইল সিস্টেমটি ডিক্রিপ্ট করার জন্য তাদের র‌্যামে থাকতে হয়" এটি বিশেষত LUKS এর সাথে সত্য হতে পারে তবে সাধারণভাবে নয়: অসমমিতিক ক্রিপ্টো ঠিক সেই উদ্দেশ্যেই ডিজাইন করা হয়েছে (পাবলিক কী ধারণকারী কেউ এনক্রিপ্ট করতে পারে তবে ডিক্রিপ্ট নয়)
ক্লিমেন্ট

3

আমার কাছে মনে হচ্ছে আপনি ভুল পথে চলেছেন। আপনি যদি এমন কোনও ফাইল চান যা আপনি লিখতে পারেন, তবে পড়তে পারেন না, তবে ফাইল অনুমতি যা আপনি খুঁজছেন তা।


$ touch log
$ chmod 222 log
$ echo test > log
$ cat log
cat: log: Permission denied

অবশ্যই, এই ফাইলটি একটি এনক্রিপ্ট করা ফাইল সিস্টেমে থাকতে পারে।


আপনি প্রদত্ত উমাস্ক দিয়ে ফাইল সিস্টেমটি মাউন্ট করতে পারেন, ব্যবহারকারীদের অনুমতি পরিবর্তন করতে না দিয়ে।
নম্বর

এবং কেবলমাত্র ফাইলের মালিক (বা সুপারউজার) অনুমতি পরিবর্তন করতে পারেন।
গরিলা

আমি মনে করি ওপি কোনও আক্রমণকারীর শেকড় পাওয়ার থেকেও নিজেকে রক্ষা করার চেষ্টা করছে।
ক্লিমেট

1
umask 0477 && touch file && echo test > file && cat file

খুব দরকারী হতে পারে। বর্তমান প্রক্রিয়ার মধ্যে তৈরি যে কোনও ফাইলের 0200 মোড থাকবে।

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