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

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

As its going to be single user for R1, this is going to be rather difficult...

IBMoid wrote:
2. Try to adhere to POSIX to prevent viruses from destroying the computer.

And? What does that have to do to help security? IRIX adhered fairly well to POSIX yet was possibly the least secure OS of its era if not ever. Windows NT has decent POSIX and.... you get the picture.

Re: Haiku Security

MYOB wrote:
IBMoid wrote:
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.

As its going to be single user for R1, this is going to be rather difficult...

IBMoid wrote:
2. Try to adhere to POSIX to prevent viruses from destroying the computer.

And? What does that have to do to help security? IRIX adhered fairly well to POSIX yet was possibly the least secure OS of its era if not ever. Windows NT has decent POSIX and.... you get the picture.

Single user shouldn't matter. Security is security and limited user accounts are one of the simplest ways to protect yourself from anything that can destroy your system files.

That linux dude was wrong about the it impossible for a virus to affect your system with POSIX. Well, I think it should have some good security measures. A topic at MES got some interested in BeOS. Security measures in BeOS were pointed out by a few members, notably Limited User accounts.

Re: Haiku Security

IBMoid wrote:
MYOB wrote:
IBMoid wrote:
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.

As its going to be single user for R1, this is going to be rather difficult...

IBMoid wrote:
2. Try to adhere to POSIX to prevent viruses from destroying the computer.

And? What does that have to do to help security? IRIX adhered fairly well to POSIX yet was possibly the least secure OS of its era if not ever. Windows NT has decent POSIX and.... you get the picture.

Single user shouldn't matter. Security is security and limited user accounts are one of the simplest ways to protect yourself from anything that can destroy your system files.

That linux dude was wrong about the it impossible for a virus to affect your system with POSIX. Well, I think it should have some good security measures. A topic at MES got some interested in BeOS. Security measures in BeOS were pointed out by a few members, notably Limited User accounts.

You're not -quite- getting the concept of "single user". Its not like its limited to one user with multiple accounts. You are the superuser, the entire time. Thats what "single user" refers to.

BeOS has no security measures; and it most certainly doesn't have limited user accounts. To be compatible with BeOS, Haiku has to stay the same way.

You still haven't explained what you meant by adhering to POSIX to stop viruses, and now you've contradicted yourself.

Re: Haiku Security

MYOB wrote:
BeOS has no security measures; and it most certainly doesn't have limited user accounts. To be compatible with BeOS, Haiku has to stay the same way.

Haiku R1, at any rate. Who knows what R2 will bring?

Haiku Security

Very basic security could be added for a "protected"/"children" mode in r2.

Blocking users/programs from changing application mimetypes
Having a limited run list in Roster, etc

It's always something to talk about on the glass elevator (or here), no?

Haiku Security

Quote:
You're not -quite- getting the concept of "single user". Its not like its limited to one user with multiple accounts. You are the superuser, the entire time. Thats what "single user" refers to.

That is what I'm suggesting not to do(with R2).

Quote:
You still haven't explained what you meant by adhering to POSIX to stop viruses, and now you've contradicted yourself.

Well, I souldn't have listened to some bloated zealot on FriHost.

Quote:
Very basic security could be added for a "protected"/"children" mode in r2.

Blocking users/programs from changing application mimetypes
Having a limited run list in Roster, etc

Better than nothing, I guess...

Quote:
It's always something to talk about on the glass elevator (or here), no?

Don't quite understand what you mean...

Haiku Security

IBMoid wrote:
Quote:
It's always something to talk about on the glass elevator (or here), no?

Don't quite understand what you mean...

Glass Elevator is a mailing list set aside specifically to discuss Haiku R2 and beyond - it's much like this "Suggestion Box" forum, except it's been around longer, and probably has a LOT more traffic.

Haiku Security

Oh, well thank you for listening to my suggestions. I will be sure to download Haiku R2 when it finally comes out. :)

Haiku Security

I used to think "why do i need multi-user...I'm the only one who touches this pc"
then i realized, on the net, anyone can be that single user of my pc!
lots of people with xp home are basically at root and I don't think they know how to adjust

Haiku Security

Hmm... Multiuser, POSIX security.

Yeah. Then the virus can't make my system unbootable (something I can fix in six minutes with a Haiku boot CD), just wipe my home folder (and everything I've worked on since last backup).

Sounds lovely to me!

Re: Haiku Security

MYOB wrote:
IBMoid wrote:
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.

As its going to be single user for R1, this is going to be rather difficult...

I wonder if adding a feature in the kernal to ask for a password to change a directories/files from read to read/write might be an option.

