Проблемы с procfs(5) в FreeBSD всех версий

У меня ни на одной машине procfs не смонтирована. В отличие от Linux, здесь для работы ps и тп, procfs не нужна.

мне понравилось описание новости. Полностью согласен надо ко всему подходить с юмором.

> В отличие от Linux, здесь для работы ps и тп, procfs не нужна.

Да что вы говорите. У меня ядро без поддержки /proc и всякие ps/top работают.

Что-то я не вижу по указанной ссылке ничего на эту тему. Последний advisory касательно procfs был до 4.9-release. Уж не гонево ли это, уважаемый?

БЗДИШНИКИ-то как засуетились :-) Гляди-ка :-) :-)

нахрена она вообще нужна - есть же kvm

единственно что маломальски полезно в procfs это ctl

Последнее сообщение по безопасности FreeBSD касается уязвимости с fetch, не вижу по ссылке ничего связанного с procfs.

Естественно засуетились. Нам не плевать на безопасность :) И нечасто такие огрехи бывают, да ещё и о которых в первоисточнике ни слова нету.

Нет, по видимому, правда... попробуй сам - "freebsd-update -v fetch"

Не знаю ни одного, у кого бы на фре была procfs включена.

По теме: господа линуксоиды решили 1 апреля отпраздновать досрочно!

Даёшь пятилетку в 3 года!!! :))

> нахрена она вообще нужна - есть же kvm

Шутите? kvm - тяжелое наследие прошлого, все нормальные люди от него избавляются.

>БЗДИШНИКИ-то как засуетились :-) Гляди-ка :-) :-)
И не говори ! Ж)

В самом деле, пришло FreeBSD-SA-04:17.procfs.

Тем не менее, не знаю как сейчас в 4.х, а в пятёрке procfs отключена по умолчанию начиная с 5.0 и, кажется, с тех пор никто по ней особо не убивался. Я не знаю ни одной программы, которой бы она была нужна.

ЗЫ Автор новости так красочно расписал всяческие ужасти, но "забыл" сказать, что уязвимость уже исправлена.

> Что-то я не вижу по указанной ссылке ничего на эту тему.

На сайте я тоже не вижу, а вот в security-advisories@freebsd.org это есть.

а в 4.x ветке то, по умолчанию procfs всёж включена..

не потеме! пробовал и freebsd 5.3 и openbsd 3.6 -- так вот опен быстрее в разы и падучесть прог меньше (ядро негде не пересобирал и тонкой настройки неделал) (просто по опенбсд мало инфы поэтому двигаюсь медленно) так, что касается линукса так он удобнее (консоль бсд достала) и функцианальность ядра у линукса выше (поэтому и ошибок больше)

так что я за все UNIX подобные систему (каждый выберет себе по вкусу)

> Шутите? kvm - тяжелое наследие прошлого, все нормальные люди от него избавляются.

кто эти нормальные люди? линуксоиды чтоли?

смысл избавляться от kvm если kvm дает непревзойденную гибкость и единственная проблема это портабельность, но procfs тоже непортабельна

вот как раз надо избавляться от такого убожества как procfs.

пофиксить прогу под bsd использующую kvm гораздо проще чем пофиксить прогу под linux которая пользует procfs

Да? А у меня truss почему-то не работает без procfs :(

т/к trussу нужен думп памяти процесса

# cvsup -g -L 2 stable-supfile
...
Edit src/sys/miscfs/procfs/procfs_status.c
Add delta 1.20.2.6 2004.12.01.21.33.57 cperciva
...

>и функцианальность ядра у линукса выше

Насчет функциАнальности ядра это ты, паренек, в точку попал.

> смысл избавляться от kvm если kvm дает непревзойденную гибкость

Для использования kvm нужны права группы kmem. Соответственно все ваши
приложения будут sgid kmem. Нормальные люди стараются как раз уменьшить
число подобных программ.

В качестве домашнего задания посмотрите log message к ревизии 1.25:
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ps/ps.c

Можно немного и не по теме.. ;-) Насчёт быстроты и падучести: тут всё очень сильно от железа зависит и от поддержки оного определённой системой.. встречались даже такие моменты, что после обновления, на стабильной до того системе, начинались странные на первый взгляд выпадения в кору и сегфаулты.. потом, всё ж с дальнейшим обновлением проходило.. Да я тоже, постоянно пробую и использую и FreeBSD и OpenBSD да и NetBSD тоже... Вот, к примеру, у менья на одинаковом железе работают - FreeBSD 6.0-currant, NetBSD 2.0, OpenBSD 3.6.. точные замеры производительности не проводил, но на глаз, вполне идентичная скорость.. тоже, правильно отстроенное ничего нигде не падает... годами могло бы работать, если бы не обновления,.. ;-) кстати об обновлениях, больше всего граблей собрал именно на OpenBSD, меньше всего - NetBSD.. за FreeBSD есть один немаловажный плюс - огромное колличество софта в портах, у OpenBSD и NetBSD - намного меньше.. можно, конечно, ручками портировать, но это гиморно.. а ядра всё же пересобирать желательно, особенно если под сервера,. да инфы по OpenBSD/NetBSD немного, но для меня вполне достаточно.. кстати, в BSD и в X-ах можно сидеть не хуже, чем в Linux, хотя в общем ты прав, Linux, в определённом смысле удобнее, да и функсиональности ядра тож побольшеб да.. ну да.. мне тоже архитектура UNIX-like систем нравится более других...

