[Comm] Security hole in X (KDE)

[Comm] Security hole in X (KDE)

[Vyatcheslav Perevalov]

1. Грузимся в runlevel 3
2. Логинимся как user1
3. startx
4. работаем в X, при необходимости отлучиться - блокируем экран
5. к машине подходит user2, видит что экран заблокирован
6. путём перебора Ctrl-Alt-[F1-F6] находит консоль, с которой запущены X
7. Ctrl-C
8. Вуаля. Делаем с данными user1 всё, что нам позволит наша совесть.

Просьба подтвердить или опровергнуть.
-- 
Всего хорошего
		/vip

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

Twas brillig at 14:27:17 09.03.2008 UTC+06 when Vyatcheslav Perevalov did gyre and gimble:

 VP> Просьба подтвердить или опровергнуть.

Опровергаю: это не security hole в X, это hole в голове user1.

ps: exec startx спасёт отца русской демократии.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Eugene Ostapets]

09.03.08, Vyatcheslav Perevalov<vip0 seversk.ru> написал(а):
>  3. startx
Сам дурак.
3. startx &
4. logout
>
>  Просьба подтвердить или опровергнуть.

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Security hole in X (KDE)

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

Здравствуйте Vyatcheslav Perevalov
  В сообщении от 9 марта 2008 Vyatcheslav Perevalov написал(a):
 > Просьба подтвердить или опровергнуть.

Это в любом xorg так, если не запрещено в xorg выполнение  ctrl+FN (и 
ctrl+backspace). 

-- 
  А ещё говорят так  (fortune):
 
PРH pbbyre - vg znxrf lbhe PРH pbby!  

________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Security hole in X (KDE)

[Vyatcheslav Perevalov]

В сообщении от 9 марта 2008 Хихин Руслан написал(a):
> Это в любом xorg так, если не запрещено в xorg выполнение  ctrl+FN (и
> ctrl+backspace).

Чем именно это запрещать?

-- 
Всего хорошего
		/vip

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 338 bytes --]

Twas brillig at 15:01:12 09.03.2008 UTC+06 when Vyatcheslav Perevalov did gyre and gimble:

 VP> Чем именно это запрещать?

В man xorg.conf рассказано. Но это костыль - всегда найдётся ещё
пара-тройка способов переключиться на vt.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 771 bytes --]

* Vyatcheslav Perevalov <vip0@> [080309 11:37]:
> 1. Грузимся в runlevel 3
А можно загрузиться в runlevel 5.

> 2. Логинимся как user1
> 3. startx
> 4. работаем в X, при необходимости отлучиться - блокируем экран
"путём перебора Ctrl-Alt-[F1-F6]" находим свободную консоль,
логинимся и делаем vlock -a.

> 5. к машине подходит user2, видит что экран заблокирован
> 6. путём перебора Ctrl-Alt-[F1-F6] находит консоль, с которой запущены X
Это отключаемо.  А ещё он может C-A-BS нажать.

> 7. Ctrl-C
> 8. Вуаля. Делаем с данными user1 всё, что нам позволит наша совесть.

> Просьба подтвердить или опровергнуть.
Ну а вы чего хотели?  Все гуёвые скринлокеры блокируют только
$DISPLAY, виртуальные консоли это не их проблема.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Comm] Security hole in X (KDE)

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Здравствуйте Mikhail Gusarov
  В сообщении от 9 марта 2008 Mikhail Gusarov написал(a):
 > В man xorg.conf рассказано. 
SERVERFLAGS SECTION
.......
 Option "DontVTSwitch"  "boolean"
    This disallows the use of the  Ctrl+Alt+Fn  sequence  (where  Fn
    refers  to one of the numbered function keys).  That sequence is
    normally used to switch to another "virtual terminal" on operat-
    ing  systems  that  have  this  feature.   When  this  option is
    enabled, that key sequence has no special meaning and is  passed
    to clients.  Default: off.
 Option "DontZap"  "boolean"
    This disallows the use of the Ctrl+Alt+Backspace sequence.  That
    sequence is normally used to terminate the  Xorg  server.   When
    this option is enabled, that key sequence has no special meaning
    and is passed to clients.  Default: off.
..........
 Option "VTSysReq"  "boolean"
   enables the SYSV-style VT switch sequence for  non-SYSV  systems
   which support VT switching.  This sequence is Alt-SysRq followed
   by a function key (Fn).  This prevents the Xorg server  trapping
   the  keys  used  for the default VT switch sequence, which means
   that clients can access them.  Default: off.


 > Но это костыль - всегда найдётся ещё 
 > пара-тройка способов переключиться на vt.
Не то, что-бы не верю, но не знаю не одного. :)

-- 
  А ещё говорят так  (fortune):
 
- Что делает системный администратор, проснувшись с похмелья? - 
Тестирует память...  

________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]

Twas brillig at 14:06:19 09.03.2008 UTC+03 when Хихин Руслан did gyre and gimble:

 >> Но это костыль - всегда найдётся ещё пара-тройка способов
 >> переключиться на vt.
 ХР> Не то, что-бы не верю, но не знаю не одного. :)

Скажем так - я бы не полагался на отсутствие таких способо ;)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

09.03.08, Mikhail Gusarov<dottedmag@dottedmag.net> написал(а):
> Twas brillig at 14:06:19 09.03.2008 UTC+03 when Хихин Руслан did gyre and gimble:
>
>
>   >> Но это костыль - всегда найдётся ещё пара-тройка способов
>   >> переключиться на vt.
>
>  ХР> Не то, что-бы не верю, но не знаю не одного. :)
>
>  Скажем так - я бы не полагался на отсутствие таких способо ;)
>
>

 Ну и вызывать, при таких проблемах: startx;exit .

 Для надежности, на startx прописать алиас.

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

Twas brillig at 22:48:49 09.03.2008 UTC+03 when Алексей Синицын did gyre and gimble:

 АС>  Ну и вызывать, при таких проблемах: startx;exit .

При таких проблемах лучше использовать xdm/wdm/kdm/gdm.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

2008/3/9, Mikhail Gusarov <dottedmag@dottedmag.net>:
> Twas brillig at 22:48:49 09.03.2008 UTC+03 when Алексей Синицын did gyre and gimble:
>
>   АС>  Ну и вызывать, при таких проблемах: startx;exit .
>
>  При таких проблемах лучше использовать xdm/wdm/kdm/gdm.
>

 В исходной постановке задачи фигурировал runlevel 3.  Может быть это
