Recently I muttered a little bit about the fact that everybody who
can mount filesystems using an "auto" fstab filesystem type entry
(or using e.g. an "ext2" entry) can crash the system.
But nobody on lk seems impressed.
Of course, one can always say that it is the distribution's fault,
or the sysadmin's fault to have such fstab entries.
Still, I think the situation can be improved.
On the other hand, I am told that recent kernels restrict the use of
loadkeys to root. If so, an unfortunate choice. People want to switch
unicode support on/off, or go from/to a dvorak keymap.
What was the security problem? I understand the reasoning was that
someone could invent malicious function key bindings, and leave those
for the user that logs in after him. Yes, true.
But my solution would be in user space, not by crippling the kernel.
If it is necessary that a user who logs in gets a default environment
at login time, that is the responsibility of login, not of the kernel.
It is very easy to arrange such things, and of course in places where
some but not all of the users use dvorak, such things are done already
today.
I have been going away from Linux for a while now - gave most of my
packages to other maintainers - but there is still kbd.
If someone is willing to maintain it, please tell me. A new version
is required because 2.6 has broken a number of things.
Andries
Andries Brouwer <[email protected]> wrote:
> Recently I muttered a little bit about the fact that everybody who
> can mount filesystems using an "auto" fstab filesystem type entry
> (or using e.g. an "ext2" entry) can crash the system.
> But nobody on lk seems impressed.
> Of course, one can always say that it is the distribution's fault,
> or the sysadmin's fault to have such fstab entries.
> Still, I think the situation can be improved.
Yes, by fixing the file systems or by implementing safe user mounts. It will
be something like fuse, maybe it will be fuse using a userspace version
of a kernel thread. Maybe not.
> On the other hand, I am told that recent kernels restrict the use of
> loadkeys to root. If so, an unfortunate choice. People want to switch
> unicode support on/off, or go from/to a dvorak keymap.
> What was the security problem?
It's global, and it can be done remotely. Therefore you can either have
remote logins or a secure console.
The correct fix would be binding the keymap to the current tty only,
resetting the console if it gets closed and not allowing init to reuse
it unless it's closed. If you do this, you'll want a default setting, too.
YANI: Root should be able to set a coloured border indicating that it's
really the getty/login process asking for the user prompt/password.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On Sat, Dec 03, 2005 at 01:21:51AM +0100, Bodo Eggert wrote:
> > On the other hand, I am told that recent kernels restrict the use of
> > loadkeys to root. If so, an unfortunate choice. People want to switch
> > unicode support on/off, or go from/to a dvorak keymap.
>
> It's global, and it can be done remotely. Therefore you can either have
> remote logins or a secure console.
Let me repeat what I said and you snipped:
If there is a security problem, then it should be solved in user space.
Some people actually use the console. They want to be able to reassign
CapsLock, set their own function keys, set dvorak keymap etc.
It is a bad idea to restrict that functionality to root.
There are a thousand things one can do to put the kernel keyboard/console
in an interesting state. The solution is to have init/getty/login reset
state to a useful initial state. Not to have the kernel forbid one
to change the settings of the very keyboard one is typing on.
Andries
> The correct fix would be binding the keymap to the current tty only,
> resetting the console if it gets closed and not allowing init to reuse
> it unless it's closed. If you do this, you'll want a default setting, too.
Yes.
> YANI: Root should be able to set a coloured border indicating that it's
> really the getty/login process asking for the user prompt/password.
Didnt I show a "bleeding edge" patch some April 1st or so?
At least I had a red border on some console a few years ago.
The patch must still exist somewhere. I seem to recall that Paul Gortmaker
submitted a somewhat more general version.
---
marc.theaimsgroup.com tells me that the change was due to horms and akpm.
Let me cc them and see whether they have reasons why this had to be done
in kernel space.
On Sat, 3 Dec 2005, Andries Brouwer wrote:
> On Sat, Dec 03, 2005 at 01:21:51AM +0100, Bodo Eggert wrote:
> > > On the other hand, I am told that recent kernels restrict the use of
> > > loadkeys to root. If so, an unfortunate choice. People want to switch
> > > unicode support on/off, or go from/to a dvorak keymap.
> >
> > It's global, and it can be done remotely. Therefore you can either have
> > remote logins or a secure console.
>
> Let me repeat what I said and you snipped:
> If there is a security problem, then it should be solved in user space.
By killing and disabeling all remote logins when root logs in or by
ptracing each user program during root sessions? You'd have to do this
untill we find somebody to do the correct fix in the kernel.
> Some people actually use the console. They want to be able to reassign
> CapsLock, set their own function keys, set dvorak keymap etc.
> It is a bad idea to restrict that functionality to root.
You can allways chmod u+s `type -p keymap`, but you'll take the blame.
> There are a thousand things one can do to put the kernel keyboard/console
> in an interesting state. The solution is to have init/getty/login reset
> state to a useful initial state.
This is not enough, since it's a global setting. At least, it used to be
when I last looked. loadkeys doesn't complain when run from an xterm,
therefore I asume nobody changed this. I can't change to the console since
ati sucks.
> Not to have the kernel forbid one
> to change the settings of the very keyboard one is typing on.
> > The correct fix would be binding the keymap to the current tty only,
> > resetting the console if it gets closed and not allowing init to reuse
> > it unless it's closed. If you do this, you'll want a default setting, too.
>
> Yes.
Unfortunartely nobody dares to implement this.
> > YANI: Root should be able to set a coloured border indicating that it's
> > really the getty/login process asking for the user prompt/password.
>
> Didnt I show a "bleeding edge" patch some April 1st or so?
It's a bad day for presenting a usefull patch. It's one thing where
windows was ahead security-wise and which unices usurally lacked.
Off cause the CTRL-ALT-DEL secure screen is about to be disabled, so we
can measure up to[0] windows by waiting.-)
[0] The translations of "gleicgziehen" by dict.leo.org seem strange.
--
If at first you don't succeed, call it version 1.0
On Sat, Dec 03, 2005 at 03:11:42AM +0100, Bodo Eggert wrote:
> On Sat, 3 Dec 2005, Andries Brouwer wrote:
> > Didnt I show a "bleeding edge" patch some April 1st or so?
>
> It's a bad day for presenting a useful patch.
Hardly useful. Somewhat funny. I just looked - it was April 1st, 2002.
> > Let me repeat what I said and you snipped:
> > If there is a security problem, then it should be solved in user space.
>
> By killing and disabeling all remote logins when root logs in or by
> ptracing each user program during root sessions? You'd have to do this
> until we find somebody to do the correct fix in the kernel.
Please describe the perceived security problem.
I see words, but no problem.
You log in remotely to my machine. Want to do something evil.
What precisely do you do?
2.0.34% loadkeys -d
Couldnt get a file descriptor referring to the console
How do you propose this remotely logged-in non-root gets access to
a console file descriptor?
Andries
On Sat, 3 Dec 2005, Andries Brouwer wrote:
> On Sat, Dec 03, 2005 at 03:11:42AM +0100, Bodo Eggert wrote:
> > On Sat, 3 Dec 2005, Andries Brouwer wrote:
> > > Let me repeat what I said and you snipped:
> > > If there is a security problem, then it should be solved in user space.
> >
> > By killing and disabeling all remote logins when root logs in or by
> > ptracing each user program during root sessions? You'd have to do this
> > until we find somebody to do the correct fix in the kernel.
>
> Please describe the perceived security problem.
> I see words, but no problem.
> You log in remotely to my machine. Want to do something evil.
> What precisely do you do?
echo -e 'keycode 28 F70
string F70 ";rm -rf /\x0a"' | loadkeys > /proc/0815/fd/1
where process 0815 is a "sleep 2147483647&"
> 2.0.34% loadkeys -d
> Couldnt get a file descriptor referring to the console
I had stale permissions on /dev/tty0. With correct permission settings,
you'll need a session belonging to the malicious user.
--
'Calm down -- it's only ones and zeros.'
On Sat, Dec 03, 2005 at 06:33:51AM +0100, Bodo Eggert wrote:
> > Please describe the perceived security problem.
> > You log in remotely to my machine. Want to do something evil.
> > What precisely do you do?
>
> echo -e 'keycode 28 F70
> string F70 ";rm -rf /\x0a"' | loadkeys > /proc/0815/fd/1
>
> where process 0815 is a "sleep 2147483647&"
I already told you the result:
loadkeys: Couldnt get a file descriptor referring to the console
> I had stale permissions on /dev/tty0. With correct permission settings,
> you'll need a session belonging to the malicious user.
Aha. So it seems you withdraw the "remote" part, and say that
a local user can leave a process with an open filedescriptor
on a console, and that process can be used to access the console
later. True.
But there are many ways of using such a file descriptor.
This patch cripples the keymap changing but does not solve anything.
The basic problem is that some things are common for all virtual
consoles, while on the other hand vhangup() on one VC does not
influence the other VCs.
Probably those common parts should be split and made per-VC.
Andries
On Sat, 3 Dec 2005, Andries Brouwer wrote:
> On Sat, Dec 03, 2005 at 06:33:51AM +0100, Bodo Eggert wrote:
>
> > > Please describe the perceived security problem.
> > > You log in remotely to my machine. Want to do something evil.
> > > What precisely do you do?
> >
> > echo -e 'keycode 28 F70
> > string F70 ";rm -rf /\x0a"' | loadkeys > /proc/0815/fd/1
> >
> > where process 0815 is a "sleep 2147483647&"
>
> I already told you the result:
>
> loadkeys: Couldnt get a file descriptor referring to the console
>
> > I had stale permissions on /dev/tty0. With correct permission settings,
> > you'll need a session belonging to the malicious user.
>
> Aha. So it seems you withdraw the "remote" part, and say that
> a local user can leave a process with an open filedescriptor
> on a console, and that process can be used to access the console
> later. True.
You can trigger it remotely after launchning the process:
Failed case:
$ chroot . ./strace ./loadkeys -d
...
open("/dev/tty", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/tty0", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/vc/0", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/console", O_RDWR) = -1 ENOENT (No such file or
directory)
ioctl(0, 0x4b33, 0xbf8382d3) = -1 EINVAL (Invalid argument)
ioctl(1, 0x4b33, 0xbf8382d3) = -1 EINVAL (Invalid argument)
ioctl(2, 0x4b33, 0xbf8382d3) = -1 EINVAL (Invalid argument)
write(2, "Couldnt get a file descriptor re"..., 55Couldnt get a file
descriptor referring to the console
) = 55
munmap(0x4014d000, 4096) = 0
exit_group(1) = ?
$
Success:
$ chroot . ./loadkeys -d < proc/6903/fd/1
Loading /usr/share/kbd/keymaps/defkeymap.map.gz
$ chroot . ./strace ./loadkeys -d < proc/6903/fd/1
...
open("/dev/tty", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/tty0", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/vc/0", O_RDWR) = -1 ENOENT (No such file or
directory)
open("/dev/console", O_RDWR) = -1 ENOENT (No such file or
directory)
ioctl(0, 0x4b33, 0xbfaa2493) = 0
munmap(0x4014d000, 4096) = 0
exit_group(0) = ?
$
> But there are many ways of using such a file descriptor.
> This patch cripples the keymap changing but does not solve anything.
Obviously it solves only a part. OTOH you can't keep an exploit open just
because there is another exploit. Like I said, use chmod u+s loadkeys.
> The basic problem is that some things are common for all virtual
> consoles, while on the other hand vhangup() on one VC does not
> influence the other VCs.
>
> Probably those common parts should be split and made per-VC.
ACK. Congrats to volunteering :-)
--
"If you see a bomb technician running, follow him."
-U.S.A.F. Ammo Tech Sgt
On Sat, Dec 03, 2005 at 06:19:47PM +0100, Bodo Eggert wrote:
> > But there are many ways of using such a file descriptor.
> > This patch cripples the keymap changing but does not solve anything.
>
> Obviously it solves only a part. OTOH you can't keep an exploit open just
> because there is another exploit.
> Like I said, use chmod u+s loadkeys.
Hmm. There is an obscure security problem. It was fixed in a bad way -
people want to say unicode_start and unicode_stop and find that that
fails today. Ach.
You argue "you can't keep an exploit open" - but as far as I can see
there is no problem that needs solving in kernel space.
For example - today login does a single vhangup() for the login tty.
In case that is a VC it could do a vhangup() for all VCs.
That looks like a better solution.
And "chmod u+s loadkeys" - you can't be serious..
On Sat, 3 Dec 2005, Andries Brouwer wrote:
> On Sat, Dec 03, 2005 at 06:19:47PM +0100, Bodo Eggert wrote:
> > > But there are many ways of using such a file descriptor.
> > > This patch cripples the keymap changing but does not solve anything.
> >
> > Obviously it solves only a part. OTOH you can't keep an exploit open just
> > because there is another exploit.
> > Like I said, use chmod u+s loadkeys.
>
> Hmm. There is an obscure security problem. It was fixed in a bad way -
> people want to say unicode_start and unicode_stop and find that that
> fails today. Ach.
>
> You argue "you can't keep an exploit open" - but as far as I can see
> there is no problem that needs solving in kernel space.
> For example - today login does a single vhangup() for the login tty.
> In case that is a VC it could do a vhangup() for all VCs.
> That looks like a better solution.
I tried this, but
1) vhangup doesn't seem to close file descriptors, so it won't help
against the exploit
2) even if it did, the behaviour you described would kill all console
sessions at once when you terminate one, which is very undesirable
3) it wouldn't prevent sb from running 'exec sleep 2147483647' and
changing to another console hoping nobody notices.
> And "chmod u+s loadkeys" - you can't be serious..
Allow the specific commmands by sudo/su1.
--
Top 100 things you don't want the sysadmin to say:
71. Ooops.
On Sat, Dec 03, 2005 at 07:48:19PM +0100, Bodo Eggert wrote:
> > You argue "you can't keep an exploit open" - but as far as I can see
> > there is no problem that needs solving in kernel space.
> > For example - today login does a single vhangup() for the login tty.
> > In case that is a VC it could do a vhangup() for all VCs.
> > That looks like a better solution.
>
> I tried this, but
> 1) vhangup doesn't seem to close file descriptors, so it won't help
> against the exploit
Yes, it does. The permission test was
current->signal->tty == tty
and even if the file descriptor may still be open, after a vhangup
the loadkeys call fails.
> 2) even if it did, the behaviour you described would kill all console
> sessions at once when you terminate one, which is very undesirable
Your definition of desirable is not mine. In all cases it is bad
to put policy in the kernel. Policy belongs in user space.