Hello,

Apparently someone suddenly got a good idea that you need to be root to reprogram the keyboard, and got a patch merged into the Linux kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0b360adbdb54d5b98b78d57ba0916bc4b8871968

The result is that the keyboard unit is no longer able to catch keys like escape, shift+tab alt+F1..F12 etc. on the Linux console. This affects the Free Pascal IDE and any other program using the keyboard unit.

Daniël

Daniël Mantione wrote

Apparently someone suddenly got a good idea that you need to be root to

[snip]

The result is that the keyboard unit is no longer able to catch keys like escape, shift+tab alt+F1..F12 etc. on the Linux console. This affects the

Perhaps the programming can be reverted when the process that reprogrammed it, exits ?

Micha

Op Fri, 13 Jul 2007, schreef Micha Nelissen:

Indeed. A secure way would be to have mingetty and friends reprogram the keyboard into a known state once a user logs out. It also reverts tty and vcsa permissions into a known state, so I don't think this patch was necessary. Otoh, getting it removed is going to be hard I fear :/

Daniël

I must admit, kernel developers do a really good job to piss off people, we can't do better.

The linux kernel developpers are actually not a new phenomena. They have been described in great detail in The Hitchhiker's Guide to the Galaxy (http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy) under the name of "Sirius Cybernetics Corporation"
(http://en.wikipedia.org/wiki/Sirius_Cybernetics_Corporation). I discovered this truth some time ago when the idiots changed something in the kernel and broke Kylix's debugger. Please refer to the Guide for possible solutions to the problem.

I think that together with the debian gpm crap it's safe to flag linux as a non-target for the IDE and be done with it. It's IMHO not worth anyone's nerves to try and hit this moving tty/console target anymore...

Ales

Op Fri, 13 Jul 2007, schreef Ales( Katona:

I think that together with the debian gpm crap it's safe to flag linux as a non-target for the IDE and be done with it. It's IMHO not worth anyone's nerves to try and hit this moving tty/console target anymore...

Well, I need the IDE for compiler development, so it has to work for at least me.

Daniël

Install the IDE setuid. When sb complains, ask for the alternative.

Peter Popov wrote

The linux kernel developpers are actually not a new phenomena.

In my university we were once trying to build a linux driver for an ISA board we had constructed, but it wouldn't work in anyway! we studyed the problem hours after hours and nothing ... everything on the Net and the kernel docs said it should work.

It turns out someone had removed some of the ISA code from the kernel a few revisions before the revision we were using .... simply building a sligtly older kernel made it work. (and we were using 2.4 just to get the ISA functions!)

That would be an extremely bad idea with the current stability record of the IDE.

Jonas

Jonas Maebe wrote

> Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE.

Not to mention that it allows you to open and overwrite any arbitrary file.

Jonas

Looking at that kernel patch, I see that it requires not uid=0, but rather certain caller's capability present.
I don't have deep knowledge of the subject, but 'capability' sounds like 'privilege' (in Windows terms) for me. If it is so, then probably there is a way to solve the problem by assigning the required capability to IDE user(s) or process.

Sergei

Yes. Just like we all have for decades. And no, it is not ideal, but apparantly that is what the kernel devels want as the only way to access the full terminal capability.

minor breakage is mentioned, you should have tried an mm kernel and complained :-)

http://www.ussg.iu.edu/hypermail/linux/kernel/0510.2/0483.html

Like everything these woolheads think of, it is very nice for trained admins, and people used to read kernel lists, how-to's (and spend overly amounts of time on it).

However the problem is that this kind of paranoia (since I assume currently it is only allowed for people using a valid tty handle) creates enormous deployment problems.

What is the security hole exactly?

Or does Linux allow any user to change kbd, even if he is not on the console?

No, we haven't.

If you install the IDE as setuid root, then every user starting the IDE will run the IDE as if he were root. That means he can open and modify every single file on the system. And overwrite any binary with an own written program by just configuring the proper exe output directory in the IDE.

And by using the shell functionality of the IDE, he can also open a root shell if that's more comfortable for him than using the IDE itself.

Jonas

While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues...

You cannot distribute a tool which creates a security hole as large as from here till Tokio. That would not look good the day it is discovered, and arguments like "the kernel forcing us to do so" will not help us then.

It just means you'll have less functionality.
How does midnight commander solve it? As far as I know, it also has strange keyboard combinations ?

Michael.

Yes, exactly. And as far as I know, this is one of the most common complaints from people used to other NC-like managers running on other systems (compare this to users used to TP/BP IDE). That's actually a very good example. ;-)

Tomas

While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues...

This has nothing at all to do with "pr trouble", but with not installing a local rootkit with every FPC install.

I'm just speechless, I really can't believe what I'm reading here...

Jonas

That might indeed be slightly too much. OTOH it would make an important point :-)