зачем-то так надо человеку.

Re: [Comm] Security hole in X (KDE)

[Michael Shigorin]

On Sun, Mar 09, 2008 at 11:00:44PM +0300, Алексей Синицын wrote:
> >   АС>  Ну и вызывать, при таких проблемах: startx;exit .
> >  При таких проблемах лучше использовать xdm/wdm/kdm/gdm.
> В исходной постановке задачи фигурировал runlevel 3.
> Может быть это зачем-то так надо человеку.

Это неверная постановка задачи; общеизвестно, что при
необходимости уменьшить вероятность подобных неприятностей
_показано_ использование display manager.

Хотя и в runlevel 3 его можно запускать, конечно. :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[Andrei Lomov]

Vyatcheslav Perevalov wrote:

> В сообщении от 9 марта 2008 Хихин Руслан написал(a):
>> Это в любом xorg так, если не запрещено в xorg выполнение  ctrl+FN (и
>> ctrl+backspace).
> 
> Чем именно это запрещать?
> 

Используйте 
$ vlock -a 
в консоли

-- 
Всего доброго,
А.Л.

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/9 Vyatcheslav Perevalov <vip0@seversk.ru>:
> 1. Грузимся в runlevel 3
>  2. Логинимся как user1
>  3. startx
>  4. работаем в X, при необходимости отлучиться - блокируем экран
>  5. к машине подходит user2, видит что экран заблокирован
>  6. путём перебора Ctrl-Alt-[F1-F6] находит консоль, с которой запущены X
>  7. Ctrl-C
>  8. Вуаля. Делаем с данными user1 всё, что нам позволит наша совесть.
>
>  Просьба подтвердить или опровергнуть.

Так и есть.

2008/3/10 Andrei Lomov <lomov@math.nsc.ru>:
> Vyatcheslav Perevalov wrote:
>
>  > В сообщении от 9 марта 2008 Хихин Руслан написал(a):
>  >> Это в любом xorg так, если не запрещено в xorg выполнение  ctrl+FN (и
>  >> ctrl+backspace).
>  >
>  > Чем именно это запрещать?
>  >
>
>  Используйте
>  $ vlock -a
>  в консоли

Простите, в какой консоли?

Вот Konsole: $ vlock -a
This tty (pts/1) is not a virtual console.
The entire console display cannot be locked.

Так как оставить машину спокойно работать? Тоже гружусь в init 3.

Re: [Comm] Security hole in X (KDE)

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

Здравствуйте ALT Linux User
  В сообщении от 10 марта 2008 ALT Linux User написал(a):
 > Так как оставить машину спокойно работать? Тоже гружусь в init 3

Прописать ключи в xorg

-- 
  А ещё говорят так  (fortune):
 
Death is Nature's way of recycling human beings. 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/10 Хихин Руслан <hihin@rambler.ru>:
> Здравствуйте ALT Linux User
>  В сообщении от 10 марта 2008 ALT Linux User написал(a):
>  > Так как оставить машину спокойно работать? Тоже гружусь в init 3
>
> Прописать ключи в xorg

Как-то не хочется запрещать открытие новых консолей...

А нельзя как-то сделать по-человечески, что бы всё же, если уж сессия
блокирована, то сначала спрашивать пароль, а уж потом разрешать всякие
сочетания клавиш?

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Twas brillig at 13:54:02 10.03.2008 UTC+03 when ALT Linux User did gyre and gimble:

 ALU> А нельзя как-то сделать по-человечески, что бы всё же, если уж сессия
 ALU> блокирована, то сначала спрашивать пароль, а уж потом разрешать всякие
 ALU> сочетания клавиш?

vim source.c

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Michael Shigorin]

On Mon, Mar 10, 2008 at 01:54:02PM +0300, ALT Linux User wrote:
> А нельзя как-то сделать по-человечески, что бы всё же, если уж
> сессия блокирована, то сначала спрашивать пароль, а уж потом
> разрешать всякие сочетания клавиш?

Не уверен, что X-сервер "в курсе", что сессия блокирована.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[Андрей Черепанов]

9 марта 2008 Vyatcheslav Perevalov написал:
> 1. Грузимся в runlevel 3
> 2. Логинимся как user1
> 3. startx
> 4. работаем в X, при необходимости отлучиться - блокируем экран
> 5. к машине подходит user2, видит что экран заблокирован
> 6. путём перебора Ctrl-Alt-[F1-F6] находит консоль, с которой запущены X
> 7. Ctrl-C
> 8. Вуаля. Делаем с данными user1 всё, что нам позволит наша совесть.
>
> Просьба подтвердить или опровергнуть.
Подтверждаю то, что сам пользователь нашёл приключений на свою голову и не 
использовал dm, как рекомендуют специалисты по безопасности.


-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/11 Андрей Черепанов <cas@altlinux.ru>:
> 9 марта 2008 Vyatcheslav Perevalov написал:
> > 1. Грузимся в runlevel 3
> > 2. Логинимся как user1
> > 3. startx
> > 4. работаем в X, при необходимости отлучиться - блокируем экран
> > 5. к машине подходит user2, видит что экран заблокирован
> > 6. путём перебора Ctrl-Alt-[F1-F6] находит консоль, с которой запущены X
> > 7. Ctrl-C
> > 8. Вуаля. Делаем с данными user1 всё, что нам позволит наша совесть.
> >
> > Просьба подтвердить или опровергнуть.
> Подтверждаю то, что сам пользователь нашёл приключений на свою голову и не
> использовал dm, как рекомендуют специалисты по безопасности.

IMHO это весьма спорный момент.
Во-первых, не надо требовать многого от пользователя - пользователь
этого, как известно, не любит.
Во-вторых, "рекомендации" по безопасности, если таковые нужны,
работают лучше, если уже "встроены" в систему, а не витают в воздухе в
виде неких "правил". Кстати, есть где-то эти рекомендации не грузится
в текстовую консоль в процессе установки ALD4? Понеже, анчекнул боксик
"грузиться в графический режим" и всё, безопасность и секъюрность
испарились?

IMHO довольно удобно НЕ грузиться в графический режим сразу. По многим
причинам. У меня дуалбут с оффтопиком и бывает несколько раз в день
приходится "скакать" туда-сюда. Чем меньше занимает загрузка - тем
душе приятнее, поскольку посмотреть-переписать пару файлов можно и в
консоли. Плюс, смотреть обновления - можно и в консоли. Плюс,
восстанавливать систему, настраивать систему, можно и в консоли. А
поскольку падает оно с завидной регулярностью - консоль частый гость
на наших голубых экранах.

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

