> Блин, чет не могу найти ядро в списке процессов (

У него есть аппаратная посылалка сигналов - на ней ещё "reset" написано.

>3. проверяю бывший рутовый баш: > >kill 4900 >bash: kill: (4900) - Нет такого процесса

если не ошибаюсь, так и должны быть и на уже пропатченой системе

Уязвимость в головах, а не в ядре

> есть комп под линухом для обученя в школе/уневере с юзверем student/guest
> и заходить на него по ssh можно только под этим юзверем. т.е. чтоб получить
> админу соответствующие права, ему нужно зайти под непривилегированным
> пользователем и через su получить рута.

Что, под ТЕМ ЖЕ САМЫМ? Дурак этот админ. Потому как любой школьник сможет
читать из соответствующего /dev/pts/N (да и писать -- тоже), спионерить
пароль, и делать все, чего его душа пожелает.

> набрать типа killall bash и кильнуть шелл, с которого зашел админ (юиды
> одинаковые, значит можно)

killall -- это самое безобидное, а вот если ptrace...

> а он, в свою очередь, кильнет все дочерние процессы, в т.ч. и su,
> который уже под рутом

А если б не убивал, то что, стало бы легче? После того, как грохнули
родительский процесс и все его сессию, su (и root'овый shell) становится
демоном. И что с него толку?

Таки в голове дырки

> Что касается суидной писалки, то k3b её родит в псевдотерминале,

На кой писалке SUID?

> k3b рождает писалку с euid root, дабы могуществом своим могла она основы
> компьютера потрясти и заставить своей воле повиноваться реалтаймово.

Не нужен для этого SUID. man getrlimit на предмет RLIMIT_RTPRIO.

> он командует k3b "отменить". и.. что теперь прикажете k3b делать?

в идеале: послать отмену по пайпу. в реале: kill(pid, 15) ;)

а вообще в идеале, рулят ACLи на сигналы, только в линуксах такого нет, а может и вообще нет, эт я толькочто придумал -). указал, например, что SIGUSRx -- все всем (или только от непосредственного родителя), а все остальные -- только от рута и между процессами того же юида. вот и прерывай запись по SIGUSR1...

> >я баян :) > Дожили... anonymous

дык все анонимусы - сплошные баянчеги :)

Ты полгода как с винды что ли? :) Вроде нет, зарегистрирован давно. Всю жизнь cdrecord был суицидным, только вот недавно это стало ненужно.

exploit'ов не будет.

> Что-то я не смог придумать, как это использовать хоть для чего-нибудь.

Боюсь, что уязвимость ... хм чисто теоретического характера. :-)

Дед бил инит - недобил, бабка била - не убила..

Прям сказка про рэпку какая то))))

> Ты полгода как с винды что ли? :)

А что такое "винды"?

> Всю жизнь cdrecord был суицидным,

Просто дядечка Schilling -- м^Hчудак, и норовит сделать SUID'ными все
свои поделия. Фактически же cdrecord работал прекрасно без SUID по крайней
мере со времен 2.4.18 (может и раньше работал, не знаю -- до этого у меня
не было писалок и вообще я на 2.2.20 сидел). Да, RT приоритет заполучить
ему не удавалось, но как-то и без этого все нормально писалось.

> только вот недавно это стало ненужно.

Больше 2-х лет уже, между прочим (RLIMIT_RTPRIO появился в 2.6.13).

> Почему теоретически?

Потому что демоны -- дети init'а.

Какая дырка? Social engineering!

> и вот еще пример ситуации: студенты заявили, что у них чего-то не работает,
> админ логинится под студентом (для чистоты эксперимента), проверяет,
> быстро набирает su/пароль

Ага, называется такая ситуация social engineering :) И никаких дырок в ядре
не надо. Кладем в ~/bin свой su, который высылает пароль ему на mail, а
админу-недоумку говорит "Permission denied", после чего запускает настоящий
/bin/su. Или клавиатурный шпион пускаем (где-нибудь в ~/.profile или
~/.xsession).

Если ты знаешь, что cdrecord был суидным, и понимаешь, о чём говорил dmiceman, то зачем все эти словеса не в тему? Блеснуть знаниями захотел что ли? :)

