Наскільки ми можемо розраховувати на дозволи файлової системи для безпеки?


31

Моє запитання стосується дозволів файлової системи (зокрема дозволів у стилі Unix) та того, як вони стосуються безпеки.

Скажіть, у мене є доступ до комп'ютера з обліковим записом гостя та користувачем на ім’я Боб. Я не знаю пароль Боба, але я можу використовувати обліковий запис гостя. В обліковому записі гостя абсолютно немає дозволу на читання для всіх файлів Боба, тому я не можу читати жодного з файлів Боба під час входу в систему як гість.

Однак з точки зору справжнього "противника" я маю повний доступ до цього незашифрованого диска. Я міг би зобразити його, зберегти його на потім, запустити якусь іншу ОС, щоб просто прочитати файли Боба, ігноруючи параметри дозволу файлової системи.

З цього я переходжу до питання:

  1. Налаштування дозволу на файлові системи на незашифрованому диску - це лише прапор, правда? І єдине, що перешкоджає мені читати файли, на які я не маю дозволу, - це те, що ОС скаже "О, ти не можеш цього прочитати, ти не маєш дозволу". Цей файл все ще знаходиться на диску в сирому вигляді, і я міг прочитати це, просто ігноруючи прапори файлової системи (скажімо, через якусь тінисту завантажувальну ОС, яка просто ігнорує дозволи). Це все правильно?

Тепер скажіть, що я не маю прямого доступу до диска, і я просто втечу в машину. Я не маю дозволу читати будь-які файли Боба. Я насправді з цим нічого не можу зробити, правда?

  1. Враховуючи мої обмежені дозволи, я просто не можу отримати доступ до файлів Боба, як би я не намагався, ні? Що робити, якщо я використовую деякий подвиг для отримання доступу до кореня? Чи можу я тепер обійти прапори дозволу ОС? Це те, що коли-небудь трапляється?

4
так і так. ви, здається, правильно розумієте пов'язані з цим поняття. Для обходу дозволів, якщо ви не можете отримати фізичний доступ до системи, буде потрібна ескалація приватної атаки.
Френк Томас

2
Чи не було б гарною ідеєю перенести це на Security.SE ? Здається, це більш логічне місце для цього.
Chris Cirefice

3
@ChrisCirefice Більш глибоке заглиблення в концепцію безпеки може бути міграцією. Але це дуже основне питання щодо розуміння дозволів файлової системи та їх конкретної ролі в концепції безпеки системи, тому це стосується цього Супер Користувача набагато більше.
JakeGould

Відповіді:


31

Коротша відповідь.

Якщо у вас є фізичний доступ до комп'ютерної системи - ПК або системи зберігання даних - і єдиний "захист" - це дозволи файлів, ви не маєте 100% захисту.

Ці незашифровані дані можна копіювати та клонувати з мінімальними зусиллями, майже не маючи інструментів, крім іншого пристрою, з яким можна підключитись до системного диска, щоб зробити копію даних.

І так, можливо, деякі фізичні доказові аспекти фізичного проникнення можуть потребувати врахування доступу на фізичному рівні; як, наприклад, переконайтеся, що не залишаються відбитки пальців, а також вирішуються будь-які печатки "очевидних підробок". Але, чесно кажучи, переважна більшість систем там можуть фізично видаляти свої накопичувачі для фізичної копії даних, і кінцевий користувач ніколи не знає нічого кращого. Якщо у вас накопичувач, у вас є накопичувач, а потім у вас є дані, якщо вони незашифровані.

Ось чому шифрування для кожного користувача або шифрування на повному диску - це сьогодні велика річ; ноутбуки та інші портативні обчислювальні пристрої є настільки великою частиною ринку, на сьогодні ризик втрати даних від крадіжки пристрою або випадкового запозичення ПК значно вищий, ніж це було раніше.

Якщо диск незашифрований, дані на ньому - це відкрита книга, готова до читання. Ця концепція не обмежується машинами Linux / Unix, а будь-якою ОС будь-де; якщо у вас є фізичний доступ до незашифрованої системи, у вас є система.

Однак, дозволи на файли є корисним заходом для віддалених серверів усіх типів.

Більш довга відповідь.

Моє запитання стосується дозволів файлової системи (зокрема дозволів у стилі Unix) та того, як вони стосуються безпеки.

По-перше, пам’ятайте про безпеку комп’ютерів - і все - це насправді просто стримуючий фактор, який уповільнює ситуацію і не обов'язково забезпечує абсолютну безпеку.

Наприклад, найслабший захист у будь-якій фізичній будівлі - це двері, які ви повинні відкрити під час входу / виходу з неї, або вікно, яке ви повинні відкрити, щоб пропускати повітря. Так, ви можете заблокувати двері та вікна та встановити тривогу, але якщо хтось справді хоче отримати доступ до чогось - і у них є час, ресурси, багатство та зусилля для його здійснення - вони отримають доступ до нього.

Скажіть, у мене є доступ до комп'ютера з обліковим записом гостя та користувачем на ім’я Боб. Я не знаю пароль Боба, але я можу використовувати обліковий запис гостя. В обліковому записі гостя абсолютно немає дозволу на читання для всіх файлів Боба, тому я не можу читати жодного з файлів Боба під час входу в систему як гість.