I see 2 things I would want included.

1. To change a directory/files from read to read/write ask for the password and your done. directory will be read/write from then on.

2. If you want to write into, copy, move or delete a read only directory/file get prompted for the password and have it set back to read only again at the end of the process.

I have seen this as a weak spot in some OS's. The harder it is for something to write into a directory or part of the hard drive when you don't want it to the better. Win98 was a classic, any file set to read only could be change in the blink of an eye without you even knowing about it by any program.

From what I have seen and I could be wrong as soon as you log into a root account anything goes again. The log in password was the only check to stop being able to do a whole heap of stuff to the drive yet you might need to go to root to install some programs.

You could still keep it single user but without the option that a program could just write into a read only system directory or over the top of a read only system file by changing it to read/write without a password confirmation.

Just thought of another idea not sure if anybody will like it or if it would be needed. You could have a system directory as read/write so you could update config files as needed. Have other files as read only so they can not be touch an add another permisssion to directories that no new files of directories can be created without the password confirmation. It would tell you if something is trying to write into a system directory that you had to have as read/write because of the config files. I would see it helping to stop something sneaky trying to write into a directory that you had to have set as read/write.

Haiku Security

umccullough wrote:
IBMoid wrote:
Glass Elevator is a mailing list set aside specifically to discuss Haiku R2 and beyond - it's much like this "Suggestion Box" forum, except it's been around longer, and probably has a LOT more traffic.

A lot more traffic? Not really...

http://www.bug-br.org.br/pipermail/glasselevator-talk/

IBMOid: Of course, virtual memory is being used in all modern operating systems, check Wikipedia for an article on this if needed.

But I think, you might mean something different. I would also vote for application sandboxing (in addition to user level access control) as a security mechanism, especially since experience on Windows tells us that only the minority of people bother to use different user accounts for working/browsing/etc and installing applications/system maintenance/etc.

I'd imagine it like this: by default an application would only have access to its own program folder and a sub folder of the user's "documents" folder, that would be assigned to it. If it needs more access, it has to ask the operating system for permission, which in turn would prompt the user to make this decision.

I'd think that would make sense.

Haiku Security

what about a firewall?

Haiku Security

I am going to respectfully disagree with most of the comments here. I also recognize that, while security is very important, it is not a primary focus in these early days of a partial working system. Still, it's a good sign that this is getting discussed early on.

I would say that none of the current security features of modern systems are good enough. Haiku should be looking forward at new systems whose goal it is to replace current broken models for ideas and inspiration.

There is no reason for Haiku to stick with old Unix traditions like the 'root' account. There is no added security by having an additional all-powerful account. Instead, a single user might have separate roles that have different privileges or perhaps applications could be compartmentalized to achieve better security.

Take a look at Fedora's security features and the up-and-coming PolicyKit or even take some inspiration from the OLPC project which has some innovative security features. Sure, some of these don't make sense for Haiku, but it's important to think creatively about this and get as many ideas as possible.

Another thing that Haiku might face in the future is problems associated with the uniformness of the operating system. This is a familiar problem with Windows XP that some effort was made to fix in Vista. Fedora also tackles this with features like variable reordering.

Some References:

OLPC: http://www.wired.com/news/technology/0,72669-0.html
Fedora Security: http://fedoraproject.org/wiki/Security/Features
PolicyKit: Search Google, there's not much info on this except in some newsgroups and code repositories. It will make it's big debut in Fedora Core 7.

Simplified Security

Hello all!!

I'm new here, and I very worried about security. I've always used Windows XP, I'm going to give the opinnion of a Windows-user. After many years searching, at least I've found (I think) the "definitive security tool". It is called "geswall" and can be downloaded at www.gentlesecurity.com. Basically it adds an additional layer of ACLs at application level. It permits any user to create permissions to any application (independently of user account rights) for acceding to folders, services, objects, registry keys, etc. Moreover, it avoids applications for using OLE messages.

The problem? Well, it's a great tool...but very complicated for a non-advanced user. For other part, it's a lot of work to create permissions for each application in hard disk!!! Finally, the non-permission of using OLE eliminates a powerful feature of Windows, and some applications could not work properly.

As one said above, I think the definitive security could be reached with automatized "sandboxed" apps, which only can accede to their installation folders, user folder and memory space, and can execute another apps (for example, internet passwords could be saved in web-browser folder, only browser can accede to them). In addition to that, a system folder with non-critical customizations, but only allowed to write with password; the rest of system folders could not be acceded by any application, only can be reinstalled, no more.

As said here, I don't think the multiuser could add "more security" (??) And what if an app cointaining a trojan is installed thinking it is reliable? Multiuser is an unnecesary complication, the better could be anyone would have his own folder protected by password.