Re: [Comm] Security hole in X (KDE)

[Vyatcheslav Perevalov]

В сообщении от 11 марта 2008 ALT Linux User написал(a):
> > Подтверждаю то, что сам пользователь нашёл приключений на свою голову и
> > не использовал dm, как рекомендуют специалисты по безопасности.
>
> IMHO это весьма спорный момент.
> Во-первых, не надо требовать многого от пользователя - пользователь
> этого, как известно, не любит.

 ............................................................

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

Слава Богу, хоть кто-то меня поддержал... а то сразу "Сам дурак", и т. д.

-- 
Всего хорошего
		/vip

Re: [Comm] Security hole in X (KDE)

[Ilis]

11.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
>
> Так что, с моей скромной точки зрения обыкновенного пользователя с
> ограниченными знаниями и не очень прямыми руками, такая политика
> взаимодействия икс-сервера и кедэе кажется простой дырой в
> безопасности.

Т.е. если при запуске иксов не блокируется текстовая консоль, то это дыра?
А где дыра, если user1 открыл вторую консоль, залогинился там, и,
например, заблокировал её и ушёл? Первая тоже должна автоматически
блокироваться?

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/11 Ilis <ilis.krou@gmail.com>:
> 11.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
> >
> > Так что, с моей скромной точки зрения обыкновенного пользователя с
> > ограниченными знаниями и не очень прямыми руками, такая политика
> > взаимодействия икс-сервера и кедэе кажется простой дырой в
> > безопасности.
>
> Т.е. если при запуске иксов не блокируется текстовая консоль, то это дыра?
> А где дыра, если user1 открыл вторую консоль, залогинился там, и,
> например, заблокировал её и ушёл? Первая тоже должна автоматически
> блокироваться?

IMHO это предмет для размышлений тех, кто отвечает за архитектуру
приложений/системы. Возможно, это должно настраиваться в GUI. Некое
нечто со вкладкой "безопасность". "Блокировать все сессии данного
пользователя при включении им кнопки "блокировка сессии"?" (извините,
не знаю как это называется в русской версии).

В любом случае, если я открыл сессию, её видно по $ w - я хотел бы,
что бы она блокировалась, пусть одна, если я явным образом сообщаю
приложению такую команду, пусть и через GUI. Механизм такой блокировки
безусловно обсуждаем, но не на уровне пользователя. Пользователь может
помочь с казуальным Quality Assurance, но никак ни с проектированием
внутренних зависимостей компонентов системы.

Re: [Comm] Security hole in X (KDE)

[Eugene Ostapets]

11.03.08, ALT Linux User<altlinux.mailbox gmail.com> написал(а):
> IMHO это предмет для размышлений тех, кто отвечает за архитектуру
>  приложений/системы. Возможно, это должно настраиваться в GUI. Некое
>  нечто со вкладкой "безопасность". "Блокировать все сессии данного
>  пользователя при включении им кнопки "блокировка сессии"?" (извините,
>  не знаю как это называется в русской версии).
Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя крутым -
пусть думает головой!
Все необходимое для организации безопасного рабочего места в системе
есть, но только в KDE/Gnome/XFCE есть настройка из коробки "заботиться
о безопасности для новичков и включать блокировку сеанса по
таймауту"...

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [Comm] Security hole in X (KDE)

[Denis Medvedev]

А бывает ли "текстовый" скринсейвер? 
Это бы решило вопрос.

-----Original Message-----
From: Ilis <ilis.krou@gmail.com>
To: "ALT Linux Community general discussions" <community@lists.altlinux.org>
Date: Tue, 11 Mar 2008 19:09:07 +0500
Subject: Re: [Comm] Security hole in X (KDE)

> 11.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
> >
> > Так что, с моей скромной точки зрения обыкновенного пользователя с
> > ограниченными знаниями и не очень прямыми руками, такая политика
> > взаимодействия икс-сервера и кедэе кажется простой дырой в
> > безопасности.
> 
> Т.е. если при запуске иксов не блокируется текстовая консоль, то это дыра?
> А где дыра, если user1 открыл вторую консоль, залогинился там, и,
> например, заблокировал её и ушёл? Первая тоже должна автоматически
> блокироваться?
> _______________________________________________
> community mailing list
> community@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/community

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/11 Eugene Ostapets <eostapets@gmail.com>:
> 11.03.08, ALT Linux User<altlinux.mailbox gmail.com> написал(а):
> > IMHO это предмет для размышлений тех, кто отвечает за архитектуру
> >  приложений/системы. Возможно, это должно настраиваться в GUI. Некое
> >  нечто со вкладкой "безопасность". "Блокировать все сессии данного
> >  пользователя при включении им кнопки "блокировка сессии"?" (извините,
> >  не знаю как это называется в русской версии).
> Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя крутым -
> пусть думает головой!

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

Скажите, пожалуйста, а возможно ли использование консольного
скринсейвера/локера в KDE? Может быть, если запустить xscreensaver, он
будет блокировать и KDE'ешную сессию?

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

11.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
> 2008/3/11 Eugene Ostapets <eostapets@gmail.com>:
>
> > 11.03.08, ALT Linux User<altlinux.mailbox gmail.com> написал(а):
>  > > IMHO это предмет для размышлений тех, кто отвечает за архитектуру
>  > >  приложений/системы. Возможно, это должно настраиваться в GUI. Некое
>  > >  нечто со вкладкой "безопасность". "Блокировать все сессии данного
>  > >  пользователя при включении им кнопки "блокировка сессии"?" (извините,
>  > >  не знаю как это называется в русской версии).
>  > Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя крутым -
>  > пусть думает головой!
>
>
> Поскольку снятие галки "Загружаться в графическом режиме" - штатная
>  возможность инсталлятора системы, IMHO было бы здорово как-то
>  предупредить пользователя, что снимая галку он становится крут,
>  переходит в другую категорию. Возможно, даже будет вынужден думать
>  головой.
>
>  Скажите, пожалуйста, а возможно ли использование консольного
>  скринсейвера/локера в KDE? Может быть, если запустить xscreensaver, он
>  будет блокировать и KDE'ешную сессию?
>


