Haiku Security

Forum thread started by IBMoid on Mon, 2006-03-06 21:21

Suggestions for security so Haiku doesn't end up as holed as Windows:
1. Make every user create a root account and a user account at startup.
2. Try to adhere to POSIX to prevent viruses from destroying the computer.
3. How about every program has its own "virtual" memory space(I dunno if this is possible) preventing the programs from interfering with other programs and the core OS files. I.E

YYYY:YYYY - [program 2] {end of virtual space} 

XXXX:XXXX - [program 1(thinks it starts at an earlier number just before a binary interpereter for requesting things the program needs)] {end of virtual space for program 1}

0000:0000 - [OS and servers who may go to any address space]

Comments

Re: Haiku Security

umccullough wrote:

I'm guessing that in these cases, constructive criticism is often utilized. Generally when providing constructive criticism, one tries to provide solutions along with the criticism (and no, "stop using this software because it sucks" is not a constructive solution). In a FOSS project, it's generally hard to make everyone happy when there is more work to do than there are volunteers to do it.

It's pretty hard to offer something constructive to say about Haiku's security. Haiku does not have security in any meaningful sense. You have perhaps heard the story of The Emperor's New Clothes ? Every post in this thread in which Haiku's security is non-specifically praised is like a courtier exclaiming how wonderful the emperor's new suit is in the story.

If for some reason this is opaque to Haiku's developers, I'd say that's one more reason to give it a wide berth, but let's briefly spell some of it out for one tiny corner of the problem, security updates.

• Reporting. You need a reliable means to receive reports of security problems, with one or more trusted individuals responsible for receiving the information, keeping it confidential and ensuring its acted on quickly. Without such a mechanism it's only to be expected that all disclosures will be public, "zero day".
• Fixes. You need to react to reported security problems from security channels, your own security contacts and in public (e.g. via Bugtraq) by identifying a correct fix, and integrating that into the software as quickly as possible.
• Distribution. You need a mechanism to distribute fixes. It should be as easy as possible for users to get fixes, while being as hard as possible for black hats to delay, undo or subvert the update process.
• Alerting. You need a reliable method to let users know they're vulnerable. Today it would be acceptable for this means to be primarily via the Internet. Again it should be hard for black hats to block this process.

Re: Haiku Security

Its just a thought, but why don't you put your wasted breath to work by working on security then writing such long-winded comments. Its a waste of time. If you really want to troll go on 4chan and whine. I do it when I'm frustrated. Your comments suck and you're bringing nothing to the table. Also, guys, stop talking to this guy, its just pissing everyone off. NoHaikuForMe, please stop talking.

Re: Haiku Security

Good points umccullough.

If NoHaikuForMe seriously wanted to provide constructive criticism and be taken seriously, then:

  1. He/she would not use that inflammatory nickname. Trying posting to the LKML as NoLinuxForMe and see how it goes.
  2. He/she would not hide here in the forums but would post on the mailing list where all Haiku developers could address his or her comments. Try posting to the Ubuntu forums about how the Linux scheduler sucks for X or Y and see if somehow the LKML people respond.
  3. He/she would actually provide constructive criticisms and not broad statements that some aspect of BeOS or Haiku is just inherently wrong and unfixable. Trying telling the LKML that Linux will never be successful on the desktop because it is just a server OS and see if they just accept that without debate and give up, as apparently is expected of us for similar comments about Haiku.
  4. He/she would not stoop to using examples such as releasing the alpha with an old version of Firefox as why Haiku's developers don't care about security. In that case Ubuntu doesn't care about security either since they too once released with that version of Firefox. I'm sure some security bugs exist in the latest Firefox too. Damn do those Ubuntu people care at all about security? Actually with that mindset I can make all kinds of broad statements about Ubuntu: they don't care about users because of all the broken crap they've shipped over the years. They want Linux audio to fail because they shipped a broken PulseAudio. And on and on.

Basically all signs point to troll: "In Internet slang, a troll is someone who posts controversial, inflammatory, irrelevant, or off-topic messages in an online community, such as an online discussion forum, chat room or blog, with the primary intent of provoking other users into an emotional response or of otherwise disrupting normal on-topic discussion."

Also if we really wanted to shut up NoHaikuForMe and stop all debate and negative criticism about Haiku we would have banned that user name long ago. But I'm sure NoHaikuForMe has a quip to explain that away too.

So why am I wasting my time here? I really would like to see NoHaikuForMe change their approach and post his or her valid complaints about Haiku on the mailing list, where more eyes can see them and maybe some of the truly broken things can be fixed. Until I see that happen I'll always have that bad feeling of a troll when I read his or her posts here.

Re: Haiku Security

Bill Hacker,

Thanks for your response - to clarify my post, I was referring to having one standard user login (as now) but possibly with a single, higher-privilege workgroup settings panel (password configured at Haiku install time) for enabling authentication against a network server, providing access to shared resources for Haiku clients, etc. Since Haiku defines itself as a Desktop operating system, any server OS capable of running the daemon(s) could take care of the authentication of Haiku clients - including file share / quota provisioning, ldap settings etc for any given network user. The network users could then be defined in accounts in the server side daemon config.

