Archive for the ‘Код и программистское’ Category

Пуленепробиваемая система.

Четверг, Октябрь 29th, 2009

Как и подобает каждому приличному секуритяну, я задумываюсь иногда о большом, белом и добром — об абсолютной защите от уязвимостей. То есть, какая должна быть система, чтобы с математической точки зрения к ней нельзя было сделать exploit’ы. Сразу оговорюсь, мы говорим именно о технической стороне, а не о social engineering’е, когда человек сам отдает ключи от квартиры, где лежат деньги.

А кстати, навеяло это мне то, что блог взломали и поместили невидимые линки на какой-то сайт с рекламой всякого хлама. Забавно, что жил на старинном WordPress 2.3 больше года и не был взломан. Стоило перейти на распоследний 2.8.5 c Security updat’ами и не прошло и недели, как взломали. Но, это, так… к делу не относится.

Так вот. в своих раздумьях по поводу абсолютной защиты, все что я смог придумать это — полное разделение кода и данных. То есть не должно быть ни одного места, где они перемешаны. Один из самых распространенных видов уязвимостей — переполнение буфера как раз основан на том, что сначала путем переполнения мы гадим в стек и вызываем переход на тот адрес, который мы хотим, например на другой загаженный кусок. Соответственно, если адресация команд отделена от адресации данных, то данные никак не будут исполнены как команды.

Вероятнее всего, имеет смысл даже более жестко вводить разделение. Вообще, управление программой не должно быть возможно с помощью «сырых» данных. То есть, все методы условного и безусловного ветвления могут работают только на основе того, что храниться в флагах или коде. А уж только флаги в свою очередь могут быть выставлены какими-то операциями с обычными данными.

Так, что — долой архитектура фон Неймана и да здравствует архитектура Ронина (м… нужно какой-нибудь титул раздобыть).

Вторая идея, фактически продолжение первой — запрет всех интерпретируемых языков. Долой всякий SQL-injection. Увы, пока я не смог придумать, как с технической стороны можно ограничить возможность интерпретирования.

Увы, пока на этом мысль останавливаются.

Есть у кого-нибудь еще идеи и предложения по этому поводу?

P.S.1. Основная идея, не какой-то метод написания кода, который будет более стабильный, а система в которой потенциально нельзя написать код позволяющий сделать exploit. Понятно, что против SQL injection и buffer overflaw есть вполне четко описанные практики борьбы, весь вопрос, что программист должен об этом думать и может забыть/не знать и поэтому везде и есть куча дыр.

P.S.2. Отличная идея от Alex UK. Конечная state machine действительно хорошо справляется с поставленной задачей.

Маленькая развлекушка.

Понедельник, Октябрь 12th, 2009

Один сотрудник рассказал о интересном проекте, которым он занимается и меня ну ооочень заинтересовало это дело.

Сейчас (в разумной степени не за дорого) продается небольшая платка с простеньким перепрограммируемым процом и некоторым количеством цифровых и аналоговых выходов.

Что собирается сделать сотрудник, это подключить эту платку к пульту радиоуправления игрушечной машинки и написать программку, которая потом будет управлять машинкой. И я решил повторить тот же самый проект, так как руки активно чешутся сделать что-нибудь такое.

Так, что заказал платку, прикупил дешевую радиомашинку (с которой с удовольствием эдак с пол часика поигрался без всяких плат), купил паяльник и сейчас активно штудирую основы радиоэлектроники. Кстати, обнаружил, насколько все таки отличаются старые советские книжки по хобби отличаются от иностранных. Советские выглядят так, как будто идет подготовка по закидыванию в тыл противника, где из трех проводов и такой-то матери надо собрать передающую радиостанцию. В иностранных книжках много упора на фан. Я например нашел вот эту книжку выпущенную компанией RadioShack.

На выходных разобрал пульт управления, срисовал схему с него. Хотя куда подключать плату я разобрался быстро, но хочется все таки понять полностью принцип работы пульта, но увы пока понимания не хватает.

Кстати, если таки кто-то знает где можно почитать о том, как понимать, что же делает схема — был бы очень признателен. Обозначения я уже знаю, но абсолютно не понимаю,

В общем, сбылась мечта идиота — добрался таки до железячек.

Выложил фотки пульта радиоуправления в трех файлах: 1,2,3

