headers
Samuel Thibault | 8 Jan 20:50
Gravatar

Re: FOSDEM 2008

Hello,

Just a reminder:

Thomas Schwinge, le Wed 07 Nov 2007 20:20:54 +0100, a écrit :
> Already some weeks ago I installed a
> coordination page into the wiki:
> <http://www.bddebian.com/~wiki/community/meetings/fosdem_2008/>.  Please
> add yourself.
> 
> 
> If we want to stay in an appartment this year, instead of again staying
> in a youth hostel, we'd need someone to organize that.

No news about this?

Samuel
Permalink | Reply | 0 comments |
headers
Thomas Schwinge | 11 Jan 11:58
Picon

Re: FOSDEM 2008

Hello!

On Tue, Jan 08, 2008 at 07:50:52PM +0000, Samuel Thibault wrote:
> Just a reminder:
> 
> Thomas Schwinge, le Wed 07 Nov 2007 20:20:54 +0100, a écrit :
> > Already some weeks ago I installed a
> > coordination page into the wiki:
> > <http://www.bddebian.com/~wiki/community/meetings/fosdem_2008/>.  Please
> > add yourself.

... or tell someone else with a wiki account to add you.

Marcus and I as well intend to arrive one or two days before FOSDEM and
leave one or two days after.  The same procedure as every year.  Not set
in stone yet, but that's the idea.

> > If we want to stay in an appartment this year, instead of again staying
> > in a youth hostel, we'd need someone to organize that.
> 
> No news about this?

Not from my side, no.  But as long as we don't even know who'll be
attending FOSDEM, we can't make any decision whether to rent an
appartement or not, in my opinion.

Regards,
 Thomas

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Bas Wijnen
 | 
18 Jan 17:39






Picon

Favicon





User sessions, system request


Hi,

It's been a while since anything happened here.  I haven't had any
comments about my kernel, which I found disappointing (I talked a bit
about it with Marcus, so I didn't expect new comments from him, but I
had expected some from others like Jonathan).  Therefore I didn't do
much with it for some time, but I'm now picking it up and maybe even
making it usable for some limited real-life purposes.

Because of this, I have been thinking of session management.  Since this
is not at all specific to my kernel, I think it is nice to have a
discussion about it on this list.  After all, I want the best solution,
and we want that in the new Hurd as well. :-)

So, what's it all about?  I'm talking about the programs which sit
between {the kernel and the device drivers (mostly TCB stuff)} and
{applications}.  Things in between there have to do with switching
between users, starting up and closing down programs, those sort of
things.  Here are my thoughts about how some things can be handled here:

First of all, about the hardware.  There must be a dedicated piece of
hardware to do a "system request".  This should get the user to a menu
with some system options.  The program must not be able to detect that
the user does this (unless the user specifically allows it to, which may
in some cases be done for performance reasons).  This menu has options
like "kill program" and "add permission to access [resource]".  Some of
these options may also be accessible from within programs, but they must
be reliably available for the user in a way that programs cannot fake.

And in a way the program cannot detect.  For example, the alt-SysRq was

(Continue reading)






Permalink
| Reply
| 11 comments  
| 



  

  

  





headers


olafBuddenhagen
 | 
18 Jan 17:27






Picon





Re: FOSDEM 2008


Hi,

On Fri, Jan 11, 2008 at 11:58:53AM +0100, Thomas Schwinge wrote:
> On Tue, Jan 08, 2008 at 07:50:52PM +0000, Samuel Thibault wrote:
> > Thomas Schwinge, le Wed 07 Nov 2007 20:20:54 +0100, a écrit :

> > > If we want to stay in an appartment this year, instead of again
> > > staying in a youth hostel, we'd need someone to organize that.
> > 
> > No news about this?
> 
> Not from my side, no.  But as long as we don't even know who'll be
> attending FOSDEM, we can't make any decision whether to rent an
> appartement or not, in my opinion.