> Ага, называется такая ситуация social engineering :) И никаких дырок в ядре не надо. Кладем в ~/bin свой su, который высылает пароль ему на mail, а админу-недоумку говорит "Permission denied", после чего запускает настоящий /bin/su.

не согласен с аналогией. объясню: ~/.profile, ~/.bashrc и подобные "автозапуски" можно закрыть на изменение для юзверя, т.о. никто не сможет сделать export PATH=~/bin:$PATH или alias su=~/bin/my-su. а в моём примере админ сам логинится со своего компа под н/п юзверем, а значит он более-менее уверен, что его никто не наё*****т, и тот su и есть /bin/su. в крайнем случае, он может так и набрать: /bin/su. а варианты "эй, админ! у меня тут не пашет, подойди-ка, введи пароль рута на сервак!" или админа-дыбила я и не рассматривал, потому что к данной теме это абсолютно не относится, т.к. это и есть то, что вы описали.

> Если ты знаешь, что cdrecord был суидным, и понимаешь, о чём говорил dmiceman,
> то зачем все эти словеса не в тему?

Очень даже в тему. Объясняют, что "дырка" имеет сугубо теоретический характер,
т.к.

1. В любом более-менее нормальном дистре количество SUID root бинарей стремится
к нулю
2. Во всех приведенных сценариях атаки дырка -- в голове у админа, а не в ядре.

> Не, это однозначно бага.

Не, это однозначно не бага. Управление родителем дочерним порожденным процессом это правильно.

> не согласен с аналогией. объясню: ~/.profile, ~/.bashrc и подобные "автозапуски"
> можно закрыть на изменение для юзверя,

Замаетесь. Во-первых, для этого нужно, чтоб этот юзверь не был владельцем
своей домашней директории. Многим программам это ни разу не нравится.
Во-вторых, создавать проблему, а потом ее решать -- кривой подход.

> а в моём примере админ сам логинится со своего компа под н/п юзверем,
> более-менее уверен, что его никто не наё*****т,

А совершенно напрасно он уверен. Где гарантия, что под этим же юзверем
не залогинен кто-нибудь еще, или не запущена какая-то гадость (например,
что-нибудь следящее за /dev/pts и пишущее оттуда все, до чего только
руки дотянутся)?

> а варианты "эй, админ! у меня тут не пашет, подойди-ка, введи пароль
> рута на сервак!" или админа-дыбила я и не рассматривал,

А это что такое, по-Вашему:

> а в моём примере админ сам логинится со своего компа под н/п юзверем,
> более-менее уверен, что его никто не наё*****т,

>init убить реально?
А у кого init дочерний процесс? У анонимуса, да?
:-)

>Управление suid програмами посредством сигналов?
Голосовых сигналов? Или флажками размахивать будешь?

> Замаетесь. Во-первых, для этого нужно,
> чтоб этот юзверь не был владельцем своей домашней директории.

4.2.

<root>~# chattr +i /home/arsi/.kderc
<root>~# lsattr /home/arsi/.kderc
----i-------- /home/arsi/.kderc
<root>~# ls -l /home/arsi/.kderc
-rw------- 1 arsi users 448 2007-08-19 00:25 /home/arsi/.kderc
<root>~# ls -ld /home/arsi
drwx------ 84 arsi   users 8192 2007-08-22 19:14 /home/arsi