Re: Haiku Security

philcostin wrote:

Bill Hacker,

Thanks for your response - to clarify my post, I was referring to having one standard user login (as now) but possibly with a single, higher-privilege workgroup settings panel (password configured at Haiku install time) for enabling authentication against a network server, providing access to shared resources for Haiku clients, etc. Since Haiku defines itself as a Desktop operating system, any server OS capable of running the daemon(s) could take care of the authentication of Haiku clients - including file share / quota provisioning, ldap settings etc for any given network user. The network users could then be defined in accounts in the server side daemon config.

Aside from not (presently) requiring any login at all - which a screensaver lock can ameliorate *slightly*, AFAICS the rest is already there.

One of the first things I did with Haiku was ssh in to a Unix server.

I haven't had the need to mount smbfs or NFS, but if they are not already there, it would be trivial to import both. AFS and the like - needing kerberos or Heimdahl may be in there somwhere too. No lazy way to test those.

As you say - login based on the *server* end - so 'already here'.

Haiku makes for really nice readability, has great terminal scrollback and handy 'zoom'.

But I hope it grows into a lot more than just a better terminal than an HP-200 LX.

.. which did have password security. And file encryption.

Re: Haiku Security

I like the idea of keeping Haiku single user - since it is supposed to be a fast, light desktop OS and computers are more personal now than ever before.

Maybe a single optional login password for preventing just anyone from using your computer.

When it comes to a networked environment, I think there could be a UNIX daemon or 3 which act as a haiku workgroup server and allow people to log into Haiku as a workstation user.

So: single user for local machine, OR one network-user at a time, communicating with a UNIX based server daemon that manages logons / file quotas, etc. That way, Haiku remains a speedy, nimble single user desktop OS, but has a future as a workstation on a network, too.

Re: Haiku Security

philcostin wrote:

I like the idea of keeping Haiku single user - since it is supposed to be a fast, light desktop OS and computers are more personal now than ever before.

'keeping' an already multi-user OS (which Haiku is) single user would require a rewrite..

Quote:

Maybe a single optional login password for preventing just anyone from using your computer.

More or less what is presently imposed by developer's fiat, moreover, with the default user selection scripted, and the ability to add more than the basic few or change passwords presently locked-down. No change to that needed to suit what you are asking for.

Quote:

When it comes to a networked environment, I think there could be a UNIX daemon or 3 which act as a haiku workgroup server and allow people to log into Haiku as a workstation user.

Already provided for in the form of a separate identity for the sshd daemon.

I haven't looked at what the httpd daemon runs as (PoorBoy?), but 'top' will show one that there are already separate credentials of one kind or another for several 'team' daemon-runners.

Quote:

So: single user for local machine, OR one network-user at a time, communicating with a UNIX based server daemon that manages logons / file quotas, etc. That way, Haiku remains a speedy, nimble single user desktop OS, but has a future as a workstation on a network, too.

Haiku already supports multiple simultaneous ssh network sessions with different user ID's from different remotes. Some fiddling required to set up the credentials, but it works well enough. No gain is taking it back out, either.

Generally, the physical count of kbd/video/mouse is going to limit most desktops to one user 'at a time' more pragmatically than the OS.

When it comes to 'remote', even CP/M on a Z80 could handle multiuser apps - and did so. They just had to be in the app, not the executive (Point Of Sale and BBS systems).

Anyway ...

Single vs multi user *design* does not necessarily equate to speed differential or even code weight. More of that depends on how MUCH work is to be done at a given point in time than 'for whom' it is to be performed. Likewise, how much of that work is 'bound' by other-than code execution time.

Think waiting on keystrokes, mouse movements, HDD access, or network I/O. Not much work, unless your OS were to be 100% 'polling' driven...

Re: Haiku Security

devs don't check the forums because they don't want to deal with all the trolls

Re: Haiku Security

arielb wrote:

devs don't check the forums because they don't want to deal with all the trolls

Well I've been checking them pretty often lately, though I'm not exactly Axel or Ingo who are some of the real heavy lifters as far as the Haiku developers are concerned. But these forums could certainly be referenced when work begins in areas being discussed, like security in this case.

As for trolls, I don't think we have too many, and I don't think NoHaikuForMe is that bad of a troll. Assuming he is male: his nickname is certainly inflammatory but his knowledge of technology is pretty good, and a lot of the critiques of Haiku he has made are fairly accurate.

My main gripe is he assumes the flaws in Haiku are permanent, like many Haiku detractors, when more than likely they are not.

Re: Haiku Security

leavengood wrote:

My main gripe is he assumes the flaws in Haiku are permanent, like many Haiku detractors, when more than likely they are not.

Nothing is permanent, and so the opposite problem is the tendency to look at where we are now, and take that as a fixed landscape against which Haiku will evolve. I've said before and will again that it's a Red Queen's race. Every other OS is evolving too. In Redmond, Microsoft's engineers will have been working on the successor to Windows 7 for months already.