21:54 al@wind ~ $ apt-cache search lock|grep cons
consolelocker - Daemon for lock console terminal and virtual consoles.
tinycdb - A package for maintenance of constant databases
vim-console - A terminal-based, full-featured version of the VIM editor
vlock - A program which locks one or more virtual consoles
xtdesktop-plugins - Small utility for creating desktop icons
21:55 al@wind ~ $

С одной стороны действительно, Xdm для данной задачи, но с другой
стороны, так-же действительно, если есть возможность устанавливать 3
runlevel то нужно наверно и это предупреждение (omg, это сколько
предупрежденией нужно "внимание, нажмая эту пипку Вы будете вынуждены
блокировать компьютер самостоятельно, блаблабла"). Может просто
спрятать третий runlevel подальше?

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

11.03.08, Алексей Синицын<asinitsinster@gmail.com> написал(а):

>  С одной стороны действительно, Xdm для данной задачи, но с другой
>  стороны, так-же действительно, если есть возможность устанавливать 3
>  runlevel то нужно наверно и это предупреждение (omg, это сколько
>  предупрежденией нужно "внимание, нажмая эту пипку Вы будете вынуждены
>  блокировать компьютер самостоятельно, блаблабла"). Может просто
>  спрятать третий runlevel подальше?
>

Кстати задумался.

Какая такая причина может потребовать третий ранлевел и стартикс?

Если нужны иксы, то почему не dm? Если иксы тяжелы то достаточно много
есть консольного ПО.

Мое мнение - понты.

Re: [Comm] Security hole in X (KDE) -- not

[Michael Shigorin]

On Tue, Mar 11, 2008 at 04:41:56PM +0300, ALT Linux User wrote:
> > Подтверждаю то, что сам пользователь нашёл приключений на
> > свою голову и не использовал dm, как рекомендуют специалисты
> > по безопасности.
> IMHO это весьма спорный момент.

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

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

Если не надо, то что он забыл в консоли?

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

Они и встроены: по умолчанию запускается dm.

> Кстати, есть где-то эти рекомендации не грузится в текстовую
> консоль в процессе установки ALD4? Понеже, анчекнул боксик
> "грузиться в графический режим" и всё, безопасность и
> секъюрность испарились?

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

> IMHO довольно удобно НЕ грузиться в графический режим сразу.

Удобство и безопасность обычно на противоположных концах качели.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[Michael Shigorin]

On Tue, Mar 11, 2008 at 06:53:03PM +0300, ALT Linux User wrote:
> > Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя
> > крутым - пусть думает головой!
> Поскольку снятие галки "Загружаться в графическом режиме" -
> штатная возможность инсталлятора системы, IMHO было бы здорово
> как-то предупредить пользователя, что снимая галку он
> становится крут, переходит в другую категорию. Возможно, даже
> будет вынужден думать головой.

Резонно; не хотите оформить FR на alterator-x11? (Cc: pls)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[Comm] console locker

[Michael Shigorin]

On Tue, Mar 11, 2008 at 05:35:53PM +0300, Denis Medvedev wrote:
> А бывает ли "текстовый" скринсейвер? 

Бывает, но разыскивался, наверное, vlock -a

> Это бы решило вопрос.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

11.03.08, Алексей Синицын<asinitsinster@gmail.com> написал(а):
> 11.03.08, Алексей Синицын<asinitsinster@gmail.com> написал(а):
>
>
>  >  С одной стороны действительно, Xdm для данной задачи, но с другой
>  >  стороны, так-же действительно, если есть возможность устанавливать 3
>  >  runlevel то нужно наверно и это предупреждение (omg, это сколько
>  >  предупрежденией нужно "внимание, нажмая эту пипку Вы будете вынуждены
>  >  блокировать компьютер самостоятельно, блаблабла"). Может просто
>  >  спрятать третий runlevel подальше?
>  >
>
>
> Кстати задумался.
>
>  Какая такая причина может потребовать третий ранлевел и стартикс?
>
>  Если нужны иксы, то почему не dm? Если иксы тяжелы то достаточно много
>  есть консольного ПО.
>
>  Мое мнение - понты.
>

Впрочем, одну причину придумать удалось. Не запускать dm с правами
рута, но сразу от пользователя. Хотя насколько это может вообще быть
актуально...

Re: [Comm] Security hole in X (KDE)

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

Twas brillig at 22:39:57 11.03.2008 UTC+03 when Алексей Синицын did gyre and gimble:

 АС> Впрочем, одну причину придумать удалось. Не запускать dm с правами
 АС> рута, но сразу от пользователя.

dm от пользователя запускать столь же малополезно, как и программу login :)

А иксы и так с правами рута работают, им иначе (пока что) до железа не добраться.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

11.03.08, Mikhail Gusarov<dottedmag@dottedmag.net> написал(а):
> Twas brillig at 22:39:57 11.03.2008 UTC+03 when Алексей Синицын did gyre and gimble:
>
>   АС> Впрочем, одну причину придумать удалось. Не запускать dm с правами
>   АС> рута, но сразу от пользователя.
>
>  dm от пользователя запускать столь же малополезно, как и программу login :)
>
>  А иксы и так с правами рута работают, им иначе (пока что) до железа не добраться.
>
>

 В общем - резюме: Сделать баальшую красивую красную вывеску с
надписями "делайте это только в том случае если точно понимаете что
это такое, уверены в том, что делаете и сами будете отвечать за
последствия" и вставить перед всеми малопонятными пипками.

 Хотя такое еще больше внимания привлечет.

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/11 Michael Shigorin <mike@osdn.org.ua>:
> On Tue, Mar 11, 2008 at 06:53:03PM +0300, ALT Linux User wrote:
> > > Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя
> > > крутым - пусть думает головой!
> > Поскольку снятие галки "Загружаться в графическом режиме" -
> > штатная возможность инсталлятора системы, IMHO было бы здорово
> > как-то предупредить пользователя, что снимая галку он
> > становится крут, переходит в другую категорию. Возможно, даже
> > будет вынужден думать головой.
>
> Резонно; не хотите оформить FR на alterator-x11? (Cc: pls)

Извините, не знаю, как это сделать... Заходил на bugzilla
(неправильно?), но никаких полей ввода для feature request там не
заметил, может быть невнимательно смотрел?

Re: [Comm] Security hole in X (KDE)

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Tue, Mar 11, 2008 at 11:31:28PM +0300, ALT Linux User wrote:
> Извините, не знаю, как это сделать... Заходил на bugzilla
> (неправильно?), но никаких полей ввода для feature request там не
> заметил, может быть невнимательно смотрел?
severity=enhancement

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

<wart_alt> У нас rpm до сих пор с beecrypt 2.2 собирается.
<thresh> О, wart_alt уже говорит "у нас" :D
<wart_alt> thresh: Ну что ж делать-то.
<raorn> thresh: просто wart сказал бы "у вас"

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Security hole in X (KDE)

[Michael Shigorin]

On Tue, Mar 11, 2008 at 11:31:28PM +0300, ALT Linux User wrote:
> > > > Пользователю - runlevel 5 с xdm/gdm/kdm, если он считает себя
> > > > крутым - пусть думает головой!
> > > Поскольку снятие галки "Загружаться в графическом режиме" -
> > > штатная возможность инсталлятора системы, IMHO было бы здорово
> > > как-то предупредить пользователя, что снимая галку он
> > > становится крут, переходит в другую категорию. Возможно, даже
> > > будет вынужден думать головой.
> > Резонно; не хотите оформить FR на alterator-x11? (Cc: pls)
> Извините, не знаю, как это сделать... Заходил на bugzilla
> (неправильно?), но никаких полей ввода для feature request там
> не заметил, может быть невнимательно смотрел?

Severity: enhancement (на всякий напоминаю, хотя сейчас наконец
поставили ссылку с http://bugzilla.altlinux.org/ -- mini-HOWTO
здесь: http://www.freesource.info/wiki/BugzillaMiniHowto)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 21:05 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 21:19 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 21:30 UTC (permalink / raw)]

[Comm] [JT] Re: Security hole in X (KDE)

[@ 2008-03-11 21:38 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-11 21:40 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 22:04 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 22:13 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 22:18 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-11 22:22 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 4:19 UTC (permalink / raw)]

Re: [Comm] [JT] Re: Security hole in X (KDE)

[@ 2008-03-12 5:58 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 7:33 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 7:40 UTC (permalink / raw)]

Re: [Comm] [JT] Re: Security hole in X (KDE)

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Wed, Mar 12, 2008 at 12:38:25AM +0300, Alexei V. Mezin wrote:
> Особенно удобно из консоли ходить в инет за инструкциями по настройке,
Не вижу проблемы. elinks табы умеет даже.

> а уж как удобно из links в одной консоли копипастить текст в конфиг,
> открытый в другой консоли...
Ничуть не сложнее, чем из FF в иксах в kwrite/vim/whatever в иксах же.
Той же мышкой.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

 * gvy перевешивает #3654 на Pilot, приговаривая "кто к нам с багой
   придет, на того и повесим!" :) 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] exec startx

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 204 bytes --]

On Sun, Mar 09, 2008 at 02:27:17PM +0600, Vyatcheslav Perevalov wrote:
> 1. Грузимся в runlevel 3
> 2. Логинимся как user1
> 3. startx

Забудьте про startx, пишите всегда
exec startx


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

12.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
> 2008/3/11 Алексей Синицын <asinitsinster@gmail.com>:
>
> > 11.03.08, Алексей Синицын<asinitsinster@gmail.com> написал(а):
>
>
> > Кстати задумался.
>  >
>  > Какая такая причина может потребовать третий ранлевел и стартикс?
>  >
>  > Если нужны иксы, то почему не dm? Если иксы тяжелы то достаточно много
>  > есть консольного ПО.
>  >
>  > Мое мнение - понты.
>
>
> Мнение интересное.
>

 Наверно я действительно несколько резко. Но попробую объяснить.

>  Особенно в свете того, что упавшая система поправляется консолью.
>  Система настраивается успешнее всего - из консоли.
>

 Ну наверно все-же не совсем так. Хотя и "сила юникс в командной
строке", но удобства графической системы еще никто не отменял.

>  Пример? - Для того что бы поднять звук на ноутбуке Toshiba L40-139,
>  мне пришлось менять строчку в конфиге альсы и перезапускаться.
>  Наверное минимум раз 10. Зачем мне для этого грузить икс?
>
>  Далее. Вот упал видеодрайвер (intel integrated). И опять я в консоли.
>  И так далее, и так далее...
>

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

>  Вот я и решил: а зачем мне сразу грузиться в иксы? Надо сначала
>  настроить систему. Жаль, что процесс затянулся...
>
>  Уверен, что 90% того, что я делал - имело быстрые обходные правильные
>  пути. Но я их не знал. А поскольку не был предупреждён о снижении
>  безопасности, - действовал как умел на своём, пусть и скромном, уровне
>  понимания функционирования системы.
>

 Мы часто не задумываемся об очевидных вещах.

 Дело в том, что блокирование системы в графическом режиме и
блокирование системы где открыто несколько (!) виртуальных консолей -
это две достаточно разные вещи.

 И различие в первую очередь в том, что графическая система - это
всего одна консоль, и блокирование ее - блокирует все сразу. Тогда как
авторизовавшись несколько раз на нескольких виртуальных консолях для
блокировании системы необходимо заблокировать их все. А, кстати,
разблокировать их надо каждую в отдельности или однократным набором
пароля? А если я работаю во второй консоли, то первая должна
заблокироваться пока на ней не было действий? Последий каверзный
вопрос, кстати, так-же не имеет смысла при использовании графической
системы.

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

 И еще раз о происхождении вопроса. Хорошо, можно настраивать систему.
Но при первом возможном случае уместно и целесообразно использовать
dm, а если kde долго грузится, то скажем какой нибудь twm или fluxbox.
Если-же вопрос стоит так: "хочу стартовать систему без исков, но потом
эти иксы запускать", то такой вопрос уже вызывает встречный вопрос: "а
зачем", другими словами "а есть-ли смысл тратить на это время и
силы?".

 И еще одно уточнение. А если я использую консоль (и иногда запускаю
иксы), то блокирую-ли я все эти консоли (я-же не могу иметь дело всего
с одним терминалом) оставляя машину? И если я задумался о блокировании
всего множества брошенных терминалов, то очень быстро я прийду к
вопросу о блокировании и терминала под исками и решение startx;exit
будет лежать на поверхности, но если и не будет то тема будет
называться не "секурити холе", а "посоветуйте".

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/12 Алексей Синицын <asinitsinster@gmail.com>:
> 12.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
> >  Особенно в свете того, что упавшая система поправляется консолью.
> >  Система настраивается успешнее всего - из консоли.
> >
>
>  Ну наверно все-же не совсем так. Хотя и "сила юникс в командной
> строке", но удобства графической системы еще никто не отменял.

Речь, в моём случае, не идёт об удобстве. Речь идёт о единственно
возможном средстве. Ноутбук Toshiba L40-139: настройка wifi была
возможна только из консоли.
Более того, даже находясь в иксах, я всё равно КАЖДЫЙ божий раз, что
бы поднять сеть отдаю команды:

# modprobe ndiswrapper
# iwconfig ESSID и так далее
# dhcpcd -G и так далее

Далее, неоднократно, при апдейте системы (настроенной на стабильный
бранч) падал интеловский видеодрайвер. Как настроить его без консоли?

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


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

Утопия? Фантастика? Вымысел? ... и где это я успел к этому привыкнуть
на том же ноутбуке...

>  Мы часто не задумываемся об очевидных вещах.
>
>  Дело в том, что блокирование системы в графическом режиме и
> блокирование системы где открыто несколько (!) виртуальных консолей -
> это две достаточно разные вещи.

Это только лишь одна точка зрения. Вот другая: с такой точки зрения
пользователя ГУЯ, даже системные действия - не более чем кликанье на
соответствующие кнопки. Чуть глубже лежит понимание, что подавляющее
большинство "мест для кликанья" - всего лишь навсего фронт-энды к
соответствующим консольным утилитам, командам.

Отсюда резонный вопрос: почему в одном случае эти фронтенды выполняют
требуемые от них системные действия, а в других нет?

Именно поэтому, моё IMHO: DE KDE содержит ошибку работы с
пользователем, не позволяя ему блокировать сессию с помощью ГУЯ.
Дальнейшее расширение этого действия: блокировать ли все сессии,
открытые данным пользователем или только текущую - это скорее вопрос
настройки того механизма, который отсутствует. KDE не осуществляет
требуемого от него системного действия - блокировка сессии
пользователя имярек.

>  И различие в первую очередь в том, что графическая система - это
> всего одна консоль, и блокирование ее - блокирует все сразу. Тогда как
> авторизовавшись несколько раз на нескольких виртуальных консолях для
> блокировании системы необходимо заблокировать их все. А, кстати,
> разблокировать их надо каждую в отдельности или однократным набором
> пароля? А если я работаю во второй консоли, то первая должна
> заблокироваться пока на ней не было действий? Последий каверзный
> вопрос, кстати, так-же не имеет смысла при использовании графической
> системы.

И эти все "каверзные вопросы" - лишь аспекты настройки механизма,
которого почему-то нет. Ну, или пока про который не рассказали.

>  И еще одно уточнение. А если я использую консоль (и иногда запускаю
> иксы), то блокирую-ли я все эти консоли (я-же не могу иметь дело всего
> с одним терминалом) оставляя машину? И если я задумался о блокировании
> всего множества брошенных терминалов, то очень быстро я прийду к
> вопросу о блокировании и терминала под исками и решение startx;exit
> будет лежать на поверхности, но если и не будет то тема будет
> называться не "секурити холе", а "посоветуйте".

Но это: $ startx;exit - никакое не решение, поскольку возможность
завершить сессию KDE остаётся. Чего не должно быть никоим образом, ибо
речь идёт о несанкционированном действии.
Довольно странно, насколько трудно донести простую мысль: сначала
спросить пароль, потом разрешать действия.

Советы, тем не менее, всегда приветствуются.

Re: [Comm] Security hole in X (KDE)

[Alexei V. Mezin]

ALT Linux User пишет:

> Речь, в моём случае, не идёт об удобстве. Речь идёт о единственно
> возможном средстве. Ноутбук Toshiba L40-139: настройка wifi была
> возможна только из консоли.
Вот с этого места поподробнее! Загрузка графической среды ПРИНЦИПИАЛЬНО 
убивала возможность отконфигурировать безпроводной интерфейс?


> Более того, даже находясь в иксах, я всё равно КАЖДЫЙ божий раз, что
> бы поднять сеть отдаю команды:
> 
> # modprobe ndiswrapper
> # iwconfig ESSID и так далее
> # dhcpcd -G и так далее
> 
etcnet позволяет все это настроить так, чтоб оно работало
1. само
2. при старте системы
3. в крайнем случае после ручного ifup

Может пора освоить штатные способы настройки системы и прекратить 
заниматься ерундой?


> Далее, неоднократно, при апдейте системы (настроенной на стабильный
> бранч) падал интеловский видеодрайвер. Как настроить его без консоли?

Бага висит? И часто ли обновляется бранч, чтоб с него _каждый_ день 
апдейтиться?


> 
> Ну и остальное... Зачем мне сразу грузиться в иксы, если система
> постоянно требует к себе отладочного внимания. 
У меня, например, Сизиф (который нестабильный более, чем бранч) и 
система не требует какого-то отдельного повышенного внимания даже после 
апдейтов. Что я делаю не так?


> Как начинающий
> пользователь, 
Являетесь ССЗБ. И сами ищете себе на ровном месте выдуманные проблемы.

> Именно поэтому, моё IMHO: DE KDE содержит ошибку работы с
> пользователем, не позволяя ему блокировать сессию с помощью ГУЯ.

Почему бы тогда не блокировать ВСЕ вторые и далее сессии Иксов при 
блокировке первой? А то вдруг юзер забудет, что у него еще две сессии 
открыто? Почему бы не блокировать ВСЕ консоли, а то залогинится на три, 
а отлогинится только на одной.

А то давайте пофантазируем:
вот залогинился юзер на первую консоль, а потом на вторую. И запустил во 
второй ДОСбокс (или досему), а потом взял да и забыл про эту консоль 
(или, чего доброго, подумал, что там ДОС и ничего ему не угроожает). А 
потом будем рассуждать, что ДОСбокс содержит в себе фатальную ошибку 
безопасности, потому что позволяет забыть про себя в консоли, и не 
блокирует ее? Туда же запишем и ssh! А вдруг там ssh-Сессия на другой 
хост, и ее тоже забыли? Почему не заблокировано автоматом?!! Кстати, mc 
тоже попадает под раздачу! Тоже должен блокировать консоль! Мало ли 
чего, кругом враги!

Так что давайте просто не будем увлекаться и искать проблемы там, где их 
нет. Есть рекомендованные способы работы в системе. Есть "оригинальные" 
(чтоб не писать "извращенные"). Для оригинальных есть _отдельные_ 
решения, которые тут озвучили. Кто хочет работать своим способом, его 
право. Но всем остальным это не надо.

Re: [Comm] exec startx

[ALT Linux User]

2008/3/12 Dmitry V. Levin <ldv@altlinux.org>:
> On Sun, Mar 09, 2008 at 02:27:17PM +0600, Vyatcheslav Perevalov wrote:
> > 1. Грузимся в runlevel 3
> > 2. Логинимся как user1
> > 3. startx
>
> Забудьте про startx, пишите всегда
> exec startx

Спасибо за совет.
Однако, проблема решена лишь частично, поскольку полной блокировки
доступа к сессии не происходит. Например, её всё так же можно
завершить по Ctrl+Alt+Backspace.

Нет ли какого-нибудь решения для этого?

Не хотелось бы запрещать "волшебные" сочетания клавиш для KDE. Много
времени уходит на наладку системы и часто бывает полезно переключится
на F12. Или запустить несколько DM, что бы посмотреть, как выглядят
шрифты.

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/12 Alexei V. Mezin <alexei-mezin@rambler.ru>:
> ALT Linux User пишет:
>
> > Речь, в моём случае, не идёт об удобстве. Речь идёт о единственно
> > возможном средстве. Ноутбук Toshiba L40-139: настройка wifi была
> > возможна только из консоли.
> Вот с этого места поподробнее! Загрузка графической среды ПРИНЦИПИАЛЬНО
> убивала возможность отконфигурировать безпроводной интерфейс?

Мне кажется, Вы немного невнимательно прочитали то, что было до этого:

> 12.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):

