[UCLA-LUG] my take on the virus...

[David Braginsky]

perhaps i am missing something, or perhaps you didn't double-check the url?

> -----Original Message-----
> From: linux-admin@linux.ucla.edu [mailto:linux-admin@linux.ucla.edu]On
> Behalf Of Dan Helfman
> Sent: Sunday, May 07, 2000 1:20 AM
> To: linux@linux.ucla.edu
> Subject: Re: [UCLA-LUG] my take on the virus...
>
>
> On Sun, May 07, 2000 at 12:13:14AM -0700, mike chan wrote:
> > dan,
> >
> > i think its time you wrote up a capabilities OS.. =)
>
> It's already been done: http://www.eros.org/
>
> But it sounds like it would be a fun thing to write. So many projects, so
> little time!
>
> > NT/Win2k uses a role/policy based system.. that isn't bad.. but needs to
> > be WAY more extensive... =)
>
> I really don't think a role/policy system is the way to go. Correct me if
> I'm wrong, but each person is given a role, which comes along with certain
> abilities that can be granted or taken away. But the checks for
> whether you
> are performing a valid action are done *every time you perform
> that action*
> (.. the same way Unix file permission checks are done every time
> you try to
> access a file). This means there are a whole slew of messy if-statement
> checks that have to be done in order to figure out whether you're granted
> access to doing something. This is Bad because 1) it's slow, and 2) it's
> very complex and thus error-prone (see Ockham's Razor), which doesn't bode
> well for system security.
>
> With capabilities, there *are no checks* to see whether you can perform an
> action! If you have a capability to do something, you can just go
> ahead and
> do it. No overhead, no testing. The only way that you can't do
> something is
> if you don't have a capability to do it in the first place. It's like the
> combination to a safe. The safe doesn't check whether you're a system
> administrator or whether you're in the wheel group before it'll
> let you open
> it. If you have the combination, you're in. And the only way you can *get*
> the combination to begin with is legitimately, because you can't forge
> capabilities (more on this below).
>
> > if it were extensible like XML, it would be great... this is a massive
> > awesome project that someone w/ a lot of time and money should take up..
> > =p write the first production level OS =) now here's a question.. do
> > programming API's need to change, or is this strictly a OS
> level enforced
> > thing...
>
> There are two basic ways I know of to implement capability-based security.
> One is at the OS level, where a capability is essentially just special
> hidden bits in memory.. that signify whether you have access to a certain
> object. Think of it as a sort of unforgeable pointer composed of bits that
> an application program or user can never see or modify. With the pointer,
> you can access the object it points to all you want: make copies of the
> capability, pass it to another process to delegate some work, whatever.
> Without the pointer, it is absolutely impossible to access the object
> because you have no way of getting a pointer to it! This is how
> Eros and its
> predecessor KeyKos do capabilities.
>
> The other way to implement capabilities is at the language-level, so that
> you have your compiler do compile-time checking to make sure that no
> capabilities are forged and that no memory is accessed except as
> allowed by
> the capabilities that an object has. The obvious downside of solely
> language-level capability checking is that a rogue binary can upset the
> whole security model. So obviously OS-level capability-based security is
> necessary if you want to be able to run untrusted binaries securely.
>
> > wouldn't the email program have to "say" that it's an email
> program? could
> > an email program emulate a "file browser" and therefore gain its'
> > capabilities to modify files?
>
> Nope, instead of a program having a "role" and getting abilities
> as a result
> of which role it has, the user operating the program grants it the minimal
> capabilities it needs. So when you first install your email client, the
> sysadmin might give it a capability to connect to the local mail
> server, and
> maybe a read-only capability to the program's own site-wide configuration
> file. It doesn't need to do anything else (externally), so you
> don't give it
> the *ability* to do anything else. If on a particular occasion you want to
> attach a file to a document, you might give it a temporary
> capability to the
> single file on your system that you want to send in your email. But it
> doesn't need any access to any other files in order to send your one
> document.
>
> There are some interesting implications of this security model.. the whole
> Unix notion of a traditional filesystem would have to go out the window.
> Right now, you request to open a file and the OS checks whether you're
> allowed to. With capability-based security, it would be impossible for a
> program to request to open a file unless it was actually able to
> open it. So
> there would need to be some sort of means of representing a
> capability to a
> file.. like an unforgeable filehandle composed of hidden bits.
> Eros handles
> this problem by not even having a filesystem at all. :)
>
> > i just find it funny that programs like outlook actually have a
> "super-low
> > i don't care if i get hit by a virus security level" where it allows any
> > file to just be executed... =p ah well.. people just need to
> clue in.. =p
> > haha
>
> Yeah, I think that this is one valid complaint that can be made in regards
> to Windows and macro viruses. Although Microsoft could conceivably port
> Outlook to Linux and have the same security problems, the fact of
> the matter
> is that most Linux mail programs are slightly smarter when it comes to
> untrusted scripts.
>
> >
> > mike
>
> --
> Dan Helfman
> UCLA Linux Users Group: http://www.linux.ucla.edu
> My GnuPG key: http://torsion.org/witten/public-key.txt
>
> _______________________________________________
> UCLALUG Linux mailing list - Linux@linux.ucla.edu
> http://linux.ucla.edu/mailman/listinfo/linux
>