Seriously, in how many distro's is this "feature" active? Can it be turned off?

Can we assume that desktop distro's as ubuntu aren't going to do this?

Why? If they allow it it's their problem. If there's no sane way to do something and we do it this way it's their problem that it's allowed...

I just don't see as how this whole thing is "our" problem.

I guess we could ask on install, "do you want a rootkit or no shortcuts?"...

Jonas Maebe wrote / napísal(a):

Oh and btw, setuid is generaly used afaik. It's a normal thing to allow temporary root access on normal programs in linux. Ofcourse doing it on something like fpIDE is somewhat questionable (heh the possibilities :D), but I don't see it as such a great risk. The more I think about it it's pretty valid for desktop users, altough they should be asked about it I guess.

Ofcourse if there IS a better way...

And to add to my last setuid stuff.. I think that if we properly audit the IDE code so that:

a) fpc is called in the uid of the original ide starter b) the "console" is run in the uid of the original ide starter c) compiler programs are called in the uid of the original IDE starter

I think it's ok to use setuid after these. Ofcourse, depending on how the IDE executes all the externals, it might be a trouble. But if we do some typical fork, it shouldn't be so difficult (I'm willing to do this should we decide to go this route).

Ales

Sorry for joining the discussion so late, but what special key combos are we talking about? And what changed in the kernel?

I agree that it does sound absurd to require root privs - and of course it goes without saying that the IDE _cannot_ under any circumstance be distributed to run as +s, it just cannnot happen, period.

These privileges that we are talking about, are they transferrable between processes? In that case, we could write a small setuid wrapper to setup the terminal, then exec the IDE without privs.

Under any circumstance, if there really isn't any New And Improved way to do this sans root, we should bring it up on the kernel mailing list. I can do that, if need be - I'm always quite interested in security matters.

Ales wrote

While I agree that it could cause some PR trouble, I don't see how this is our problem. It's not like anyone blames the software makers for windows security issues...

You cannot seriously mean that. I agree 100% with Jonas here. PLEASE rethink your position Ales :-)

Why? You have your good ol' PING doing it. I agree tho that if a wrapper can do it for us it's safest. Or if the ide can do it on start, and always setuid(userid) itself right after setting the proper things. I don't see a problem with ANY program being setuid if it has a proper reason, and is audited for it.

But as I sayed a wrapper, of if there's a non-setuid way then of course that should be used.

You cannot seriously mean that. I agree 100% with Jonas here. PLEASE rethink your position Ales :-)

There is absolutely no clean way to use setuid in a program the size of the IDE. Trust me.

It is vaguely possible that a very small (think "less than 100 LOC") wrapper could be generated, which will simply set certain configuration parameters of the PTY that the IDE is attached to. I imagine that this would work.

This could be distributed, and called from the IDE after startup. The entire IDE would then be run completely as normal, by the user.

Even with such a small wrapper, one would have to put a big fat warning in the README file and similar places. In the Debian package, debconf should ask the user if s/he is ok with installing a suid program.

If this is not feasible, then the IDE will have to be redistributed with reduced functionality. You just cannot compromise when it comes to security matters. Ever.

Ales wrote

Why? You have your good ol' PING doing it.

Unbelievable strawman argument there.

This is not at all a critique of the IDE, but please don't compare the complexity of "ping" and "fpide"(!)

I agree tho that if a wrapper can do it for us it's safest. Or if the ide can do it on start, and always setuid(userid) itself right after setting the proper things. I don't see a problem with ANY program being setuid if it has a proper reason, and is audited for it.

There is a very serious limit as to how many lines of code one can audit. A project the size of the IDE is unauditable, given it's size. This again is not meant to criticize the IDE - any project of the size is unauditable.

Strawman yes, but if we setuid to userid right after setting the console stuff, there's nothing left to audit. We're not malicious software makers so there's no chance anything else could happen? Or am I missing something here?

eg:

fp starts
fp sets itself to uid 0
fp sets the required things as root
fp sets itself to original userid
fp finishes init

I don't see a problem with that. It's not nice to have a suid binary requirement, but if there's no other way?

Christian Iversen wrote / napísal(a):

If there's no other way, it would still be nicer to have the suid code in an entirely seperate executable. Running any complex program as suid always makes me nerveous - and yes, I very much would have second thoughts about even running the from that, your plan could work. I just really, really hope we find some other way.

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

Probably Midnight Commander doesn't solve it. Ctrl+arrows works in mc, but I expect them to use the TIOCLINUX, subfunction 6, to get the shift states. The keyboard unit makes use of this ioctl too, but it ain't enough to catch combinations like alt+fx, escape without delay, and being able to tell the difference between F11 and shift+F1. I believe mc doesn't do this.

Still, there is the semiraw mode, which is another way to catch keys, but the semi raw mode has the disadvantage that it is keymap ignorant. You need your own keymaps like XFree86 (XFree86 probably uses semi-raw, or full raw mode).

Daniël

Op Wed, 18 Jul 2007, schreef Sergei Gorelkin:

Yes, you need a certain capability, but in practise this means you must be root. This is because:

* You can only drop a capability, not get a capability as a process.
* Root has all capabilities, users don't have any capabilities.

However, there is the SETPCAP capability, where a process can set the capabilities of another process. So, a setuid helper program cuild assign the needed capability if certain conditions are met. Unfortunately due to a security hole SETPCAP has been revoked from even root. Without kernel modification this possible solution is unfortunately sabotaged.

Daniël

Under the assumption a setuid root program is the only possible option:

The safest - and in my opinion only correct - way is to write a small setuid root program which sets the proper TTY stuff, and then executes the IDE as the normal user.

The program can easily be audited, as it'll be maybe 50 lines of code...

Michael.

Op Wed, 18 Jul 2007, schreef Jonas Maebe:

A possible way out is to install the IDE setuid root, then drop all capabilities except the right one and change uid. It is not a good solution, because then every program using the keyboard would need such a trick and I'm sure one of your users will code a security hole sooner or later this way.

However, for the IDE itself, it could be effective.

Daniël

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

If the user switches VT, the keyboard needs to be unpatched. So this approach won't fully work. However, a solution that can work is to make the keyboard unit execute a setuid root helper to which it communicates through a pipe.

Daniël

I object to this; The keyboard unit should not be able to do this in the first place. It's supposed to be read-only. If the linux kernel does not allow you any more to trap some weird key combinations unless you are root, well then that's it... If you want to use these keys, you'll have to run your programs as root...

Or use a GUI IDE like Lazarus...

Michael.

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

You just proposed this yourself, but before executing the IDE?

Daniël

? I proposed to use a small wrapper program, which does an Exec() after setting the proper TTY properties. Not set up a communication channel with a setuid root program. The solution is worse than the problem then...

Michael.

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

What is bad about such a solution?

Daniël

It's not KIS. If you can't have certain keys without being root, well then you'll have to learn to live with it. This is no longer the MS-DOS age when everything was possible. It's a shortcoming of the platform, and for me this is the end of the story. The keyboard unit should in no way set up such a communication channel; if you absolutely want that, you can set it up for the IDE (I don't use it anyway), but not for the standard keyboard driver unit. Develop a driver that handles this, and use that in the IDE.

I can agree that some of the Linux kernel developers are braindead - seeing what they have done - but I don't think we should go out of our way to fix that. Rather, we should request that they implement a decent keyboard interface which allows you to detect properly the state of all keys on the terminal which you are currently using.

Michael.

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

The "scary" thing is the setuid root. The communication channel can be standard i/o and there is nothing scary about that.

Yes, I agree all kinds of hacks suck. However, the situation with Unix keyboard is not "if" there should be hacks, but to what extend you go. I.e. you can enable xterm "meta sends escape" with an escape sequence to allow detecting alt-key combinations. However some xterms already do this by default and start sending double escapes. We detect this with an ugly hack.

Some people go much further I.e. you can bypass xterm limitations by opening a stealth connection to the X server and many people are doing it. However, this went too far for me for now.

Unfortunately Unix and keyboards is one hell, like it or not. There is no proper "API" and you have to work around things to get work done.

By the way, I have started to talk to Andrew Morton and his reply was constructive. Perhaps a proper solution is possible after all.

Daniël

There is: a user using the keyboard unit should then distribute the (setuid) program too, and that is not acceptable. (not for me as an FPC developer, and most likely also not fot the user) So if you want to go through with this, develop a separate keyboard driver for linux console that can catch all keys. But not the standard driver.

I understand. But spawning an external setuid process and talking to that just to get a text mode thing working in some weird cases is not one, but two bridges too far for me...

I mean, seriously, how many people develop on the Linux console ? You can't even open a browser then ! I expect most people do their work in an X-Term if they use the fp ide...

By the way, I have started to talk to Andrew Morton and his reply was constructive. Perhaps a proper solution is possible after all.

Great, that is the way to go !!

Please, keep us updated on any progress you make on this :-)