> >  Особенно в свете того, что упавшая система поправляется консолью.
> >  Система настраивается успешнее всего - из консоли.
> >
2008/3/12 Алексей Синицын <asinitsinster@gmail.com>:
>  Ну наверно все-же не совсем так. Хотя и "сила юникс в командной
> строке", но удобства графической системы еще никто не отменял.

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

Впрочем, я нигде не претендовал на то, что все мои действия являются
абсолютно правильными. Но, однако, оставляю за собой право действовать
так, как считаю нужным. Даже если кому-то такой способ действия не
кажется оптимальным.

> > Более того, даже находясь в иксах, я всё равно КАЖДЫЙ божий раз, что
> > бы поднять сеть отдаю команды:
> >
> > # modprobe ndiswrapper
> > # iwconfig ESSID и так далее
> > # dhcpcd -G и так далее
> >
> etcnet позволяет все это настроить так, чтоб оно работало
> 1. само
> 2. при старте системы
> 3. в крайнем случае после ручного ifup

А где можно об этом почитать применительно к ALT Linux 4 PD? На момент
задавания мной таких вопросов в рассылке (по настройке WiFi) мне никто
таких советов не дал.

> Может пора освоить штатные способы настройки системы и прекратить
> заниматься ерундой?

С большим удовольствием.