When work on Haiku began in 2001 you could have looked at the landscape at that moment and concluded that most people only use a desktop PC, they have no more than 1GiB RAM, they have AC97 audio, and they use DSL or Cable at maybe 1 Mbit/s to read blog pages and write email. Haiku today is actually not that badly equipped for such a system. But it scarcely matters, because it isn't 2001 any more.

Some detractors of the original OpenBeOS concept felt that the BeOS R5 goal was short sighted because they wouldn't have an OS until say 2010 and by then all the assumptions would change. They were shot down by people who insisted that it wouldn't take nearly that long to bring OpenBeOS to fruition.

2010 is now two months away.

But this has swung wildly off topic.

Re: Haiku Security

NoHaikuForMe wrote:

Nothing is permanent, and so the opposite problem is the tendency to look at where we are now, and take that as a fixed landscape against which Haiku will evolve. I've said before and will again that it's a Red Queen's race. Every other OS is evolving too. In Redmond, Microsoft's engineers will have been working on the successor to Windows 7 for months already.

If you are a developer - there's a chance that you've seen some projects that have gone wrong. Huge, bloated, badly designed - piece by piece, very hard to maintain. Adding new features is a pain - you have to make changes all over the codebase, often using hacks, accidentaly breaking a lot of seemingly unrelated stuff in the process. Just finding what to change in order to add a simple feature can often be a daunting task. And it keeps getting worse.

Windows and Linux have all the characteristics of such projects.