а толку то .. реализовывать надо нормально

создать таблицу доступа к символам и сам кернель должен разрюхивать кому отдавать кусок а кому нет. И конфигурится все это дело через kvm.conf & kvmrehash - собщаем кернелю что таблица изменилась .. таблицу можно навернуть добавить туда классы/группы доступа и все такое ..

запретить прямой доступ памяти - только symbol + offset, и иметь null-symbol который указывает на 0(аля прямой доступ) который по дефолту разрешен только mem группе

и все - избавились полностью от необходимости прав kmem

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

> запретить прямой доступ памяти - только symbol + offset

... и получился sysctl. Не плодите сущности без необходимости.

по сути да, должен получиться расширенный sysctl - и sysctl умрет как obsolete сущность :)

>это ты, паренек, в точку попал.
В твою болевую точку бздунишка ты эдакий !

Все читаем внимательно. Уязвимость локальной DOS атаки.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
FreeBSD-SA-04:17.procfs Security Advisory
The FreeBSD Project

Topic: Kernel memory disclosure in procfs and linprocfs

Category: core
Module: sys
Announced: 2004-12-01
Credits: Bryan Fulton, Ted Unangst, and the SWAT analysis tool
Coverity, Inc.
Affects: All FreeBSD releases
Corrected: 2004-12-01 21:33:35 UTC (RELENG_5, 5.3-STABLE)
2004-12-01 21:34:23 UTC (RELENG_5_3, 5.3-RELEASE-p2)
2004-12-01 21:34:43 UTC (RELENG_5_2, 5.2.1-RELEASE-p13)
2004-12-01 21:33:57 UTC (RELENG_4, 4.10-STABLE)
2004-12-01 21:35:10 UTC (RELENG_4_10, 4.10-RELEASE-p5)
2004-12-01 21:35:57 UTC (RELENG_4_8, 4.8-RELEASE-p27)
CVE Name: CAN-2004-1066

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit
<URL:http://www.freebsd.org/security/>;.

I. Background

The process file system, procfs(5), implements a view of the system
process table inside the file system. It is normally mounted on
/proc, and is required for the complete operation of programs such as
ps(1) and w(1).

The Linux process file system, linprocfs(5), emulates a subset of
Linux's process file system and is required for the complete operation
of some Linux binaries.

II. Problem Description

The implementation of the /proc/curproc/cmdline pseudofile in the procfs(5)
file system on FreeBSD 4.x and 5.x, and of the /proc/self/cmdline
pseudofile in the linprocfs(5) file system on FreeBSD 5.x reads a process'
argument vector from the process address space. During this operation,
a pointer was dereferenced directly without the necessary validation
steps being performed.

III. Impact

A malicious local user could perform a local denial of service attack by
causing a system panic; or he could read parts of kernel memory. Such
memory might contain sensitive information, such as portions of the file
cache or terminal buffers. This information might be directly useful, or
it might be leveraged to obtain elevated privileges in some way. For
example, a terminal buffer might contain a user-entered password.

FreeBSD 4.x does not implement the /proc/self/cmdline pseudofile in
its linprocfs(5) file system, and is therefore only affected if the
procfs(5) file system is mounted.

In its default configuration, FreeBSD 5.x does not utilize procfs(5)
or linprocfs(5) and will therefore be unaffected by this vulnerability
unless the configuration is changed.

IV. Workaround

Unmount the procfs and linprocfs file systems if they are mounted.
Execute the following command as root:

umount -A -t procfs,linprocfs

Also, remove or comment out any lines in fstab(5) that reference
`procfs' or `linprocfs', so that they will not be re-mounted at next
reboot.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the
RELENG_5_3, RELENG_5_2, RELENG_4_10, or RELENG_4_8 security branch dated
after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 4.8, 4.10,
5.2, and 5.3 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 4.x]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:17/procfs4.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:17/procfs4.patch.asc

[FreeBSD 5.x]
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:17/procfs5.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:17/procfs5.patch.asc

b) Apply the patch.

# cd /usr/src
# patch < /path/to/patch