Innovative concepts are neccesary to avoid falling down in "virus career", like Windows. If Win is so extended, it is because of the easy of use with root-account, but forgetting security; people is so used to re-install Win every 15 days, that virus creators have no limits. I've been using Win XP since 5 years, and only been infected once, during browsing with root account. I've been more than 3 years without reinstalling SO and it runs very fast, after a lot of work optimizing it. I don't use antivirus since many time, and have not any problem.

All security process shall be "automatic", so that noone should be worried about virus, trojans, etc...If Haiku is intended to be a realistic alternative to Windows, it shall be as (or even more) easy as Windows, and include non-intrusive security concepts.

Regards.

Page from ubnutu - sudo maybe?

nos wrote:

2. If you want to write into, copy, move or delete a read only directory/file get prompted for the password and have it set back to read only again at the end of the process.

**snip**

From what I have seen and I could be wrong as soon as you log into a root account anything goes again. The log in password was the only check to stop being able to do a whole heap of stuff to the drive yet you might need to go to root to install some programs.

If I understand correctly, are you talking about something like sudo?

I'm personally not a fan of multi-user machines unless there are going to be multiple users. It seems like most folks only ever use but one account, and unless they get badly burned for doing so are unlikely to change. Someone mentioned multiple accounts for different tasks, but folks tend to ignore default extra accounts like NT's 'GUEST'. Heck, I still see default accounts/passwds cropping up in sytems that've been around for years.

Now, I don't like how linux has me set up the root account and then tells me to never use it; but denies me the ability to modify my system unless I go root. I think ubnutu did an okay job with that, by essentially removing root, and password prompting for any 'root' actions.

Personally, the sudo thing also gets on my nerves, but it's not bad. I'd kindda like to see way of verifying the action is coming from the user at their box. See if input is coming from the attached keyboard/mouse, or a secured 'okay' list (for system files/scripts to communicate with each other); if it is, trust them. Otherwise, such as networked connection (telnet, ssh, etc), or not part of the 'okay' list, sudo type verification. This way I could be working on one machine and still change another on my network, I'd just have to validate myself a lot as I was doing it. Or get out of my Laz-E-Boy, walk to my desk and avoid the password nagging.

Of course that's no good if you're worried about physical access to your computer, but if someone has that, all the security in the world won't really matter.

Just my thoughts.

Re: Haiku Security

Haiku without security won't be taken serious in any kind of enterprise environment. Without user accounts i'd probably never share a computer that had any personal info on it, which would be my laptop, or desktop.

My two cents.

I didn't mean to reply to your post but rather to the whole thread.

Re: Haiku Security

Hi all,

Would a program analogous to rkhunter on linux be a useful, or even possible addition to Haiku?

Besides actively looking for the rootkits, they check that various /bin's are up to date and that their MD5 sigs tally with those of the official releases

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!

Re: Haiku Security

The downside to not writing preferences to a single location in the system is that it makes it nearly impossible to quickly backup all your application settings/preferences. Also, it makes it less useful on a multi-user system.

For example: If I have a few applications, say a mail reader, an internet browser, and an IRC client, and 3 different people use the machine, I would prefer if each of those applications stored their preferences in a user-specific location (e.g. ~/config/settings like Haiku currently does)... same with storage of data - I want my mail stored in ~/mail

This is actually more secure, so that individual users cannot access each others files/data. Imagine the browser stores it cache per user, then each user can only access their own browser cache.

I can then backup (or move) all the settings for a specific user, across all applications at once without having to hunt for them.

If each application is limited to the directory it is installed in, this becomes... painful.

Are we talking about security of the user? or security of the machine?

Re: Haiku Security

fano wrote:

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!

This is, in my opinion, a bad idea.

For example, I'm currently writing an application that adds a new filetype, and indexes its attributes. While the files themselves may be stored in user folders, nothing requires the user to store the files there; a user may store these files everywhere she wants to, even in system folders. (You said yourself - user first, so if a user wants to store these files in system folders, nothing should prevent him/her from doing it). But this means that my application will constantly monitor all of the system. Surely, using queries and live queries, but anyway, it will be system-wide. Besides, the application will have constant access to index of all BFS volumes mounted. A cherry on the pie, my application adds an attribute to a randomly chosen system file (something like kernel or libbe.so), to prevent illegal distribution of the commercially sold copies and to distinguish between shareware and bought copies. Surely enough, it also accesses the Net, not only to check for updates but for other purposes (syncing with the Google servers, for example, and validating the copy is legal for use).