There's a reason it took Microsoft so many years and manpower to get from WindowsXP to Vista (5+ years, hundreds, if not thousands of developers and for what?). There's a reason why it took the Linux desktop so many years to catch-up with Windows. And there's a reason why Haiku has managed to reach it's current state with a tiny fraction of the developers and resources that Windows and Linux needed. You can count the major Haiku contributors on the fingers of one hand. The team that was responsible for the ill-fated Vista shutdown dialog( http://tinyurl.com/y2g6ye ) was probably bigger than that.

The Haiku code is compact, efficient, easy to understand and above all - well designed as a complete, coherent and interoperable system that can be easily extended.

Re: Haiku Security

geleto wrote:

And there's a reason why Haiku has managed to reach it's current state with a tiny fraction of the developers and resources that Windows and Linux needed.

Sure, those developers did only a tiny fraction of the work. Major parts of the system (not to mention the general design) already existed and were simply imported wholesale. So while Red Hat (a major Linux distributor) has employees working on the compiler and toolchain, Haiku is content to merely re-use them with a brief credit. The FreeBSD driver developers worked from hardware documentation to create and test drivers. Haiku pastes them into a compatibility layer. Whether it is JPEG decoding, writing a line of text on the screen, connecting to a remote server, Haiku was able to have a "tiny fraction of the developers" by only doing a tiny fraction of the work.

Throughout Haiku, at least when someone remembered to leave them in, there are copyright lines or credits for thousands of other individuals and organisations which developed the software that is "Haiku".

Another way to reduce developer numbers is to cut a lot of corners. For example you could take a critical feature of the OS and just not bother implementing it. We'll see an example below.

Quote:

The Haiku code is compact, efficient, easy to understand and above all - well designed as a complete, coherent and interoperable system that can be easily extended.

Security is job number one. Security mitigations are entirely absent from this "complete, coherent and interoperable" system despite being the topic of this thread. Haiku R1 alpha shipped with an unmaintained web browser. Probably some readers of this thread laugh at Windows users who run some obsolete and unpatched version of Internet Explorer - but Haiku insists that you take the same risk.

But really you can't have intended the word "complete" there as a serious point. Haiku lacks support for most of the peripherals people own, not to mention numerous little features everyone assumes a modern OS will have - even its own developers recognise that this isn't feature complete.

Re: Haiku Security

NoHaikuForMe wrote:

Haiku was able to have a "tiny fraction of the developers" by only doing a tiny fraction of the work.

This is definitely true, but you act as if our project is the only one to use other people's code. I'm pretty sure Linux, Mac OS X, Windows and pretty much every other OS in existence are built with some amount of "other people's code." Either way if those people did not want their code used it would not have been released open source. If we had written every bit of Haiku ourselves we wouldn't be done until 2020, if that, and you already point out how long it has taken us to get this far, even using so much other code.

Also I'm pretty sure all the Haiku developers have made a very serious effort to recognize and preserve all copyrights and licenses of the code we make use of. If you feel there is some area where this was not done properly, please speak up.

NoHaikuForMe wrote:

But really you can't have intended the word "complete" there as a serious point. Haiku lacks support for most of the peripherals people own, not to mention numerous little features everyone assumes a modern OS will have - even its own developers recognise that this isn't feature complete.

Indeed, that is why we released R1 ALPHA 1, not R1, or even R1 Beta. Trying to run Haiku on some various pieces of native hardware lately has been giving me quite a bit of trouble. It is frustrating, but it is development code. Linux didn't start off supporting every piece of hardware. Even Microsoft with Vista (and probably again with Win7) has had trouble supporting some pieces of hardware and older software.

I do appreciate some of your insights NoHaikuForMe, but I really do have to wonder why you waste your time here. We Haiku developers aren't just going to just throw up our hands and give up on Haiku because it isn't immediately as great as the other major operating systems (not that they are that great...let's be honest now, they all have flaws.) And clearly you don't find it to be a worthwhile project. It seems like we should just agree to disagree and part ways.

Lastly on the topic of this thread, Haiku may not be as secure as it could be. But besides the fact that it is still in development, I'm pretty sure it would take a VERY, VERY, VERY long time for Haiku to come even close to causing as much harm as Microsoft has with their crappy, insecure software. The day that there is a botnet of Haiku machines even close to the levels of Windows machines, I'll concede you have a point. But I just don't see that happening.

Now that isn't an excuse to be sloppy, but I just don't think the risk of real user harm is there. Microsoft captured that "market" years ago.

Re: Haiku Security

leavengood wrote:

This is definitely true, but you act as if our project is the only one to use other people's code.

I don't think so, geleto's claim rests on the false idea that these developers have done so much with less people, and I simply showed where that argument falls apart. It's specific to Haiku only because geleto wrote about Haiku and this is a Haiku forum.

Quote:

I do appreciate some of your insights NoHaikuForMe, but I really do have to wonder why you waste your time here.

I'd say you've answered your own question. In most projects this voice would be redundant but Haiku inherits from BeOS fandom an almost entirely uncritical approach. I suspect that BeOS in turn inherited it from Apple and the reality distortion field. But wherever it came from it's unhealthy.

Quote:

Lastly on the topic of this thread, Haiku may not be as secure as it could be. But besides the fact that it is still in development, I'm pretty sure it would take a VERY, VERY, VERY long time for Haiku to come even close to causing as much harm as Microsoft has with their crappy, insecure software. The day that there is a botnet of Haiku machines even close to the levels of Windows machines, I'll concede you have a point. But I just don't see that happening.

Haiku won't achieve the popularity of Windows, and so according to you that means security isn't important?

Quote:

I just don't think the risk of real user harm is there

What's not to get? Haiku R1 alpha ships an old unsupported browser that has known security holes. People running that browser are at hugely increased risk to have their personal data copied. In my day job I see the kind of data that's collected this way (not the actual data of course, unless something goes wrong, since it would be unethical to look at it unnecessarily) and it means people's credit card number and CVV, their name and address, email addresses and passwords. Everything people type into a web browser is being collected by organised criminals.

The message from you, and apparently Haiku, seems to be "Who cares? And by the way Microsoft suck. La la la".

In terms of absolute numbers of people, the figures are tiny. Maybe a few thousand people try Haiku and use it to buy something on the web. Maybe one of those people is unlucky and gets their identity "stolen". Compared to the millions of people still running Internet Explorer 6 with no updates, it's not significant, right? But in terms of Haiku it's huge. And while Microsoft is doing whatever they can to get their users to update, Haiku is complacent.

Re: Haiku Security

NoHaikuForMe wrote:

I don't think so, geleto's claim rests on the false idea that these developers have done so much with less people, and I simply showed where that argument falls apart. It's specific to Haiku only because geleto wrote about Haiku and this is a Haiku forum.

So you are showing a more critical eye toward Haiku for no reason except that this is a Haiku forum? OK. I hope in the Linux or Gnome forums you tell them how much they suck because they still haven't gotten the Linux desktop right even with thousands of developers and tons of corporate cash.

No matter what you think in your distorted world view the Haiku developers have achieved a lot with a little.

NoHaikuForMe wrote:

I'd say you've answered your own question. In most projects this voice would be redundant but Haiku inherits from BeOS fandom an almost entirely uncritical approach. I suspect that BeOS in turn inherited it from Apple and the reality distortion field. But wherever it came from it's unhealthy.

That's just bullshit. Obviously you are hiding here under your user name so I have no idea who you really are, but over the years on the mailing list and in various commit messages the various problems from BeOS have been discussed and sometimes fixed in Haiku. Examples include the slow and crappy userland network stack, the lack of a GUI layout system, the lack of tooltips, the slowness of the syscalls, the slow compiling of large programs, and various problems with BFS.

We are recreating BeOS so there is obviously some respect for BeOS and most of what it represents, but the developers aren't a bunch of fanboys who see no flaws. Get realistic. Just because a few users here show some typical fanboyism does not mean the whole project runs under that attitude.

NoHaikuForMe wrote:

Haiku won't achieve the popularity of Windows, and so according to you that means security isn't important?

Don't twist my words, security is important but regardless of popularity Haiku will never impact the world in the horrible way Windows has. I think our developers care much more about security than most Microsoft programmers, based on their respective track records. Plus Haiku is an ALPHA OS, whereas Windows is on its seventh release (really more if you count properly.)

NoHaikuForMe wrote:

What's not to get? Haiku R1 alpha ships an old unsupported browser that has known security holes. People running that browser are at hugely increased risk to have their personal data copied.

SNIP

And while Microsoft is doing whatever they can to get their users to update, Haiku is complacent.

So all the efforts that I and Maxime Simon have been doing to port WebKit and write a new browser for Haiku are seen by you as complacency? Whatever dude, it seems that nothing Haiku does is enough for Mr/Ms NoHaikuForMe, so I won't waste my time anymore. Haiku is an alpha OS still heavily in development and you act like it's running the space shuttle or something.

I'd like to see you rip apart all the other operating systems with a similar approach. I don't think any OS would stand up to your ridiculous standards.

Either way others reading this can see your over the top negative bias toward Haiku and you'll be written off as the troll you are.

Re: Haiku Security

leavengood wrote:

So you are showing a more critical eye toward Haiku for no reason except that this is a Haiku forum? OK. I hope in the Linux or Gnome forums you tell them how much they suck because they still haven't gotten the Linux desktop right even with thousands of developers and tons of corporate cash.

Indeed critical debate is much more healthy in the communities you've mentioned. On the LKML for example you have someone like Brad Spengler. Thus an outsider voice would be redundant. The response to "Linux sucks" is not "go away troll" but "show us where and we'll fix it". The x264 author recently wrote about his experience as a non-kernel developer of showing a problem to the LKML and getting it fixed.

Quote:

That's just bullshit. Obviously you are hiding here under your user name so I have no idea who you really are, but over the years on the mailing list and in various commit messages the various problems from BeOS have been discussed and sometimes fixed in Haiku. Examples include the slow and crappy userland network stack, the lack of a GUI layout system, the lack of tooltips, the slowness of the syscalls, the slow compiling of large programs, and various problems with BFS.

The network stack change was initiated by Be, not Haiku. Similarly Be had been promising a real 1990s-type layout API for some time. We're talking about an eight year period, and the big changes you can come up with from Haiku are one thing Be already did, and another they already planned to do.

Quote:

Don't twist my words, security is important but regardless of popularity Haiku will never impact the world in the horrible way Windows has. I think our developers care much more about security than most Microsoft programmers, based on their respective track records. Plus Haiku is an ALPHA OS, whereas Windows is on its seventh release (really more if you count properly.)

Maybe Haiku developers care more than anyone else in human history about security, but it seems that they don't do much about it. Meanwhile Microsoft's programmers who you allege care much less, have been steadily introducing better security over the same eight year period in which you remind us that Haiku has yet to release anything but an alpha.

Quote:

So all the efforts that I and Maxime Simon have been doing to port WebKit and write a new browser for Haiku are seen by you as complacency?

Haiku didn't ship your WebKit based browser, it shipped an unmaintained build of Bon Echo. Where's the warning that this is just a placeholder for a real browser and shouldn't be used, as users would expect, to check their bank balance, buy a book on Amazon etc. ?

Quote:

Either way others reading this can see your over the top negative bias toward Haiku and you'll be written off as the troll you are.

That would make you the second person in this thread to announce that I'm a troll and no-one should listen to me. If it's true that negative comments about Haiku are automatically inflammatory to Haiku users then I think you've tacitly accepted my earlier point.

Re: Haiku Security

NoHaikuForMe wrote:

Indeed critical debate is much more healthy in the communities you've mentioned. On the LKML for example you have someone like Brad Spengler. Thus an outsider voice would be redundant. The response to "Linux sucks" is not "go away troll" but "show us where and we'll fix it". The x264 author recently wrote about his experience as a non-kernel developer of showing a problem to the LKML and getting it fixed.

I'm guessing that in these cases, constructive criticism is often utilized. Generally when providing constructive criticism, one tries to provide solutions along with the criticism (and no, "stop using this software because it sucks" is not a constructive solution). In a FOSS project, it's generally hard to make everyone happy when there is more work to do than there are volunteers to do it.

In this case, I think that you're assuming that your criticisms are constructive for the project, but to the rest of us it seems your criticisms are nothing more than attempts to frustrate the project contributors and supporters - seemingly insinuating that they are intentionally doing things wrong.

I also find it strange that you concentrate all of your criticism for Haiku here on these forums rather than on the mailing list where most of the project contributors discuss aspects of Haiku that need to be modified or changed.

In any case, I have learned over the last few years that many of your criticisms are certainly warranted, but often poorly expressed in a way that can encourage change - which is why you are often labeled as "troll" I think.

Anyhow, sorry to take this so offtopic.

Re: Haiku Security

The fundamental problem with linux is that a linux system is made out of so many moving parts from different groups, and put together by many different distros, that even if some of the parts are shiny, the entire system acts like crap. Until the linux community standardizes behind a single linux platform and one 'bugzilla', I just don't see how assorted security features here and there will amount to much.

Re: Haiku Security

'.. 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

Re: Haiku Security

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.

Minix is a microkernel operating system. Haiku's kernel, like Linux, is monolithic. So you're comparing apples with oranges.

Re: Haiku Security

NoHaikuForMe wrote:
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.

Minix is a microkernel operating system. Haiku's kernel, like Linux, is monolithic. So you're comparing apples with oranges.

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.

Re: Haiku Security

Bill Hacker wrote:

More accurate, perhaps to say comparing 'fruit with fruit', as - architecture aside - the kernel is the kernel - not the entire meal.

No, that's quite OK, I was accurate before, you were comparing apples with oranges.

Quote:

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.

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.

Re: Haiku Security

Quote:

Ultimately, even if you somehow ignored the fact that X is much better designed than these toy window systems you mentioned,

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.

..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.

Quote:

This particular dancing bear is principal ballerina.

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.

Re: Haiku Security

Bill Hacker wrote:

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.

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.

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.

Re: Haiku Security

Mea Culpa - that handle 'NoHaikuForMe' was fair enough Troll-Warning that I should not have wasted the time. And not just an average troll, either...

Giving credit where it is due, I must say that the amount of contradiction you manage to squeeze into each single sentence is only exceeded by its misinformation content.

Dr. Pauli had your number first:

'That's not right. It's not even wrong'

Re: Haiku Security

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

Re: Haiku Security

Bill Hacker wrote:

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.

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.

Bill Hacker wrote:

'Glued on' after the fact simply will not do. See Windows.

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.

Re: Haiku Security

Bill Hacker wrote:

Just note how few participants have appeared in this thread.

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

Re: Haiku Security

koki wrote:
Bill Hacker wrote:

Just note how few participants have appeared in this thread.

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

.. 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.

Re: Haiku Security

Bill Hacker wrote:
koki wrote:
Bill Hacker wrote:

Just note how few participants have appeared in this thread.

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

.. and therein lies another problem.

It would be advantageous if 'proper' advert-free MLM hosting could be found for the Haiku project.

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*.

Re: Haiku Security

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.

Re: Haiku Security

koki wrote:
Bill Hacker wrote:

Just note how few participants have appeared in this thread.

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

Alternatively, someone subscribed to one of those mailing lists could post a message there with a link to here...

Re: Haiku Security

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).

Re: Haiku Security

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.

Re: Haiku Security

Bill Hacker wrote:

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.

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).

