[Inx] Thoughts and Isssues: INX

[Dan Mazzei]

Peter Garrett wrote:
> As there has not been much happening with INX over the last couple of
> weeks, I am sending this as an update, and a possible catalyst for
> thought.
>
> In this post I want to deal with some potential issues. One of them is
> technical, and the others are about "policy", for want of a better term.
>
> As you will be aware, INX has never really been publicly announced,
> other than on a few mailing lists. Part of the reason for this up to
> now has been my disquiet with a technical problem regarding the links2
> browser.
>
> Links2:
>
> 	In INX, the links2 browser is currently suid root -
>
>         ls -l /usr/bin/links2
>         -rwsr-xr-x 1 root root 2807180 2008-01-05 01:05 /usr/bin/links2
>
> 	The reason for this is that this is the only way so far that I
> 	have been able to make the "directfb" graphics "work" from the
> 	menus. It is possible to make directfb work with links -g (AKA
>  	xlinks2) by altering permissions in
>
> 	/etc/udev/rules.d/40-permissions.rules 
>
> 	(For example, setting user "inx" as a member of group "tty" and
> 	making devices writable by that group as follows:
>
> 	KERNEL=="mice"                         GROUP="tty", MODE="0660"
> 	KERNEL=="tty[0-9]*"                   GROUP="tty", MODE="0660"
> 	KERNEL=="fb0"                           GROUP="tty", MODE="0660" )
>
> 	Unfortunately, while this allows links2 -g / xlinks2 to start and run 
> 	without the suid bit *from a command prompt* , the browser fails 
> 	to start *from a menu entry or script*
>
> 	I have tried without success to change the scripts in various ways in
> 	order to make directfb "work" with links2...
>
> 	Links2 simply refuses to run using directfb from any script unless set suid root. 
> 	I think this is a directfb question, but I confess that my understanding of 
> 	directfb is... *cough* rudimentary.
>
> 	One point worth mentioning: if the browser is called with "exec" from a menu 
> 	or script, with thte permissions tweaked as above,  it runs. 
> 	This is not very useful though, since once you invoke "exec"
> 	you are out of the INX shell, so quitting links2 then returns you to a prompt.
>
> 	The "safe but not really optimal" solution is to run links2 -g /xlinks2 using only
> 	ordinary "fb" (the slow vesa framebuffer). This is fairly horrible, since the mouse
> 	becomes very "slow" , the scroll wheel "Doesn't Work", and so on. If you want to
> 	try it, invoke the browser thus:
>
> 	links2 -g -driver fb <some-url-here>
>
> 	Of course, all of the above applies only to running the browser graphically in a tty, 
> 	and not in "X", which works fine...
>
> 	I've made this rather long dissertation in the hope that some of you might find 
> 	time or interest to solve the problem ;-) I won't go into the reasons why suid
> 	on a browser is,,,, shall we say, Not the Right Thing (tm).
>   
I may not be understanding the issue fully, but could we maybe install 
the program in a chroot environment and have a symbolic link in the path 
statement, so that, even though it would run as suid, it would not be a 
security risk to the system, but just to the chroot environment.  I may 
hack that together and try it out in the next few days, depending on 
schedule.  Would that fix some issues?  Obviously still you have to run 
it as suid, but that should cover some of the more obnoxious 
vulnerabilities. 
> Stable vs, Development Models:
>
> 	Since the current development versions of INX are based on Ubuntu Hardy, 
> 	the released version ("Real Soon Now", "When it's Ready", etc. etc.) will stay 
> 	pretty much "as is" for a few years.
>
> 	It occurs to me that we could use a model similar to the Debian approach, and
> 	have an "unstable" branch into which improvements and features could be added
> 	continuously. The reason that I am thinking about this is that I feel it would help to
> 	generate interest in INX for people who want to play with the code, add stuff or 
> 	improve it, and so on.
>   
Perhaps the release dates should co-inside or be close to Ubuntu Long 
Term Support releases, and the improvements be an unstable branch? 
> Announcements, Release and other Scary stuff:  ;-)
> 	
> 	* We need to set up a torrent when the announcement is made - you never know,
> 	there might be some interest, and anyway it's the Right Thing.
>   
I can maybe seed, but I don't have a lot of bandwidth, so if I do the 
torrent would be throttled. 
> 	* Some mirrors might be nice - if nothing else, it's good for people to have a server
> 	relatively nearby rather than having to download from half way around the world.
> 	* I have no idea what information needs to be gathered for, say, Distrowatch,
> 	but that would be easily discovered...
> 	* Team members might like to think about writing press releases / blogs/ other
> 	marketing things. ( I have an unreasonable prejudice about such matters that 
> 	I might need to overcome *grin*)
>
> Feel free to respond in a similarly rambling style, or if you have a solution to the links2
> problem, please let us know...
> 	
>
>   

Let me know about updates to the situation. 

--Dan