Ok, I'm a bit exaggerating about constant access to system folders, but you got the point.

Your suggestion will require the user to enter his/her password every time my application accesses global index, system file(s) etc., or at least once - upon launch. As you may understand, this is, IMHO, unacceptable. No-one will enter his password for every application that wants to perform a system-wide search, or connect to the Net, or access other folders except application's own, even if the password is required only once per session. Reducing the need for entering passwords by creating tiers of applications is useless either, because a malware may sneak into improper tear: either you check every application every time, or you leave the system unsecure.

As a matter of fact, it may be even easy enough to create a sniffer that will acquire a user's password in this (very legal!) way and send it along with the IP address of the user to a hacker... Thus making the system much less secure.

I hope I didn't understand your suggestion wrong :)

Re: Haiku Security

OK Urias, we can think of a list of trusted directory in which an application can write without user password:

~/config/myapp/
~/mail for mail application

and so on... but for example I don't want that an application says Bezilla write something in
~/config/OpenOffice/... maybe it can't read in that folder too... it haven't to exist for it!
A sort of sandbox.

It is obviously that in case of OpenOffice if the user want save a file I can choose all folders... but is the user to do this, not the application itself...

I think we must find a just balance to user security and machine security.... at the same time we can't ask the user password too much as Vista does... if we do that the user click OK without reading it!

Re: Haiku Security

hitech wrote:
fano wrote:

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!

This is, in my opinion, a bad idea.

For example, I'm currently writing an application that adds a new filetype, and indexes its attributes. While the files themselves may be stored in user folders, nothing requires the user to store the files there; a user may store these files everywhere she wants to, even in system folders. (You said yourself - user first, so if a user wants to store these files in system folders, nothing should prevent him/her from doing it). But this means that my application will constantly monitor all of the system. Surely, using queries and live queries, but anyway, it will be system-wide. Besides, the application will have constant access to index of all BFS volumes mounted. A cherry on the pie, my application adds an attribute to a randomly chosen system file (something like kernel or libbe.so), to prevent illegal distribution of the commercially sold copies and to distinguish between shareware and bought copies. Surely enough, it also accesses the Net, not only to check for updates but for other purposes (syncing with the Google servers, for example, and validating the copy is legal for use).

Ok, I'm a bit exaggerating about constant access to system folders, but you got the point.

Your suggestion will require the user to enter his/her password every time my application accesses global index, system file(s) etc., or at least once - upon launch. As you may understand, this is, IMHO, unacceptable. No-one will enter his password for every application that wants to perform a system-wide search, or connect to the Net, or access other folders except application's own, even if the password is required only once per session. Reducing the need for entering passwords by creating tiers of applications is useless either, because a malware may sneak into improper tear: either you check every application every time, or you leave the system unsecure.

As a matter of fact, it may be even easy enough to create a sniffer that will acquire a user's password in this (very legal!) way and send it along with the IP address of the user to a hacker... Thus making the system much less secure.

I hope I didn't understand your suggestion wrong :)

Hem not offence but or your application is a part of the system (and Haiku's part haven't to ask passwords) or well is the type of things that i can't accept... I can understand it must do queries to add new filetypes but I don't like it to touch libbe or system files for its shareware controls... is this so necessary?
It can't create a sort of hash file in the application directory or add this attrribute to itself?
The net maybe is a necessity if you want be secure your application is not cracked but it MUST prompt for password... if it was a malicious software instead of your application the user must known that it wants send something via network... we can't repeat the windows errors!
Maybe we can ask only the first time or add a "remember my setting for this app" checkbox in the alert... so after the first net access Haiku not ask ever for that application!

Re: Haiku Security

What the application can and what it can't - this question is off-topic.

Here is the genuineness verification design: I, as the applicaiton designer, design it in the way that will be difficult to spoof. To do so, I add attributes to files that surely exists in the system; the attribute's data is a (big) numeric value calculated from app's version, buyer's ID, chosen system properties etc, - a number which is unique enough to identify the customer. The attribute's name is obscured to make it more difficult to find which attribute controls this data; in additional, the application adds some random numbers in attributes to other files, so the hacker won't know which attribute is the real check. (Surely enough, there may be quite a few "real" numbers, all calculated in different ways, as well as quite a few of the "barren", "vain" ones, - it's not a good idea to put all eggs in one backet). Upon startup of the application, a "real" attribute value is read (randomly chosen from the pool of "real" attributes), and corresponding value is recalculated from the available system data, they are compared. Simultaneously, the value read from the attribute is sent over the Network to a central server, which contains all "real" numbers received from the client upon installation (no user data, of course; the data that composes the numbers is not reversely calculable). Any of these checks may be performed several times upon need. After these comparisons, the program decides if it's a genuine copy or a pirately distributed one, and acts accordingly. E.g., triggers full HDD erase :-P. Just kidding. Honestly, I see only one way to break this system: edit the binary application's file and replace the "jump_if_zero" instruction representing the main decision "genuine / hacked" with "no_op" (or "unconditional jump") instruction. Surely enough, this may be checked also, e.g. by hashing the contents of the application's file, but this is well beyong the scope of this discussion.