<arsi>~$ mv .kderc .kderc2
mv: невозможно переместить `.kderc' в `.kderc2': Операция не позволяется
<arsi>~$ rm -f .kderc
rm: невозможно удалить `.kderc': Операция не позволяется
<arsi>~$ echo 'Hello, world!' >>.kderc
bash: .kderc: Отказано в доступе
<arsi>~$ cat .kderc
[General]
...


> Во-вторых, создавать проблему, а потом ее решать -- кривой подход. 

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


> Где гарантия, что под этим же юзверем
> не залогинен кто-нибудь еще

именно


> А это что такое, по-Вашему: 

ну хоть diff используйте, если сами не видите разницы...

> не согласен с аналогией. объясню: ~/.profile, ~/.bashrc и подобные "автозапуски"
> можно закрыть на изменение для юзверя,

>Замаетесь. Во-первых, для этого нужно, чтоб этот юзверь не был владельцем своей домашней директории.
ЧАВО? Про chattr напомнить?

> init убить реально?

> Конечно реально: сначала убиваешь ядро как родителя, потом > посылаешь сигнал смерти иниту.

Убиваешь себя, как родителя, традиционным для лора способом. Затем ядро. Далее по тексту .

дак это ж пончики =)

Это неудивительно.

Ты точно так же можешь запустить konsole, в ней два баша с разными логинами, а потом просто нажать на кнопку "закрыть".

Как думаешь, мертвый bash должен оставаться живым?

> Ты точно так же можешь запустить konsole, в ней два баша с разными логинами, а потом просто нажать на кнопку "закрыть".

всё верно, просто под двумя башами подразумевались два удаленных соединения к серверу с общим логином, где один из пользователей, перешедший под рут, был "убит" простым смертным))

> Как думаешь, мертвый bash должен оставаться живым?

я затрудняюсь ответить на этот вопрос, но, как вариант, баш н/п юзера не должен был умереть от рук н/п юзера, т.к. "держит" более привелегированный процесс, как если б в примере вместо SIGKILL был послан SIGTERM (его я и пытался послать сначала, но родительский баш не отреагировал на него). ну или действительно рутовый баш должен был демонизироваться. я пока не вижу универсального решения, устраивающего во всех случаях. имхо, сабж -- не баг, а лишь один из способов решения данной проблемы.

"Потому что демоны -- дети init'а. " (c)

> Что-то я не смог придумать, как это использовать хоть для чего-нибудь. Обычно у сетуидных программ (которых не так уж и много) не очень принято по какому-либо сигналу давать кому-то рутовый шелл. :)

Вспоминаю древнюю как мир дыру в Solaris, где делали следующее:
1. ulimit -c 8192
2. passwd
3. С другой консоли слали SIGSEGV или другой какой то сигнал этому passwd.
4. В corefile содержимое shadow :-)

У меня такая мысль тоже была, но я как-то думал что забирать shadow в память вроде как незачем, если хоть чуть-чуть башкой-то думать. :)

> Кладем в ~/bin свой su, который высылает пароль ему на mail, а админу-недоумку говорит "Permission denied"

Баян :-) Мы так в 1999-м году доставали пароль рута с фряхи :-)

> > Замаетесь. Во-первых, для этого нужно, чтоб этот юзверь не был владельцем
> > своей домашней директории.

> ЧАВО? Про chattr напомнить?

1. Запаритесь отслеживать все возможные файлы. У одного только bash'а
есть .bashrc, .bash_profile, .profile, .bash_logout, .logout.
И опция --rcfile. И куча интересных переменных окружения. Например,
export PS2='$([ `id -u` -eq 0 ] && rm -rf /)'
А есть еще ~/.ssh/environment. Да и у каждой софтины есть какой-нибудь
конфиг, в который можно вставить что-нибудь интересное, а потом идти
жаловаться админу, что она не работает.

2. Работает далеко не на всех ФС, но это фигня, то же можно сделать
стандартными средствами:

chmod 1755 ~pupkin
chown root:root ~pupkin/.bashrc
chmod 644 ~pupkin/.bashrc

> > Кладем в ~/bin свой su, который высылает пароль ему на mail, а
> > админу-недоумку говорит "Permission denied"

> Баян :-) Мы так в 1999-м году доставали пароль рута с фряхи :-)

Оно-то баян, вестимо. Причем _очень_ старый. Но до сих пор находятся
особо одаренные граждане, которые на него ведутся.

> ну придумайте какую-нить suid-ную программку, которая оперирует данными
> которые обычному пользователю знать не нужно (явки-пароли-etc). если
> уронить её в корку к которой можно потом добраться от текущего пользователя,

По умолчанию Linux не делает дампов, если бинарь SUID/SGID:

$ cat /proc/sys/fs/suid_dumpable
0

> chattr +i /home/arsi/.kderc

1. Работает только на ext[23]
2. Даже если работает, то

mkdir -p /tmp/hack/kde/env
echo 'FOO=`rm -rf /`' > /tmp/hack/kde/env/foo.sh
echo "KDEHOME=/tmp/hack/kde" >> ~/.ssh/environment

Это гонка, в которой админу трудно выиграть.

Гыыы 1 консоль ssh:
        ├─snmpd(2004)
        ├─sshd(2063)─┬─sshd(4337)───sshd(4340,dron)───bash(4341)───su(4369,root)───bash
(4370)
        │            └─sshd(4390)───sshd(4392,dron)───bash(4393)───pstree(4422)
        ├─syslogd(1746)
        ├─udevd(820)
        ├─vmware-guestd(1916)
        ├─xfs(2383,xfs)
        └─xinetd(2134)
[dron@localhost ~]$ kill -KILL 4337
-bash: kill: (4337) - Operation not permitted
[dron@localhost ~]$ kill -KILL 4369

2 консоль ssh
login as: dron
dron@*********'s password:
Last login: Sun Aug 19 23:38:44 2007 from ************
[dron@localhost ~]$ su

Последняя строчка не влезла :) #Killed $ Мона руту консоль отстрелити :)

УВАГА!! СРОЧНО ВСЕ ОТКТЫВАеМСЯ НА Ветку 2.2!!

uname -a

Linux localhost.localdomain 2.6.22.5 #1 SMP PREEMPT Thu Aug 23 12:00:14 YEKST 2007 i686 i686 i386 GNU/Linux

точно..., как галасит народная мудрость, немного перфразированная "ядро должно "отлежаться"".... ;)

> Это гонка, в которой админу трудно выиграть.

Неимоверно трудно. :)

root@localhost ~ # rm -rf /
rm: невозможно удалить корневой каталог `/'
root@localhost ~ #