Bill Hacker wrote:

How else can you describe how it works?

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.

Re: Haiku Security

.. '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.

http://www.barrelfish.org/

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

Re: Haiku Security

Bill Hacker wrote:

.. 'inobtrusive' w/r any 'sandboxing mechanism' that actually works is an oxymoron.

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.

Re: Haiku Security

.. 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...

Re: Haiku Security

Bill Hacker wrote:

.. 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?

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.

Bill Hacker wrote:

Another Windows we do not need...

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?

Re: Haiku Security

I know I'm a noob but as a user there some things about system design I have never understood.

Like how Windows has games and little apps like notepad.exe in system folders rather than placing all those small applications in the program files directory. How Linux scatter files across a billion different directories.

Yes I know with Windows is a throwback to 32-bit and legacy applications. In one sense there the problem how future features might need to change/break the design of the OS. I find Linux really bad at supporting legacy applications. I am often amazed at how many packages need recompiling for each new release for some Linux distributions.

In a sense I am wondering the same thing for Haiku. In the quest for being able to update for security reasons how will that affect legacy applications(breaking libraries or API), the difference between having an evolving OS from people who do updates, the difference between those who do clean installs at major releases and those who are like me if their system is running fine don't feel the need to update( if it ain't broke don't fix it).

I know I might be getting confused with Haiku with it's API and with packages having their libraries and dependencies in the package as compared to a linux type OS but will you after a few years or a number of major releases be able to find an old package of a program you really want that says something like FOR R2 or R3 and above. I have heard some people have kept old versions of Linux to run a specific program that is no longer maintain and all the libraries have updated around it.

