From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <000501c3ba7b$03cbaf90$030ba8c0@kgpi> From: "Anton V. Denisov" To: Date: Thu, 4 Dec 2003 15:26:39 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Return-Path: fire@kgpu.kamchatka.ru X-MDaemon-Deliver-To: devel@altlinux.ru Subject: [devel] Q: hiding security sensitive info X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2003 04:01:58 -0000 Archived-At: List-Archive: List-Post: Приветствую всех. Прошу прощения за отступление от тематики данного списка рассылки, но altlinux-security@ у нас пока нет. Возник у меня следующий вопрос: как непривилегированный пользователь может получить список пользователей, вошедших в систему? Предполагается, что доступа к /usr/bin/{w,who} у пользователя нет. Также он не может скомпилировать и выполнить на хосте свою программу, но может загрузить её на хост уже в скомпилированном виде. Это подразумевает, что у пользователя есть доступ на запись к некоторым каталогам, которые находятся на разделе, смонтированном с параметром 'exec'. Прочитал ещё раз вопрос и понял - в этом случае ничто не помешает загрузить на хост и запустить статически слинкованный бинарник who. Но это значительно усложнит жизнь злоумышленнику. Особенно если доступа к средствам загрузки тоже нет. Данный вопрос можно распространить на информацию, выдаваемую следующими утилитами: dmesg, mount, netstat, ps, uname, df, free, last, lastlog, id, groups, pstree, quota, fdisk, chkconfig, lsmod, ifconfig, ip, route и многими других. С помощью этих и других утилит пользователь может получить довольно много информации о системе, поэтому я бы для себя поставил их на control(8), но в этом не будет смысла, если пользователь сможет получить эту информацию другими путями - про это и был мой первоначальный вопрос. Openwall Linux Kernel Patch несколько улучшает ситуацию, защищая /proc, но этого явно недостаточно. Помню нашёл на одном web сервер дырявый cgi скрипт, который позволял выполнять системные команды. Выполнил id, чтобы узнать что, я nobody (это и предполагалось), потом who, а потом отослал /etc/passwd админу сервера (я его знал :-)). Так вот хочется защититься от подобных вещей. Если бы у пользователя nobody изначально не было прав запускать что-либо из $PATH, то мне бы пришлось гораздо труднее в данном случае. Конечно, когда пользователи имеют удалённый доступ и полноценный shell, то такую защиту применить труднее. Но меня больше интересует случай использования аккаунта непривилегированного пользователя, полученного через удалённую уязвимость или как в случае описанном выше. P.S. Очень буду благодарен за ответ на это письмо или направление - куда читать.. Наверное я параноик :-][ P.P.S. Что лучше почитать про систему kernel capabilities? -- With best regards, Anton V. Denisov. In silent deep without hope. '-- MARK --' is my favourite log-entry.