Michael.

Op Wed, 18 Jul 2007, schreef Michael Van Canneyt:

Yes, but again no difference from a wrapper that launches the program. I fully agree that it would suck to have to distribute such a wrapper or helper and that it would need to be optional.

Many people indeed use X. But on the Linux console, thanks to fbdev, you can get a really comfortable text mode (i.e. 1024x768 with a high res 8x16 font is still a 128x48 text mode). This makes make you can see large amounts of source at the same time, combined with a speed and responsiveness of a text mode UI.

Compared to xterm, you get the VGA character set instead of the limited VT100 character set and the keyboard works better (for example shift+tab is impossible in xterm).

Therefore, console is popular as well.

Sure!

Daniël

Ales wrote: A project the size of the IDE is unauditable, given it's size. This again is not meant to criticize the IDE - any project of the size is unauditable.

Not that it is doable for us for the IDE, but OpenBSD seems to think otherwise.

But I still think not making a separation between server related and desktop security in Linux is the big problem.

People that feel limited by all kinds of security features turn stuff of at random. These kinds of petty changes only increase the risk.

This would introduce quite some linux specific code on a lot of already complicated points to the IDE.

IMHO either give up the textmode IDE, or try to support it to the fullest extend.

This is no longer the MS-DOS age when everything was possible.

"everything" being using the standard keyboard type that is around for 15 years.

(skip this if you hate rants)

Why bother with more advanced keyboard at all then? The platform obviously is not fond of simple keyboard systems or unit keyboard would not be several thousand lines. Maybe we should repatch the IDE to a VI mode so we can kill function keys:-)
)

Rather, we should request that they implement a decent keyboard interface which allows you to detect properly the state of all keys on the terminal which you are currently using.

Definitely. And that was also one of the points I wanted to make when I made the half serious setuid remark.

The problem should be propagated back, specially if it is configurable in the kernel. Maybe it will at least make some distro packagers of more desktop distroes aware of the problem.

Therefore, console is popular as well.

I second this! So far I've using FPC to develop server-side application (using PSP/PWU) which has no X installed on the server machine and I only have SSH access to the machine. fpIDE is the best text mode IDE on Linux.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Bisma Jayadi wrote

(using PSP/PWU) which has no X installed on the server machine and I only have SSH access to the machine. fpIDE is the best text mode IDE on Linux.

But SSH access means using a vt100 kind of terminal, not the linux console aka linux framebuffer.

Micha

That can be, but these calls will do you no good, they are only needed if you use the physical console, as far as I know; Not if you use a pty.

Michael.

I'm not so sure - refreshing the keyboard and video status after coming back from a spawned program or shell should be provided as a standard functionality within InitKeyboard and InitVideo calls, shouldn't it?

Tomas

In general, yes. But this complicates the matter because not all kbd programs need it (only the ones that patch), and in general it goes way beyond a simple state save, with all its IPC.

Last time i tried I was not able to get the state the terminal is in, for example white on black or black on white. Consequently, you can only reset it to its default state, when you are done, which might be different from what is was before you started.

Sure, because it's a product written from the ground up with security in mind, by security freaks eating and breathing security.

That's simply not the focus of FPC, nor should it be, necessarily.

But I still think not making a separation between server related and desktop security in Linux is the big problem.

I don't think that's exactly right. On server-distros there typically ARE more security features enabled.

People that feel limited by all kinds of security features turn stuff of at random. These kinds of petty changes only increase the risk.

That's a luser problem, but I somewhat agree with your point.

Anyway, this is a pretty dead horse. Let's hope Andrew Morton can help us solve this the right way - in the kernel.