OSDev.org

just curious...

how does this guy work? i mean i'd like to look at sources of one!

Can someone explain what kind of support we need to have in our own kernels so that some day, when implementing or porting an open source antivirus (if any, i guess there is), we do not run into trouble?

Well... you're not entirely clear, but I assume you're talking about running an antivirus application within your own OS. I would suspect it to be pretty easy, except that you would not know the viruses. Would you be checking on viruses for your OS or for viruses that affect some other OS?

I mean an application.

yeah. I can't possibly think of all the kinds of virus attacks i might get. but it should be able to account for some common categories, and i guess i need to take special pains in the implementation to make the cops' life easier.

The best antivirus you can get is good (and equitable) security model. Forget about 'fixing things' after the catastrophy has happened.

In my opinion an OS with a good design shouldn't need an anti-virus program at all. You shouldn't allow untrusted programs to run, and the programs that do run should have the least amount of permissions as possible in order to function.

I agree with Cheery's point on this

I'm going to go along with most people here already, if you make a proper design, you shouldn't need an antivirus, malware detection or firewalling tool. Pretty much all that Symantec lives on is superfluous, had the design of Windows been proper in the first place. The two-way prisoners dilemma however requires that the most popular (most used...) OS is the least secure one, up to a certain level. People choose for the least enclosing, most freeing OS, therefore rendering all reduced-functionality OSes into forgetment. Also, bits that can only be done on a bit of software that allows too much in a way tend to drive people toward developing for hackish systems. People stop using hacks when the easier solution is not to hack.

If you allow viruses, you allow:
- Programs to run undetected
- Programs to be able to nest so deep that they can't be removed without being run at the same time - effectively preventing removal
- Programs to perform things the user doesn't necessarily want

People think that the problem is that the computer doesn't warn them about what a program does or such. One part is that users want all rights, but they want the programs they intuitively use to have the rights they could use and the programs they implicitly start (unknowingly) to not have those rights. If you, however, limit all programs to the amount agreed to between the OS and the user at the installation of the program, those problems don't exist. If the program then does want to use a right, it has to ask explicitly. If these messages are sparse and far between, people will even look at them and think, before clicking "yes (permanently)".

The second is a fundamental problem with windows and one that goes pretty deep. Programs can nest so deep that they are unremovable by normal removal tools. This makes windows more extensible but less maintainable. People focus on extensible first, so by prisoners dilemma you have to focus on extensibility first. Effectively, people choose viruses.

Then there's just the last bit. People running programs that do things they don't want. That's a pretty simple one - hit the user and tell him/her not to do that again. It does require one very specific thing in your OS: being able to start the system without starting ANY of such tools, in a safe mode that is guaranteed virus-free. Windows presented a safe mode in the past that's becoming increasingly less "safe" by this definition, but doesn't protect the actual files that make up this safe-mode. It's not safe to have binaries that were modified by anybody.

This is a pretty high-level OS design thing though, how you want users to be able to affect the way the computer runs, and in how far your computer can take actions that protect its own usability, possibly against the user's will. In how far can a computer program or computer OS go in protecting its own integrity, without harming the users ability to do whatever he/she pleases?

Candy wrote:Programs can nest so deep that they are unremovable by normal removal tools. This makes windows more extensible but less maintainable. People focus on extensible first, so by prisoners dilemma you have to focus on extensibility first.

What do you mean with nesting in this case?

I myself consider it being total lose to use antivirus systems. You lose computer time resources and you have already lost the security if your OS is insecure, so that any AV system cannot regain it.

And why bother about antivirus? That capability system sounded a lot working approach; at times you'd give programs capabilities to interact with very sparse amount of your system, It'd be very hard for the program to do something it is not allowed to do. And you are giving input data for those programs anyway!

Medium/weak security is better than no security at all and a big amount of defending forces inside.

Cheery wrote:

Candy wrote:Programs can nest so deep that they are unremovable by normal removal tools. This makes windows more extensible but less maintainable. People focus on extensible first, so by prisoners dilemma you have to focus on extensibility first.

What do you mean with nesting in this case?

A program that registers itself on the file-open handler can't be removed, effectively. Nesting as in, making the OS so much to its home that you can't kick it out without destroying the OS as well or without using the program that was causing the problem (making the removal uncertain to actually succeed).

I myself consider it being total lose to use antivirus systems. You lose computer time resources and you have already lost the security if your OS is insecure, so that any AV system cannot regain it.

Very true. Yet, still, my windows machine runs antivirus.

And why bother about antivirus? That capability system sounded a lot working approach; at times you'd give programs capabilities to interact with very sparse amount of your system, It'd be very hard for the program to do something it is not allowed to do. And you are giving input data for those programs anyway!

I'm very much for the capability system, but you must not make a system that takes away power from the user. Power in two senses here, both the power that you can do anything you want and in that not every micro-decision is sent to you. Or, don't become another windows in the "yes I really want to delete this file" sense and don't limit the program too much in that it can't do something. There's a fine balance between the two, that also requires the user to think before clicking yes or no. The last one might be the hardest to accomplish in the current Windows-trained world. (how do you install? next-next-next-finish... nobody reads anything).

Candy wrote:There's a fine balance between the two, that also requires the user to think before clicking yes or no. The last one might be the hardest to accomplish in the current Windows-trained world. (how do you install? next-next-next-finish... nobody reads anything).

True, capability based system wouldn't work if done by microsoft. I do not suppose anyone should read anything; when you download the program, it has no capabilities in your system. Not after you specifially give them caps for certain files and devices, thus, there could be temporal capabilities when handling input. When it'd be clear what capability gives control to what action, and which capabilities are usually considered dangerous, it'd be quite safe for even person who doesn't know anything about computers.

And if you wonder about installing software. Simply, installer software wouldn't be mounted to the software package and it'd have caps to create files, get capabilities to them, write them and give newly installed programs capabilities to their own files.

Neither controlling the capabilities by shell shouldn't be any kind of hard task, I can easily think of a syntax for such case:
$ caps +read /dev/keyboard2 program
$ ./program
or:
$ inputfile -> program

If you wonder how shell scripts would work in this case, they'd get their own caps too.

The program capabilities would work as the template for process capabilities, like you could do:
$ caps +read /dev/keyboard4 -read /dev/keyboard2 [23047]
or:
$ caps +read /dev/keyboard4 -read /dev/keyboard2 [program/1]
to give read capability for keyboard nr. 4 and remove it for keyboard nr. 2.

I was going more for a more generic framework in which you wouldn't specify "keyboard4" or "disk2" but more of a

Program XYZ requests to be installed with the following privileges:

+ Full access to files on fixed disk(s)
+ Full access to files on removable disk(s)
+ Access to network
- Access to kernel (*)
- Replacement of kernel functions (*)

The functionality of a program can be increased by granting privileges. The danger of a program can be reduced by retaining privileges. Select + or - for privileges to grant or retain. Press Ok when you are done.

NB: The privileges marked with (*) are not necessary for any ordinary program and should not be granted unless you are a developer.

Something like that in a nice installer dialog box. Intentionally keeping dialog boxes useful, clear and short for quick and concise installation, instead of 5 next's before you get a question.

Also: in the installer dialogs, I think one could really much prevent people using that nextnextnextnextfinish -method if you'd remove the 'next' -buttons from installers. ;D