:pPppPPpPpppP

> Последняя строчка не влезла :) #Killed $ Мона руту консоль отстрелити :)

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

Да и баги собственно нет никакой. Если я поднимаю суидный pppd call provider, то если бы не возможность послать сигнал порожденному рутовому процессу, то снять этот процесс и завершить соединение не будучи рутом было бы невозможно! Бага плять... Это фича!

Вобщем осмысливайте суть "баги":

$ pppd call provider
$ pidof pppd
4077
$ killall -9 pppd
$ pidof pppd

$

И как бы я убил pppd если бы не возможность слать сигнал прожденным процессами? Это нужная фича, а какой-то ламер поднял кипишь не разобравшись...

> rm: невозможно удалить корневой каталог `/'

да, тут нужен патч:

- rm -rf /
+ rm -rf /*

=)

админ, который обновляет систему прямо из ssh-сессии - дурачёк, который от пива все мозги выссал.

для выполнения длительного действия с возможностью им управлять, неоднократно подключаясь с разных терминалов, есть screen

Чё-то я не понял, при чём тут
1. я
2. суидная писалка.
Или под моим постом кнопочка "ответить" самая красивая? :)

> админ, который обновляет систему прямо из ssh-сессии - дурачёк, который от пива все мозги выссал.

а можно подробнее, в чем тупость дистанционноко обновления, и как, не через ssh, обновить систему на серваке, находящемся в ньюйоркском датацентре? или все кул-админы всё обновляют через telnet и web-интерфейсы?

очень просто
ssh user@server.org
su
screen
#./configure
#make
#make install
<ctrl+A-D>

с этого момента screen вместе с дочерними процессами отсоединяется от оболочки, которая была запущена su и от терминала.

в любой момент делаем (с любого компа)
ssh user@server.org
su
screen -r
с этого момента screen вместе с дочерними процессами подсоединяется к текущему терминалу и мы лицезреем компиляцию чего-либо (которая в наше отсутствие выполнялась в фоне). ну или видим что компиляция завершилась с ошибкой (или без неё:)

вместо компиляции может быть, ессно любой другой процесс.

> админ, который обновляет систему прямо из ssh-сессии - дурачёк, который от пива все мозги выссал. для выполнения длительного действия с возможностью им управлять, неоднократно подключаясь с разных терминалов, есть screen

Гентушнег? Часами компилируешь опдейты на серваке?

>очень просто ssh user@server.org su screen #./configure #make #make install <ctrl+A-D>

Ууу еще хуже - слакварер краснглазый, патрех бог, зависимости вручную. :)

Нормальные админы используют для обновления нормальные дистрибутивы с нормальными собранными пакетами, а не занимаются длительными компеляциями на продакшн серверах как некоторые красноглазые, выссавшие от пива мозги, поэтому никаких длительных мудоханий нет и screen использовать - лишнее.

Вообще-то, запускать даже и apt-get не в скрине действительно может только сугубо некомпетентный (ну или, скажем так, беззаботный) человек. Только к теме это не имеет отношения.