> > Далее, неоднократно, при апдейте системы (настроенной на стабильный
> > бранч) падал интеловский видеодрайвер. Как настроить его без консоли?
>
> Бага висит? И часто ли обновляется бранч, чтоб с него _каждый_ день
> апдейтиться?

Не апдейтюсь каждый день.
В рассылке много материалов о падениях и на интел, и на ати. Имею и
то, и другое в своём распоряжении.

> У меня, например, Сизиф (который нестабильный более, чем бранч) и
> система не требует какого-то отдельного повышенного внимания даже после
> апдейтов. Что я делаю не так?
>
>
> > Как начинающий
> > пользователь,
> Являетесь ССЗБ. И сами ищете себе на ровном месте выдуманные проблемы.

Апдейт из заявленного стабильным Branch 4 является поиском проблемы на
ровном месте?

> > Именно поэтому, моё IMHO: DE KDE содержит ошибку работы с
> > пользователем, не позволяя ему блокировать сессию с помощью ГУЯ.
>
> Почему бы тогда не блокировать ВСЕ вторые и далее сессии Иксов при
> блокировке первой? А то вдруг юзер забудет, что у него еще две сессии
> открыто? Почему бы не блокировать ВСЕ консоли, а то залогинится на три,
> а отлогинится только на одной.