It is hard enough to get people to commit if you already have stuff
organized. It's hopeless if you are still in "we could..." phase.
Really. I've seen it often in other similar cases. You can tell people
five times in a row that you need them to commit. You can whine as much
as you want that you can't plan without prior commitment. It won't help.

There is always some uncertainty in such matters. But I have little
doubt we could get a reasonable number of people together *if* somebody
would actually take up organising it. It's all about taking initiative.
However it seems there is nobody able and/or willing to do so, and
consequently the matter is pretty much settled...

-antrik-






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Banck
 | 
29 Jan 14:18






Picon

Gravatar





Re: FOSDEM 2008


On Fri, Jan 18, 2008 at 05:27:36PM +0100, olafBuddenhagen <at> gmx.net wrote:
> There is always some uncertainty in such matters. But I have little
> doubt we could get a reasonable number of people together *if* somebody
> would actually take up organising it. It's all about taking initiative.
> However it seems there is nobody able and/or willing to do so, and
> consequently the matter is pretty much settled...

So basically what you are saying is that you are unwilling to organize
it.

Michael






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


olafBuddenhagen
 | 
30 Jan 06:54






Picon





Re: User sessions, system request


Hi,

On Fri, Jan 18, 2008 at 05:39:12PM +0100, Bas Wijnen wrote:

> It's been a while since anything happened here.  I haven't had any
> comments about my kernel, which I found disappointing (I talked a bit
> about it with Marcus, so I didn't expect new comments from him, but I
> had expected some from others like Jonathan).

I was pretty amazed by what you had done there... And I really didn't
know what to say. Look at it in a positive light: It was so convincing
that there was nothing left to add or to dissent from... ;-)

> There must be a dedicated piece of hardware to do a "system request".
> This should get the user to a menu with some system options.  The
> program must not be able to detect that the user does this (unless the
> user specifically allows it to, which may in some cases be done for
> performance reasons).  This menu has options like "kill program" and
> "add permission to access [resource]".  Some of these options may also
> be accessible from within programs, but they must be reliably
> available for the user in a way that programs cannot fake.
> 
> And in a way the program cannot detect.  For example, the alt-SysRq
> was pretty much designed for this purpose.  However, it is unusable:
> if we find out that a program is malicious, and we want to stop it
> immediately, pressing alt-SysRq means first pressing alt, which the
> program can see.  In response, it can do its worst (thinking it's
> about to die anyway).  This must be avoided.

To be honest, the bit about Alt sounds a bit too paranoid to me...

(Continue reading)






Permalink
| Reply
| 9 comments  
| 



  

  

  





headers


Jonathan S. Shapiro
 | 
30 Jan 16:46





Re: User sessions, system request


On Wed, 2008-01-30 at 06:54 +0100, olafBuddenhagen <at> gmx.net wrote:
> > And in a way the program cannot detect.  For example, the alt-SysRq
> > was pretty much designed for this purpose.  However, it is unusable:
> > if we find out that a program is malicious, and we want to stop it
> > immediately, pressing alt-SysRq means first pressing alt, which the
> > program can see.  In response, it can do its worst (thinking it's
> > about to die anyway).  This must be avoided.
> 
> To be honest, the bit about Alt sounds a bit too paranoid to me...

Given how common keyboard sniffing software is these days, it is not
overly paranoid.

But I'm not sure that ALT is required. On most keyboards, SysRq is an
*unshifted* key.

Even if ALT is required, there is a fairly "simple" solution: inject a
low-level keyboard driver that captures key code sequences from the
keyboard. This state machine confirms that each key code sequence is
"well formed", and passes the key code sequence along (unmodified) only
when the full sequence has been seen. If the key code sequence for
SysReq is seen, it is hijacked.

Note that on modern machines this means that the low-level USB channel
driver, keyboard driver, and all USB hub drivers must be trusted.

More broadly, the "drivers" for any secure input and output devices, and
any channels used by those devices to communicate to the CPU, must be
managed by 100% trusted drivers. A secure system cannot let those
drivers be replaced and remain secure. This is a well-known issue. It's

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Jonathan S. Shapiro
 | 