c) Recompile your kernel as described in
<URL:http://www.freebsd.org/handbook/kernelconfig.html>; and reboot the
system.

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_4
src/sys/miscfs/procfs/procfs_status.c 1.20.2.6
RELENG_4_10
src/UPDATING 1.73.2.90.2.6
src/sys/conf/newvers.sh 1.44.2.34.2.7
src/sys/miscfs/procfs/procfs_status.c 1.20.2.5.4.1
RELENG_4_8
src/UPDATING 1.73.2.80.2.30
src/sys/conf/newvers.sh 1.44.2.29.2.28
src/sys/miscfs/procfs/procfs_status.c 1.20.2.4.8.2
RELENG_5
src/sys/compat/linprocfs/linprocfs.c 1.84.2.1
src/sys/fs/procfs/procfs_status.c 1.52.2.1
RELENG_5_3
src/UPDATING 1.342.2.13.2.5
src/sys/compat/linprocfs/linprocfs.c 1.84.4.1
src/sys/conf/newvers.sh 1.62.2.15.2.7
src/sys/fs/procfs/procfs_status.c 1.52.4.1
RELENG_5_2
src/UPDATING 1.282.2.21
src/sys/compat/linprocfs/linprocfs.c 1.78.2.1
src/sys/conf/newvers.sh 1.56.2.20
src/sys/fs/procfs/procfs_status.c 1.49.2.1
- -------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----

iD8DBQFBrlpUFdaIBMps37IRAkqSAJ9bJt5VXd0g+OpZq76O84LGEtw3HgCfayws
iuc0B5+J0K67LvDIUA6+wck=
=2l7f
-----END PGP SIGNATURE-----

Да уж давно ознакомились..

>пофиксить прогу под bsd использующую kvm гораздо проще чем пофиксить прогу под linux которая пользует procfs

В чем это проявляется?

да фиг его знает, работать с чистыми данными всегда проще

> да фиг его знает, работать с чистыми данными всегда проще

так и запишем - трепло

>да фиг его знает, работать с чистыми данными всегда проще

Ну не всегда. Программе на C - да, а всяким скриптам - скорее нет. :)

поясните, что в вашем понимании чистые данные?;-))

Как я понял, ты ведь не особо то и BSD-шник ;-) так кто же ты, или кем хочешь казаться? а то, знаешь ли, стебать не по детски мы и так запосто можем.. :-P

4запостивший аффтор: "dereferencing" - это не загадочное "переопределение", а рядовое "разыменование" (указателя).

4mara:
>не потеме! пробовал и freebsd 5.3 и openbsd 3.6 -- так вот опен быстрее в разы и падучесть прог меньше

Надо было сразу 1c ставить, глядишь, совсем бы проги перестали падать!

//Loseki

понял тебя... ;-))но не льзя же та не по детски стебатся над детьми, добрее, однако, надо быть...

> FreeBSD 6.0-currant,

Енто че за зверь? ))))

как это чего за зверь?! ;-)самый обычный... нынешная текусчая ветка разработки FreeBSD...

FreeBSD 6.0-currant - это, полагаю, смородиновая фря.
"Теперь банановый!".

//Loseki

> смысл избавляться от kvm

Everything is a file.

> но procfs тоже непортабельна

Да уж портабельне, чем kvm. Да и программы, которые используют ее, куда более портабельны

> Everything is a file.

Да давно от этого ушли. Покажите мне /dev/eth0.

Да ладно уж, currant = current очепятка получилось,.. хотя, смородиновая.... так даже вкуснее будет!;-)))

>4запостивший аффтор: "dereferencing" - это не загадочное "переопределение", а рядовое "разыменование" (указателя).
да лааадна... загадочное-разгадочное, павлин-мавлин... не видишь - мы новости постим!!!
Вообще надо было бы написать просто изменение... Хрен его знает, что они имели ввиду - разыменование, рассылание:)... и что там на самом деле с указателем творится...

Контроль за доступом к kvm уже пробовали строить. Нереально это. И самая серьезная проблема доступа kvm - race conditions между чтением из userland и изменением в ядре. В отличие от доступа через сисколлы, это неизлечимо в принципе. Поэтому и уходят от него.

А для анализа мертвого ядра - да, самое оно.

> Да давно от этого ушли. Покажите мне /dev/eth0

bash-2.05b# ls -l /dev/net
total 0
crw-------  1 root  wheel  253,   1 Dec  4 10:22 bfe0
crw-------  1 root  wheel  253,   2 Dec  4 10:22 fwe0
crw-------  1 root  wheel  253,   3 Dec  4 10:22 lo0
bash-2.05b# uname -mrs
FreeBSD 5.3-BETA7 i386


Годится как аргумент? ;)))