Не давайте бензопилу детям.

Понедельник, Август 31st, 2009

Тут мы пообсуждали localstorm мою статью о CopyPaste. Ну и пришли к выводу, что да CopyPaste бывает полезен, но скорее для профессионалов, в тот момент когда люди понимают зачем и как его использовать.

Ну и по ходу у нас вышло вот такое обсуждение:

Victor>Поэтому я и говорю, что безусловно есть применению копированию, но для серьезного большинства малоопытных программистов (и тех кто их окружает) — это абсолютное зло.

localstorm>, у меня нет другого решения проблемы неопытных программистов, кроме как начать давать им реальные задачи, показывать, где они не правы и просить больше так не делать. 🙂 Не станешь же думать, что вот, этот чувак не опытный, надо у него отобрать отвёртку и напильник, а то покалечит нашу систему 🙂

Я полностью согласен о том, что единственный метод обучить — это работать с ними, показывая хорошие решения и объясняя почему плохие решения плохие. Но я не согласен, что отбирание напильника (или бензопилы) такая уж плохая идея.

Сначала небольшая аналогия, а потом к делу. Представим себе, что у нас есть Linux машина и мы всем раздаем root права. И администратор говорит, ну что же поделаешь, что пользователи могут к черту все системы разнести, я приду починю, пожурю, объясню в следующий раз как надо и как не надо делать.

Так вот, как-то так уже сложилось, что в среде программистов какое-то уж совсем нездоровое равенство. Все имеет право использовать весь набор инструментов.

Так вот, я выступаю за то, чтобы разграничить права на использование инструментов, как разграничены права пользования в Linux. Условно говоря, главный программист может делать любые действия. Средний программист не имеет права изменения критических существующих интерфейсов и ядра системы. Младший программист не имеет правда добавления новых файлов, copypaste и т.п. Еще раз… Это всего лишь пример. У меня сейчас нет в кармане полного списка прав и как все разделить и разграничивать.

Естественно задача проблемного кода решается даже без введения ограничения на инструментарий путем review кода до сommit’а его в SVN. Но даже на этом уровне, получается, что доступ к более опасным tool’ам будет съедать время главного программиста, так как ему придется объяснять, что Вася, не бери бензопилу, не меняй интерфейсы в классах.

Но, все таки гораздо удобнее было бы таки, по мере роста программиста позволять пользоваться более широким инструментарием. Опять же, это упростило бы работу самого программиста тоже. Когда у него есть всего 10 методов работы с кодом, а не 100, их будет гораздо легче освоить и использовать корректно.

Да, кстати, localstorm пишет в своем ЖЖ о управление проектами, программировании и других IT радостях жизни. Рекомендую почитать — хорошие и взвешенные мысли.

P.S. В многих комментариях проскочила одна и та же мысль. Можно же откатиться по системе контроля, так что ничего страшного. Я согласен, что откат уменьшает в десятки раз нанесенный ущерб. Но! Пусть нам нужно скажем сделать какой-то модуль. Мы можем это сделать двумя методами — даем неопытному его дизайн, он его делает плохо, мы объясняем как делать хорошо, он переделывает. Или мы сначала объяняем как делать хорошо и он сразу делает хорошо. Второй путь по большему счету более эффективный (с точки зрения компании).  Замечу, «откатить» плохой дизайн мы можем мгновенно, но дизайн все равно придется второй раз делать.  Поэтому, когда мы заранее знаем где лежат грабли, имеет смысл действовать проактивно, то есть решать проблему ДО того, когда она стукнула тебя по голове.

Copy/paste и закомментированный код.

Пятница, Август 14th, 2009

Две мысли в голове. Одна моя, другая позаимствованная.

С бейсбольной битой в руках разыскивается тот человек который первый в IDE добавил возможность copy/paste. Блин, жили бы, горя не знали, если бы не эта зараза.

Вторая мысль более длинная. Терпеть не могу, когда кто-то закомментирует код и добавляет комментарий. Исправление бага номер такой-то. Если код не нужен, то почему бы его не удалить вообще, если он таки может быть нужен, так может написать почему его оставили. Ну и плюс, лезешь — ищешь этот баг, потом лезешь смотреть изменение целиком относительно этого бага и все эта беготня в результате, чтобы удалить 4 строки мазолящие глаза.