30 Jan 16:50





Re: User sessions, system request


On Fri, 2008-01-18 at 17:39 +0100, Bas Wijnen wrote:
> Hi,
> 
> It's been a while since anything happened here.  I haven't had any
> comments about my kernel, which I found disappointing (I talked a bit
> about it with Marcus, so I didn't expect new comments from him, but I
> had expected some from others like Jonathan).

Bas:

I apologize, but (as you have probably figured out) things have been
very hectic, and I really don't have time to look at another kernel
right now.  As I said in my other mail, I think there are some
fundamental problems with trusted path in the session management design
that you have outlined.

Here is a pair of "litmus test" questions:

If I am a user typing in a password,

  1. How does the receiving software know that the password is
     coming from the user, and not from software simulating the user?

  2. How does the user know that the password they type is going
     to software that can be trusted to protect it, rather than
     software that will broadcast the password to the entire world?

Both issues are very difficult, and they both require support from both
hardware and software (in particular, hardware keyboard sniffers are a
serious problem). Both issues tend to prohibit designs in which

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Bas Wijnen
 | 
30 Jan 18:30






Picon

Favicon





Re: User sessions, system request


Hi,

On Wed, Jan 30, 2008 at 06:54:15AM +0100, olafBuddenhagen <at> gmx.net wrote:
> On Fri, Jan 18, 2008 at 05:39:12PM +0100, Bas Wijnen wrote:
> 
> > It's been a while since anything happened here.  I haven't had any
> > comments about my kernel, which I found disappointing (I talked a bit
> > about it with Marcus, so I didn't expect new comments from him, but I
> > had expected some from others like Jonathan).
> 
> I was pretty amazed by what you had done there... And I really didn't
> know what to say. Look at it in a positive light: It was so convincing
> that there was nothing left to add or to dissent from... ;-)

Thanks. :-)

On Wed, Jan 30, 2008 at 10:50:33AM -0500, Jonathan S. Shapiro wrote:
> I apologize, but (as you have probably figured out) things have been
> very hectic, and I really don't have time to look at another kernel
> right now.

No problem, thanks for answering now. :-)  As you probably know without
looking at the kernel, the main difference with Coyotos is the lack of
constructors, and of opaque memory.  So far I'm still happy without
them. :-)

> > There must be a dedicated piece of hardware to do a "system request".
...
> > pressing alt-SysRq means first pressing alt, which the program can
> > see.  In response, it can do its worst (thinking it's about to die

(Continue reading)






Permalink
| Reply
| 7 comments  
| 



  

  

  





headers


Jonathan S. Shapiro
 | 
30 Jan 20:42





Re: User sessions, system request


On Wed, 2008-01-30 at 18:30 +0100, Bas Wijnen wrote:
> Right.  But my keyboard driver is working around all cleverness of
> keyboards anyway.  It sends exactly one event for each make or break
> that happens.  Fake shifts are removed, prefixes are interpreted (and
> merged with the actual events), key repeat is ignored.

This will break a small number of programs, but they turn out to be
depressingly important programs.

> However, by requiring users to first press Alt before they are able to
> press SysReq, the application can get some information that it shouldn't
> have.  That's why I want it to be a single key, not a combination.

Understood. Interposing a state machine in the way that I suggested
would also resolve this.

> > Even if ALT is required, there is a fairly "simple" solution: inject a
> > low-level keyboard driver that captures key code sequences from the
> > keyboard.
> 
> This won't work: I want programs to instantly see any key that is
> pressed, if they're allowed to see it.  If you want to capture it, you'd
> need to delay sending of the Alt make code until another key is pressed,
> or until it is released, or until some arbitrary time has expired(?).

This is not an issue. The state machine only runs for one full keypress.
ALT-SysReq is a single keypress. The application cannot tell if the
individual code points have been delayed.

If you are converting everything into canonical code points, you are

(Continue reading)






Permalink
| Reply
| 6 comments  
| 



  

  

  

  


  





    



Gmane