… short answer…
So you insure that only the ‘right’ browser is able to run…
…but do nothing to prevent the malware it dragged in the door from running?
Another Windows we do not need…
[quote=Bill Hacker]… short answer…
So you insure that only the ‘right’ browser is able to run…
…but do nothing to prevent the malware it dragged in the door from running?[/quote]
If the browser gets compromised by malware - it should not be able to do any harm as it will be effectively sandboxed. Of course the best approach will be to request a signed manifest for all installed apps.
How does an unobtrusive sandboxing mechanism turn Haiku into Another Windows?
Your suggestion is too simplistic. It’s effectively an application whitelist. Any whitelisted app can do anything it wants. What if upon opening a malware-exploited PDF file your perfectly functioning authenticated and hashed PDF viewer decides to send all your browser/ftp-app/mail passwords, documents, contacts, etc to a third party?
… ‘inobtrusive’ w/r any ‘sandboxing mechanism’ that actually works is an oxymoron.
The closest I am aware of for a combination of capability-based security and pathname security is used in the Prex embedded OS, which see (duuno if I can post a link, if not go ogle for it)
http://prex.sourceforge.net/doc/security.html
Be aware that conscious choices were made to run the ‘system’ in one chunk of protected memory, and userland in another. And that for a single ‘seat’ embedded OS intended for example mobile devices and the like, yet.
Should Haiku follow a similar path?
Pass. I don’t yet know. It is neither easy nor quick to re-engineer an OS as complex as Haiku, and re-engineer is what it would require.
But what Haiku should NOT do - follow failures - whether security failures, (WinWOES), maintainability failures (Linux+gawd-alone-knows-this-week), or simple economic failures (SunSoft / Solaris) - is more easily answered.
Prex OS DOES show that ‘some forms of’ security can be implemented in a very small and lightweight space. They are not alone, and yes, there are downsides.
See also barrelfish - about as ‘messaging’ dependent’ as can be (vs shared memory OS’en).
Haiku is extensively ‘messaging’ based, and that requires a different core security model than otherwise.
Neither ‘manifests’ nor ‘sandboxes’ do not fall out of the sky, nor work without an infrastructure in place to support them.
All that has to be coded, tested, and maintained by … are you up for it?
Bill
You download the app from a repository, install it and run it. No security-related dialog boxes. If the app tries to do something not allowed by the manifest - the OS will silently(for the user) refuse it. This is as unobtrusive as it gets.
OK - I’ll play your game.
I have two instances of Haiku online at the moment, R1 and a day-old snapshot.
One has the TiltOS ‘box’ packaging tools installed.
I’ve also got ‘joe’ and a decent hex editor, so I can alter a bit or two and see if the system detects it.
Just tell me, please …
-
which repository I should use?
-
and which app should I download from that repository to test that this all works as you claim it does?
And - as I have two views of the ‘trunk’ open on the PowerBook - just where in the sources or docs is this toolset you claim works so ably and simply?
While I am still doing research and comparisons of potential ‘possibilities’, you seem to have brought your blue sky manifest system all the way into existence. How else can you describe how it works?
… show me the code.
[quote=Bill Hacker]Just tell me, please …
- which repository I should use?
- and which app should I download from that repository to test that this all works as you claim it does?
… - just where in the sources or docs is this toolset you claim works so ably and simply?..
… show me the code.
[/quote]
Huh, this is a discussion about ideas on how the Haiku security model may work in the future. Did I imply that my proposal is anything more than an idea? The idea may be simple, the implementation is not.
If you want to see an implementation of something similar - have a look at AppArmor(SUSE,Ubuntu) and SELinux(RHEL).
Well, that’s how proposals and ideas work. Somebody says “I have this idea/proposal, it should work this way:…”.
The proposal is simple to explain and can be summarized in one sentence : “We have a manifest file for each installed app that specifies what the application is allowed to do, if it tries to do something that is not allowed - the operation will fail”.
It is my opinion that this can be made to work without requiring any user intervention. I may be wrong. If you have any technical objections why this may not work - please voice them.
Security profiling and binding (yes, this involves a manifest that for the most part be automatically generated) through something such as Systrace is the easiest way to go in terms of locking down and partitioning the system into system/user areas and systrace will not break backwards compatibility. If an OS is designed with a mechanism such as Systrace in mind then it will be will integrated and of very low annoyance to the user. We should also not include a “turn off your security” button ala Vista’s UAC.
Systrace was mentioned here - http://www.haiku-os.org/community/forum/sandbox_securitymulti_user_idea - but it is NOT sandboxing (in the traditional sense) and certainly NOT virtualization or emulation. There is almost no overhead with Systrace, just as there isn’t with SELinux.
I think the heavy use of trusted repositories is also EXTREMELY important to general system security. Users should not be doing what they currently do in Windows which is getting unknown binaries from all dark corners of the internet. This works extremely well for Linux and BSDs and is very user friendly (no file hunting).
There is a finite, but arbitrarily large count of such ideas that have already been turned into practice, for better or worse. And no shortage of F/OSS code.
The point you are choosing to overlook is that they have - for the most part - either:
-
taken advantage of an environment wherein MOST, not necessarily all, of the tools they need for implementation, already exist in one form or another (‘most’ Unix and Linux).
-
ELSE have been designed-in from early days (Prex, barrelfish - both still theory/WIP)
-
AND/OR been progressively integrated, over a longish period of time, into the very core of something that did not originally have the needful parts (OpenBSD = 10+ years of sweat and counting, SELinux = $$$$ + sweat + what? 3+ years?.. then what? Limited adoption anyway).
Haiku has neither the history, the resources, nor even much in the way of ‘hooks’ or compatibility to support porting any of these things over. ‘Glued on’ after the fact simply will not do. See Windows.
So - IF even the most minimalist security model is to come into being:
-
the guardians of the code have to agree the need AND the method.
-
they, and other new help, have to CODE IT and test it. Repeat, repeat, repeat.
Three year effort? More?
So far, there isn’t even any serious interest in having a Haiku security model, let alone which, how, or when. Just note how few participants have appeared in this thread.
So I doubt there ever will be.
Devel team having demonstrated their ability, many are likely to move on to other projects.
That’s the nature of the industry.
Bill
The developers don’t frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development
Haiku has the advantage of having a relatively compact, clean and well integrated codebase.
It is also very new and has not been under much scrutiny, so it is probably ripe with security bugs. Having a security framework is a must and I hope that afteer R1 this will be actively worked on.
Windows is a mess. It has tons of legacy libs and APIs with duplicated functionality and it has to keep compatability with gazillion legacy applications.
Linux is also a mess - it has a huge ‘everything but the kitchen sink’ kernel, and very unintegrated userspace with layers upon layers of incoherent libraries, APIs, window managers, GUI toolkits, etc. It also has a dozen of separate efforts to create a security framework.
‘… probably ripe with security bugs.’
Not actually as likely as all that. Just as OpenBSD had to do a very thorough code-audit in branching from NetBSD, and more recently DragonFlyBSD from FreeSBD 4.X, Haiku’s genesis in re-implementing a BeOS workalike has had to have given rise to greater code scrutiny and clean-up than might have been the case otherwise. IMNSHO, the larger risk is that it relies heavily on a messaging architecture (as does Windows). That poses special challenges in its own right, which is why I’ve said the Barrelfish work should be looked at.
‘Windows is a mess.’
The very point. It was too far-along to change easily by the time anyone realized it had serious problems. Not a mistake that needs to be made again.
‘Linux is also a mess - it has a huge ‘everything but the kitchen sink’ kernel…’
Given the size and lines of code, the kitchen sink must be in there as well.
Minix 3.XX, by contrast needs only around 4,000 lines of code to implement its kernel. Not my ciup of tea, but proves fat is optional, not essential. In an age when Linux has gone so far overboard that even Linus Torvalds calls it bloated, Haiku has a clear edge.
‘A wise man learns from the mistakes of others. A fool from his own’
Bill
The developers don’t frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development[/quote]
Alternatively, someone subscribed to one of those mailing lists could post a message there with a link to here…
The developers don’t frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development[/quote]
… and therein lies another problem.
Appreciating that ‘Freelists’ may be attempting to ad value in exchange for advertising, I find their lists essetially useless, as my browser has to time-out on the multiple advert feeds - all of which it blocks (and would be ignred anyway…).
I don’t blame ‘Freelists’. I blame the Monkeys who fund advertising-land with budgets for ‘click’ programs despite their abysmally low returns. As with overly intrusive radio commercials of days gone by, many try to avoid buying products or services from those who are so inconsiderate.
It would be advantageous if ‘proper’ advert-free MLM hosting could be found for the Haiku project.
The developers don’t frequent these forums, so if you want to get any kind of feedback from them, you then need to ask on the [haiku] or [haiku-development] mailing list.
http://www.freelists.org/list/haiku
http://www.freelists.org/list/haiku-development[/quote]
… and therein lies another problem.
It would be advantageous if ‘proper’ advert-free MLM hosting could be found for the Haiku project.[/quote]
False alarm on your part, as you don’t need a browser to follow the mailing lists. Just signup to the lists that are of interest to you and all emails will be properly delivered to your mailbox ad-free.
That functionality is already available via other means, fortunately.
Anyway - it is not the main problem.
The issue is that it is a RPITA to search the archives so as to inobtrusively get up to date on what has already been covered on a given topic / area of concern AND be able to rapidly read what the search returns, THEN move on to the next entry or topic. At present, each navigation step triggers a fresh set of adverts, hence delay.
One can, of course, pull a local copy of the entire archives periodically, so it is nuisance category - nothing more.
Minix is a microkernel operating system. Haiku’s kernel, like Linux, is monolithic. So you’re comparing apples with oranges.
[quote=NoHaikuForMe][quote]
Minix 3.XX, by contrast needs only around 4,000 lines of code to implement its kernel. Not my ciup of tea, but proves fat is optional, not essential. In an age when Linux has gone so far overboard that even Linus Torvalds calls it bloated, Haiku has a clear edge.
[/quote]
Minix is a microkernel operating system. Haiku’s kernel, like Linux, is monolithic. So you’re comparing apples with oranges.[/quote]
More accurate, perhaps to say comparing ‘fruit with fruit’, as - architecture aside - the kernel is the kernel - not the entire meal.
‘All of the above’ need external binary code to do any human-usable work.
What Linux and Minix need to implement a GUI is near-as-dammit identical - the X-Windowing infrastructure for starters, then a WM, optionally a ‘toolkit’, then a ‘desktop’ on top of all that.
Not everything is built in, but Haiku needs far less of that sort of external, so - despite the ‘monolithic’ - it ends up smaller than many ‘microkernel’ or hybrid (OS X) architectures, even BEFORE thye haul in their support frameworks.
A closer cousin ‘philosophically’ might be Plan9 - though anyone other than a Plan9 developer might have issues with Acme/Rio as a UI (… as they are really more of an IDE…).
Others include Aos bottle, Syllable, Menuet, and some others - all of which, as does Haiku, take their own ‘direct’ and ‘in house’ cohesive route to implementing a GUI rather than using a gadzillion diverse libs and tools from all over the known universe. X-Windows is like the dancing bear. The marvel of the thing isn’t that it dances well, but that it manages to dance at all.
Comparing on the basis of kernel size alone is deceptive. OS/2 Warp had a ‘kernel’ of around 85 Kilo-bytes, and could install and run in 4 Mega-bytes of RAM or less.
(IBM Thinkpad 360C).
BUT - though I don’t recall it being called a ‘microkernel’, Warp still had to page 80+ Mega-bytes of various classes of drivers and such through that RAM and back out to VM swap before it was ready to communicate with a user. The HDD sounded like a Singer. The sewing machine, not the minicomputer. Worked much faster once it had 20 MB, though.
NB: Just got Haiku up, and reasonably happy, on a salvaged Thinkpad X20. PIII 600 MHz, 128 MB SDRAM. No joy, however on a Kapok 200 MHz pre-MMX PII, 72 MB FPM RAM, which did run Warp Server Advanced / 4.5 & eCS or Win NT4.
No, that’s quite OK, I was accurate before, you were comparing apples with oranges.
Ultimately, even if you somehow ignored the fact that X is much better designed than these toy window systems you mentioned, the bottom line is that X has the developers, the drivers and the applications. This particular dancing bear is principal ballerina.
[quote]
Ultimately, even if you somehow ignored the fact that X is much better designed than these toy window systems you mentioned, [/quote]
As I’ve only been dealing with X for twenty years, perhaps you’ll forgive me if I’ve missed any evidence to that effect.
X cannot yet match Presentation Manager / Workplace shell on any factor save the count of available hardware video drivers - and did not match OS/2 video driver collection ‘back in the day’.
I can make X look better than Apple’s OS X, but I cannot make it work better - nor even as well, unless I throw it a 2:1 heavier hardware advantage than OS X needs. Which I do.
Neither X nor even OS X can inherently ‘remember’ the precise size and position of a specific application window I used a month ago, let alone that I had given that one window, or its app, or its desktop, but no others a different theme and customized menu layout and colors than other windows. System Object Model at work. Haiku cannot do that yet - but as open source, I can see where to hook it in if I want it badly enough, and in a simple and elegant manner (DB lookup vs hard-coded attributes).
[quote]
the bottom line is that X has the developers, the drivers and the applications. [/quote]
…and did precious little with those resources vs the 800lb MS Gorilla until X-org took over and made what turned out to be almost a fresh start. Kudos to them, but they are not the only game in town.
And, as with classical ballet, unfortunately, holds a miniscule share of the entertainment business.
MS Windows still holds something above 80% of the desktop and laptop market. Mac OS X has displaced ‘all others combined’ as the next largest single holder, arguably taking as much share from Linux as it did from MS.
Both Windows and Mac OS X have a presence on handheld phone and PDA gadgets - which by unit count now outsell desktops and laptops. X-Windows is as scarce in handhelds as it is on the desktop or laptop.
iPhone and Windows Mobile aside, more and more of the rest are using one form or another of what you have called ‘toy window systems’.
Crash a GUI app badly enough to destroy the desktop on any other windowing system except OS/2 or Haiku. Then see if it lets you rebuild the desktop without losing a byte on an in-process file download. One evoked from the GUI, not the CLI under it.
If Haiku is a ‘toy’, then it is a toy that is worthy of respect.
Twenty years is certainly a long time to not notice the fundamentals.
As to SOM, it’s not even slightly relevant to X but “everything is an object” plus native binaries results in “everything is an exploit”. (For any BeOS/ Haiku fans, SOM is basically OS/2’s equivalent of COM)
[quote]
Crash a GUI app badly enough to destroy the desktop on any other windowing system except OS/2 or Haiku. Then see if it lets you rebuild the desktop without losing a byte on an in-process file download. One evoked from the GUI, not the CLI under it.
If Haiku is a ‘toy’, then it is a toy that is worthy of respect.[/quote]
It’s to be expected that someone who doesn’t understand X would not recognise the difference between a shell and a window system. What you’re doing in Haiku is restarting the shell. X doesn’t really consider the shell distinct from any other client, so of course you can restart it without disturbing other clients. When people choose to have a shell in X (not everyone does) it often takes the role of session manager and sometimes also window manager. The NETWM spec explains how a window manager can even take over from a previous window manager, reparenting all the top level windows, without unduly disturbing the clients that own those windows.
This thread was originally about security, and it seems that your rambling does offer an opportunity to look back in that direction. Securing a GUI is an interesting problem, not to be underestimated.
In BeOS and Haiku there has been no attempt to address this problem, a malicious or very badly written application can seize control not merely of the window system, but the entire OS. But if you look at something like Windows NT you see steady effort, at first securing access to the window system and protecting it from client applications, and later increasingly on protecting clients from each other. With something like GNOME on Linux you see a very different approach to the same problem, proxying privileged programs so that they’re not directly connected to the window system and thereby shrinking their attack profile.