Возвращаемся к механизму настройки несуществующего (необъявленного)
механизма в KDE, позволяющему пользователю блокировать свою сессию.
То, что Вы поминаете - это воображаемый чекбокс: "блокировать все
открытые сессиии пользователя имярек?".

> Так что давайте просто не будем увлекаться и искать проблемы там, где их
> нет. Есть рекомендованные способы работы в системе. Есть "оригинальные"
> (чтоб не писать "извращенные").

Как нет проблемы?
Пользователь работает в KDE. Заблокировал сессию, отшёл. Пришёл некто,
нажал Ctrl+Alt+Backspace и ушёл. Вернувшийся пользователь находит на
месте оставленной сессии предложение вновь залогиниться.

Это называется "нет проблемы"?

Re: [Comm] exec startx

[Andrew Borodin]

On Wed, Mar 12, 2008 at 04:51:44PM +0300, ALT Linux User wrote:
> > Забудьте про startx, пишите всегда
> > exec startx

> Спасибо за совет.
> Однако, проблема решена лишь частично, поскольку полной блокировки
> доступа к сессии не происходит. Например, её всё так же можно
> завершить по Ctrl+Alt+Backspace.

> Нет ли какого-нибудь решения для этого?

Уже упоминалось в этом треде.

DontZap в xorg.conf.

This  disallows  the use of the Ctrl+Alt+Backspace sequence.
That sequence is normally used to terminate the Xorg server.
When this option is enabled, that key sequence  has no special
meaning and is passed to clients.  Default: off.

-- 

С уважением,
А. Бородин.

Re: [Comm] exec startx

[ALT Linux User]

2008/3/12 Andrew Borodin <borodin@zarya-k.ru>:
> On Wed, Mar 12, 2008 at 04:51:44PM +0300, ALT Linux User wrote:
> > > Забудьте про startx, пишите всегда
> > > exec startx
>
> > Спасибо за совет.
> > Однако, проблема решена лишь частично, поскольку полной блокировки
> > доступа к сессии не происходит. Например, её всё так же можно
> > завершить по Ctrl+Alt+Backspace.
>
> > Нет ли какого-нибудь решения для этого?
>
> Уже упоминалось в этом треде.
>
> DontZap в xorg.conf.
>
> This  disallows  the use of the Ctrl+Alt+Backspace sequence.
> That sequence is normally used to terminate the Xorg server.
> When this option is enabled, that key sequence  has no special
> meaning and is passed to clients.  Default: off.