To be sure that a potential hacker does not find these attributes, they are attached to the files which surely exist in the system. These are: the application's files (duh), libbe.so, kernel file, Tracker file, Deskbar file, B_USER_SETTINGS_DIRECTORY/tracker/TrackerSettings, etc. (I won't reveal all of them here, but you got the point). This way I ensure the application can't be portable (see, due to the application's nature, there's no meaning for it to be portable) and can't be distributed freely.

Is this way of action acceptable? Surely it is. I don't compromise the system in any way, I don't acquire or store the user's data, I don't open any security holes for the attacker to come through, I even don't modify the system's binaries. Heck, I don't touch any file, I modify only the attributes which are not part of the files.

The difference here is between "User is god" system's architecture to "User is slave". The first one is Linux way, where any process running with root's priorities can do anything, including modification of system files. The second way is Windows, where even the Administrator can't touch some places in the system. However, surprisingly Linux is much more secure then Windows. Doesn't it mean that Linux' way of action is better?

I agree that user may be limited; however, I have strong objections to it. But not application. If performing any checks, then base it on user's account properties, and don't do it per application. And, of course, allow user to run applications under other user's credentials.

Re: Haiku Security

double post, comment removed.

Re: Haiku Security

Alex wrote: Here is the genuineness verification design [...]

You can't bootstrap this from software, try Googling “The Client Is in the Hands of the Enemy” for discussion about a similar problem in Massively Multiplayer Online Games and this family of problems generally.

The generalisation of this problem to our own experience is a topic of epistemology.

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

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

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

'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

[quote=myob]

IBMoid wrote:
As its going to be single user for R1, this is going to be rather difficult...

Just to clarify, R1 did not, in fact ship 'single user'. There were two:

- The de-facto MOFU or 'root' identity, AKA 'user' / Yourself

- The sshd identity.

Generating keys, enabling sshd, adding (at least) one additional identity, setting passwords and home directory was vanilla Unix, albeit with a bit of Linux / SVR(x) flavor.

Therafter, one can ssh in to a/the new identity, and do so more than once for multiple, simultaneous ssh shell sessions. Ditto multiple on-box 'Terminal' shells with different login IDs.

Ergo Alpha R1 is no less multiuser than 'normal' - just does not by default insist on login etc.

The only caveat I have run into (so far) is that it respecteth not the /home/userid assignment in ~/etc/passwd, even if such a dirtree has been created and chowned beforehand. Easily fixed, that.

Lazy, I am, so I don't care if other folks want or use such privilege separation or not.
I am just grateful to find it was already there if/as/when wanted so that *I* can use it.

Thanks for that...

;-)

Bill Hacker

Re: Haiku Security

Bill Hacker wrote:

Just to clarify, R1 did not, in fact ship 'single user'. There were two:

Quote:

Lazy, I am, so I don't care if other folks want or use such privilege separation or not.
I am just grateful to find it was already there if/as/when wanted so that *I* can use it.

There is no privilege separation, its an open question whether Haiku can be retro-fitted with privilege separation, but today it doesn't have it, just a toy version of the Unix user-group-other file permission rules. Without the rest of the Unix security model, the file permission rules are just a nuisance.

Re: Haiku Security

"...an open question whether Haiku can be retro-fitted with privilege separation..."

Eminently do-able, but early days yet, so not sure how hard it would be. Will be 'aving a recce.

So far, the Haiku GUI API (which is not necessarily 'entangled' with security, per se for a single-seat, single monitor/kbd/pointer rig), looks to be incredibly clean vs X-Windows.

Remains to be seen if it would be easier to implement a Haiku GUI API layer on some other already-security-aware kernel (Plan9, barellfish, a *BSD .. 'whatever'). Or to work a minimalist, but reasonable security model into Haiku.

Haiku doesn't have to compete with OpenBSD. Entirely different target.

But neither should it be less secure than NT4 or OS/2.

As said - I'm not for boiling the ocean for those who don't see the need on their turf.

I'm just after my cup of tea not being easily contaminated.

Bill

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

'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

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

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

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

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

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

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

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:

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

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