Тут питання - контекст доступу. Якщо у вас є фізичний доступ до комп'ютера, можливо майже все . Але якщо ви підключені лише через віддалене з'єднання - через якусь мережу - то володіння файловою системою, безумовно, є ефективним методом захисту. А у випадку з серверами Linux / Unix дозволи та права власності є ефективними формами безпеки для стримування віддаленого вторгнення.

Ось чому в світі Linux / Unix rootдоступ до віддаленої системи вважається таким великим призом. Перейдіть rootдо віддаленої системи, і тоді ви справді зробили щось, що надає вам більший доступ, не потрібно заходити в центр обробки даних і клонувати диск.

Однак з точки зору справжнього "противника" я маю повний доступ до цього незашифрованого диска. Я міг би зобразити його, зберегти його на потім, запустити якусь іншу ОС, щоб просто прочитати файли Боба, ігноруючи параметри дозволу файлової системи.

Так. Саме так. Якщо у вас є фізичний доступ до машини, то - як було пояснено на початку - всі ставки знімаються. Ви можете отримати доступ до файлів і каталогів, що належать іншим, зробивши зображення диска - або навіть просто переглянувши сирий вміст самого накопичувача - з невеликими та без особливих технічних зусиль.

Кожен, хто, наприклад, позичає вам свій персональний комп’ютер і налаштовує новий рахунок лише для вас, не замислюючись над цим сценарієм, в основному видає будь-які особисті дані, які вони мають на своїй машині, не знаючи цього.

Незначна дотична, але я думаю, саме тому так багато випадкових користувачів здають старі ПК, не докладаючи жодних зусиль, щоб стерти дані на диску. Вони встановлюють пароль користувача, і вони припускають, що вони захищали свої дані настільки, наскільки вони могли просто кинути накопичувач у смітник і не думати двічі. Якщо реальність не відповідає справжньому шифруванню або видаленню даних, будь-який привід, кинутий у смітник або проданий використаний, може просто читати будь-хто в будь-якій точці без особливих важких підйомів або глибоких технічних зусиль.


6
Я думаю, що ця відповідь пропускає щось досить очевидне, що варто згадати. Безпека - це не лише обчислювальна безпека. Моделі загрози теж мають значення, тому що нападники - це людина: зловмисники, як правило, хочуть уникати слідів. Якщо ви надаєте комусь фізичний доступ до пристрою, але ви робите це таким чином, що пристрій не може бути підроблений, не залишаючи сліду (що завгодно, від відбитків пальців до підробки маркерів до руйнування пристрою під час маніпуляції), він дійсно може збільшитися безпеку вашої системи, незважаючи на те, що дані є фізично доступними.
Мехрдад

@Mehrdad Цей коментар може мати сенс у більш широкому обговоренні безпеки та захисту від доступу, але це питання - і моя відповідна відповідь - зосереджені на загальних поняттях дозволів логічної файлової системи порівняно з базовим фізичним доступом до системи. І в цьому випадку ці побоювання щодо відбитків пальців та фальсифікаторів - це лише вигадка фантазійного сценарію. Якщо у людини є фізичний доступ до незашифрованих даних, вони мають фізичний доступ до незашифрованих даних, і 9 разів з 10 не повинні бути "головним злодієм / шпигуном", щоб отримати доступ до цих даних у цей момент.
JakeGould

15

Ваші три бали:

  1. Якщо ви входите в SSH як звичайний користувач, у вас немає доступу до необмеженого дискового пристрою. Зазвичай вам потрібен rootабо дозвіл на доступ до необмежених та логічних дискових пристроїв.

  2. Якщо ви отримуєте корінь за допомогою експлуатації, ви є найпотужнішим користувачем у системі та маєте доступ до більшості всього, включаючи пристрої. Оскільки ви root, ви можете безпосередньо отримувати доступ до файлів Боба, тому немає необхідності отримувати доступ до дискового пристрою.

  3. Фізичний доступ б'є root. Корінь - це логічний шар. Ви можете проігнорувати це за допомогою фізичного доступу до диска. Сюди входить завантаження згаданого диска в окрему ОС, де ви є root.

Звичайно, системи повинні бути загартовані проти rootподвигів, але нові подвиги виходять щодня. Жодна система не є на 100% захищеною, але ви можете зробити її безпечною для практичних цілей, обмеживши доступ.

Очікується, що дозволи файлової системи працюватимуть лише в ситуаціях з обмеженим доступом користувачів, де ОС не порушена. Це система "зберігати чесних (і типових) чесних користувачів", як замок для велосипедів. Він працює над тим, щоб запобігти "злочинам можливостей" більш ніж невдало забезпечити повний захист.


Правила дозволу FS досить надійні. Вони працюють до тих пір, поки жоден зловмисник не має кореня. Семантика файлової системи POSIX (і специфічні для Linux розширення) ретельно розроблені так, щоб не відкривати більше доступу, ніж можна отримати просто open(2). наприклад, linkat(2)дозволяє створити запис каталогу для дескриптора відкритого файлу, але лише якщо кількість посилань вже не дорівнює нулю, тому процес, який отримує відкритий FD для видаленого файлу, не може зв’язати його назад у файловій системі. Очевидно, що зловмисник отримує корінний або фізичний доступ - це означає, що ви тості. Шифрування допомагає фізичному, але не дуже кореневому.
Пітер Кордес
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.