What about, in the future large projects like open office that might update slower than future official releases. If you update a system library for security reasons and it breaks open office are you going to be running two library versions of the file in the system directory. ( I guess this is were virtualization comes in)

Two of my pet peeves with OS's at the moment is 1: system file creep in which your system directories are ever increasing in size and 2: you really can't tell where your clean install finishes and what you have added to the system begins because files have been placed everywhere. So we get install/uninstall programs but they don't catch everything like config files that a program might write when it runs or registry entries.

What I would like to see in an OS is a system folder that represents a clean install locked down to be made read-only. Any changes in config files be written to a administrators system directory, any updated libraries or patches be written to the administrators system directory as well as any third-party drivers etc. Have the OS probe the administrators system directory when it boots use any libraries, config files and drivers that it finds their else use the OS's system folder. Some people like the ability to be able to copy a programs to anywhere and the program should run. I'd like the same type of feature for the Administration directory. If you were to copy it or back it up you have all your updated libraries, drivers and config files etc.

I don't know if this is pie in the sky or just a dream but for the OS system directory I would also like something like this.

System
!
!--R1
!
!--R2

Each major release gets its own directory in the system folder. For a legacy application I'd like to be able to point it - if I wish to use the libraries from R1. Each major release is a clean break from the previous release so if there are any major changes you can point legacy programs back to previous libraries and old API. Delete the R1 directory if it's not needed replace it if you have program that does and in once sence it forms a standard base. A given sets of libraries that are always present on the machine not replaced by updates.