Подскажите, пожалуйста, а в каком месте xorg.conf и как это нужно вставить?

Re: [Comm] exec startx

[ua2fgb]

ALT Linux User пишет:
> 2008/3/12 Andrew Borodin <borodin@zarya-k.ru>:
>   
>> On Wed, Mar 12, 2008 at 04:51:44PM +0300, ALT Linux User wrote:
>>     
>>>> Забудьте про startx, пишите всегда
>>>> exec startx
>>>>         
>>> Спасибо за совет.
>>> Однако, проблема решена лишь частично, поскольку полной блокировки
>>> доступа к сессии не происходит. Например, её всё так же можно
>>> завершить по Ctrl+Alt+Backspace.
>>>       
>>> Нет ли какого-нибудь решения для этого?
>>>       
>> Уже упоминалось в этом треде.
>>
>> DontZap в xorg.conf.
>>
>> This  disallows  the use of the Ctrl+Alt+Backspace sequence.
>> That sequence is normally used to terminate the Xorg server.
>> When this option is enabled, that key sequence  has no special
>> meaning and is passed to clients.  Default: off.
>>     
>
> Подскажите, пожалуйста, а в каком месте xorg.conf и как это нужно вставить?
>
>   
Ответ содержится в мане на xorg.conf

Re: [Comm] Security hole in X (KDE)

[Алексей Синицын]

12.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):

> Как нет проблемы?
>  Пользователь работает в KDE. Заблокировал сессию, отшёл. Пришёл некто,
>  нажал Ctrl+Alt+Backspace и ушёл. Вернувшийся пользователь находит на
>  месте оставленной сессии предложение вновь залогиниться.
>
>  Это называется "нет проблемы"?
>

 Строго говоря да. Прохожий мог нажать ресет (независимо от ОС),
загрузиться с CD, скопировать данные (так-же, или больше того на лоре
недавно была ссылка про то как можно подключиться по usb или firewire
к залоченной win и спокойно получить управление). Утащить ноут не смог
потому-что мы его пристегнули цепочкой.

 При физическом доступе к машине вопросы безопасности опять-же меняются.

Re: [Comm] Security hole in X (KDE) -- not

[Michael Shigorin]

On Wed, Mar 12, 2008 at 12:40:40AM +0300, ALT Linux User wrote:
> > > > Подтверждаю то, что сам пользователь нашёл приключений на
> > > > свою голову и не использовал dm, как рекомендуют
> > > > специалисты по безопасности.
> > > IMHO это весьма спорный момент.
> > Нет.  Это весьма широко известный и не раз перетёртый в сети
> > момент.  Неохота тратить время только для поиска иллюстраций,
> > но их есть, в т.ч. по-русски.
> А разве от того, что момент уже обсуждался, он перестаёт быть
> спорным?

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

> > > Во-первых, не надо требовать многого от пользователя -
> > > пользователь этого, как известно, не любит.
> > Если не надо, то что он забыл в консоли?
> Связь ускользнула...

Пользователи, от которых "не надо требовать многого", в консоли
не водятся (эмпирически).

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

Не, я ж потому и предложил повесить FR, что в предупреждении
резон вижу.

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

Потому что это всё-таки линукс, а не винда или макось? :)

> Следуя проводимой здесь логике, если пользователь способен
> работать в консоли, значит может позаботиться о собственной
> секьюрности сам. Но тогда, такой пользователь и сам способен
> выставить init 3 в inittab?

Да.  Возможно, когда у нас опять появится expert mode -- 
эта галочка спрячется туда.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Comm] Security hole in X (KDE)

[ALT Linux User]

2008/3/12 Алексей Синицын <asinitsinster@gmail.com>:
> 12.03.08, ALT Linux User<altlinux.mailbox@gmail.com> написал(а):
>
> > Как нет проблемы?
> >  Пользователь работает в KDE. Заблокировал сессию, отшёл. Пришёл некто,
> >  нажал Ctrl+Alt+Backspace и ушёл. Вернувшийся пользователь находит на
> >  месте оставленной сессии предложение вновь залогиниться.
> >
> >  Это называется "нет проблемы"?
> >
>
>  Строго говоря да.

Если говорить строго, то как раз это - проблема. Осуществление
каких-либо действий без авторизации - проблема.

> Прохожий мог нажать ресет (независимо от ОС),
> загрузиться с CD, скопировать данные (так-же, или больше того на лоре
> недавно была ссылка про то как можно подключиться по usb или firewire
> к залоченной win и спокойно получить управление). Утащить ноут не смог
> потому-что мы его пристегнули цепочкой.

Что-то маловато фантазии... Ни тебе метеоритов, ни землятресений... Ну
хоть наводнение какое будет? Или там, Чубайс с кусачками?

>  При физическом доступе к машине вопросы безопасности опять-же меняются.

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

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 16:30 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 16:34 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 16:38 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 16:49 UTC (permalink / raw)]

[Comm] configurability at different experience levels

[@ 2008-03-12 16:54 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 16:56 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 16:57 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 17:23 UTC (permalink / raw)]

[Comm] [JT] Re: configurability at different experience levels

[@ 2008-03-12 17:28 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 17:30 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 17:38 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 17:45 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 17:48 UTC (permalink / raw)]

[Comm] [JT] обманутые ожидания

[@ 2008-03-12 17:56 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 18:03 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 18:10 UTC (permalink / raw)]

Re: [Comm] [JT] обманутые ожидания

[@ 2008-03-12 18:14 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 18:33 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 18:43 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 18:49 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 18:50 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 18:58 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 19:04 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 19:06 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 19:11 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 19:13 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-12 19:21 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 20:01 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE) -- not

[@ 2008-03-12 20:06 UTC (permalink / raw)]

[Comm] [2SR] Re: Security hole in X (KDE) -- not

[@ 2008-03-13 5:20 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-13 15:54 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 12:45 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 13:24 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 15:22 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 15:33 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 20:42 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 20:52 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 20:56 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 20:58 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:03 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:09 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:10 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:19 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:24 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:31 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:41 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:43 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 21:59 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:05 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:14 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:19 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:23 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:24 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:29 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:40 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:49 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 22:53 UTC (permalink / raw)]

Re: [Comm] Security hole in X (KDE)

[@ 2008-03-16 23:25 UTC (permalink / raw)]

[Comm] Administrativia

[@ 2008-03-16 23:43 UTC (permalink / raw)]