I wonder if any OS can avoid the crawl over the years that has caused Microsoft to decide to put XP under emulation in Windows 7 or how MacOS change to Coca but I would like going to multi-user to offer more to the system than just security. Yes I understand you are recreating Beos but you are already beginning to break with GCC4. I am no developer so am not sure that any of that is possible.

Just thinking out loud :)

Re: Haiku Security

'manifest file' ... see the 'environment' division of any COBOL program.

But time has moved on. What is not abstracted is virtualized. A COBOL environment could specify that it required two or three tape drives, and even which models and where and how attached. Other 'divisions' then specified what input was required, and what output coudl be expected.

Enforcement, sadly. was largely up to (s)he who submitted the punch-cards - not the often not-yet-existent-as-such 'OS'.

Fast forward to an editor operating on files that may on detachable media or be NFS or FUSE mounted from half way 'round the world - where you are not really even certain that the underlying storage is case-preserving, let alone UTF-8 (or other).

Bottom line? Expectign an app to provide useful info about what it might want to do, with which, and to whim, is 'too complicated' for a lean, fast environment.

But (see barrelfish, among several others) 'what if':

- Each 'build' shipped with all executables hash-signed, a table of said hashes compiled into that build's kernel, or 'near as dammit' - e.g. - table loaded by the boot process with the *table's* hash compiled in, then 'trusted' for the hash of the entries.

-- At 'level Zero' all such that match are authorized w/o human intervention.

- Any changes - and there will be many - go to 'level 1' where a MOFU [1] has to auth them *once* at which point they are added to a secondary, but persistent, (encrypted, on-disk) table. This survives reboots.

- Apps, which devel team may not ever even *see*, got to level three. 'Vetted' when first run by a MOFU [1], optionally lower-level 'Admin/Boner [2] but stored only in RAM, e.g. do NOT survive past the next reboot. The challenge will be raised again.

Imperfect? Absolutely! Willingly stipulated as such.

But simple enough to at least raise a flag if/as/when malware arives at the gates.

At the end of the day, 'complete' security is a myth. Even the most hardened systems can still be brought to their knees with use of perfectly sound and fully authorized apps, if only by causing resource exhaustion.

So - better ways exist, I am sure. But 'KISS"

Whatever else is done - let us not fail to take advantage of the extensively documented mistakes and successes of others who have gone before. Dig out and compare the alternatives under a strong light. Weigh cost vs benefit.

Haiku doesn't need to be fully hardened. Just strong enough that 'most' attackers will seek easier targets, and most others will at least raise a flag and be logged.

Bill

[1] 'MOFU' Master Of the Finite Universe. Pronunced as in Chinese Taoism, meaning roughly 'without any (magical) protection', and used in the vernacular to describe a situation one is powerless to resist or change.

[2] 'Boner' Box owner. Interpretation left as an exercise for the reader...

;-)

Re: Haiku Security

Bill Hacker wrote:

Bottom line? Expectign an app to provide useful info about what it might want to do, with which, and to whim, is 'too complicated' for a lean, fast environment.

Too complicated for whom/what?

The user? - he will not be bothered unless the application tries to do something it's not supposed to do. Actually the OS can silently refuse access without bothering the user at all.

The developer? - he spends a lot of lot of time to developing/port the application. He can spend another hour writing the manifest. OF course the manifest format must be made as simple as possible.

The OS? - most modern OS already have something similar - SALinux, Windows UAC, Solaris Trusted Extensions... Sooner or later Haiku will have to implement something similar. Because if for instance the PDF viewer happens to have a zero-day code-execution bug - how do you stop it from wreaking havoc with your system?

The manifest can also be generated automatically - whenever an app tries to do something it's not supposed to - the user can be prompted to add an exception in the manifest. I don't think this should be available to the average user, but the developers can use it to easily generate the manifest.

Even having manifest only for the most exploited apps - like the browser, media player, document viewers can still be a huge boon for security.

Re: Haiku Security

Each application should come with a manifest file that specifies what it should be allowed to do. If the manifest file is signed by some authority(e.g. Haiku Inc.) - the app is installed and no questions are asked. If the manifest is not signed and requires for instance system access - the user has to confirm the install, if he chooses he can get a simple list explaining what the app wants to access.

What the manifest file should contain:
- Whether the app is allowed to read or write to certain folders or files - the app folder, system files/folders, files of certain types, files choosen by the user in the Open/Save dialog...). A sane default for most apps is to allow access only to the files selected in an Open/Save dialog, the files from the application folder, the filetypes associated with the application and the files that the application has created itself.
- What libraries can it use (it can safely use any libraries with a matching manifest file)
- What API functions can it use
- What network resources it has access to (is it allowed to access the Internet, what protocols, on what ports, should it access only certain domains - like an update server, etc.)

Re: Haiku Security

'Sandbox' ing, 'jails' 'chrooting', 'vkernel' - even virtualizers as a class - all have valuable places in the grand scheme of things.

But don't confuse any of those with system-level security. It is distracting.

Security needs to be low-level, pervasive, persistent, more trouble to defeat *without detection* (it can ALWAYS be defeated somehow or other) than the effort is worth.

Also 'light weight', easy to admin, and inobtrusive.

The last three are the challenge.

Others may disagree, but I have no objection to a largish increase in initial boot time, perhaps to set up encrypted storage, memory, or communicaitons services.

Nor would I object to a signficant increase (five seconds or less should be more than enough) in the *initial* opening of an app where the delay is due to credentials being checked.

I just do not want to forever-after continue to pay a 'security subsystem tax'. IOW - once 'vetted' an app or utility or service should run unencumbered, save for things such as whether it has rights to read, write, or even 'see' a specific file or portion of the file system - those being either already in-place or easily made so.

One of the reasons that IPL and app opening is not on *my* critical path is that idle/resume is already well-handled, and hibernation / save-state can become so.

Many of us tend to run long-lived platforms and sessions, especially laptops with inherent 'UPS' when on mains power. The IPL penalty is lost in the 'noise' when one boots less than once a week. 'Sandbox' and similar overheads, OTOH, may be present at every keystroke, mouse move, packet transferred, or 'whatever'. If Haiku goes down that road, it is no longer lean. mean, and hungry, and I'm better-off with Solaris or a *BSD, as these at least are already expert at that sort of thing.

JM2CW, but a bit of work on a safe and well-drained foundation does a house more long-term good than adding storm doors or a new set of curtains.

Bill Hacker

Re: Haiku Security

I would just like to direct people to this thread about using Sandboxing as a security feature.
http://www.haiku-os.org/community/forum/sandbox_securitymulti_user_idea

Porting Systrace from FreeBSD would be great.

Re: Haiku Security

Glance 'with a long spoon' - as the Nazgul are just about the last folks on the planet one wants to get into an IP-rights tussle with ... (see SCO).

Plan9 might be a friendlier model, license-wise...

Bill

Re: Haiku Security

On the general topic of security, not any specific post ....

Research is in order before we go off into disagreements.

'Of interest':

- Plan9: - has no 'root' superuser. A user has been granted a collection of privileges unique to what resources they have 'plumbed'. Worth a look.

- OS X: - 'root' superuser not enabled by default, nor need an 'Admin' be a member of the classical 'wheel' group. Major changes, such as installing software, are 'challenged' for an Admin user ID & password. Enabling 'root' is still permitted. Decent balance of security vs convenience in long term use.

- Barrelfish: - (experimental) postulates a database of vetted binaries. Not the first to do so, but 'of interest' because it is also largely a message-passing creature, as is Haiku.

- TuDOS: - uses a compartmentalization scheme at very low level that, for example, (should) make it very difficult for one online-banking session to be at all interceptable by anything else the system is doing at the time.

- OpenBSD: - has protected memory, encryptable swap, and a host of other security gadgetry that does seem to work well. Mind - it ain't 'free' as far as CPU-cycles or disk I/O go, so OpenBSD is generally slower than its cousins - but very stable as well as secure.

- OS/2 & eCS: - while cousins under the skin to DOS and WinWOES, had a much better security model, despite being essentially single-user creatures, as Haiku is (still, yet).

- Syllable: Another desktop/integral-GUI risen-from-the-ashes OS (not the 'Server' version, which is Linux-based)

BTW - w/r the BeOS heritage and 'single user' - the (illegal?) PhOS variant of BeOS was also multi-user, (and not the only such), was it not?

Gotta start somewhere - whether 'enterprise' use is, or ever will be, a factor or not.

Many of us have at least one family member (or wannabee) with whom we should be able to share 'the computer' without getting into each other's environments. At the moment, that is supported - but in no way *enforced*.

No one - not even a hobbyist - really wants to have an OS that exhibits the behaviour for which Ganymede was notorious.

;-)

JM2CW

Bill

Re: Haiku Security

In OS400 (AS400's operating system), system objects are all derived from a virtual object whose only function is to implement security features.
this approach is very elegant ... and effective.
IMO : we should cast a glance on it

Re: Haiku Security

Speaking of security ..... Someone will look at this? : P or publish the alpha with a shell account for intruders ... xD

http://dev.haiku-os.org/ticket/3776

Regards!

Re: Haiku Security

I think that for have a secure system we need to continue with the Haiku philosophy: USER FIRST!

So the installed application must only write their config, logs and so on in their installation folder, if they MUST write in an another folder must prompt the user for insert the password... but I think is not must so invasive as in Vista was... simply the application must avoid to write in another folder!

Another security threat is when an application want sends user information on the net... Haiku must asks the user the permission... the only legit "net" search is when the apps must search for updates... but I think the updater must be system wide so... the application haven't to go online for this, too!
Obviously an e-mail and a Browser application must go online where the user want :-)))

I'm talking of this in the AppFile discussion... but I think application installation can be a security argument, too.

And to adds another security level (if this is not sufficient) the application sandboxing
may be an option too!