Re: Vista security


"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message
news:20070324125936.GB4282@xxxxxxxxxxxxxxxxxxxxxxxxxxx
On Sat, Mar 24, 2007 at 08:48:52PM +1000, cr88192 wrote:

"Robbert Haarman" <comp.lang.misc@xxxxxxxxxxxxx> wrote in message

Trust the user? LOL.


IMO, if the user messes something up, it is their own damn fault...

Sure, sure. But trusting user input is a good way to throw security out
of the window. I don't think that this is a problem when it only affects
that user, but, in today's world, that isn't the case. If I have my
numbers right, about 90% of email traffic is spam, and about 80% of spam
is sent by infected Windows machines operated by home users. Not all of
that is the result of trusting the user (unless you extend the
definition of that to include the decision of what software to run and
what security policy to follow), but some of it is, and it's just one of
the problems. In short, bad decisions by users can and do affect the
whole networked world.


that is part of why I say, not to trust the software.

oftentimes, this kind of software will install itself without the user being
notified (ie: by scripts embedded in websites, ...).

yes, it is true though that many users make bad decisions.

I am not saying not to use security, but in my view the security should be
done "differently", ie, by heavily restricting and/or sandboxing the apps,
and in different ways than are used for the user, rather than limiting the
user and restricting apps only because it is the user that is limited.


I think, the OS should more restrict the applications than the user. let
the
user go and alter system files if they so feel, but not the applications.

It's not that simple. How do you distinguish the two? How does the user
even alter system files _without_ going through an application? Is
reserving the privilege of altering system files to humans actually a
good idea? Just two name two things: you lose the ability for installers
to automatically register themselves with other software (e.g. PHP
enabling itself in the Apache configuration file, or programs updating
file associations), and you force users to take decisions that might
well have security implications, quite possibly without these users
having taken the time to understand the issues.


possibly, but it depends IMO.

I am saying that different apps have different security levels, for example,
things like web-browsers and email clients are kept in a kind of sandbox.
even if a virus breaks through the app, they are restricted in that the app
is unable to use various system APIs (in the case of an email client or web
browser, it is restricted only to its own data).

as such, then a virus not only has to break the app, but also the OS's
security.
since the OS is typically seperated from the app via memory protection, and
the interface is via syscalls, this should be an easier task.


some tasks, ie, those handled through the OS, or in cases where the app is
set to verify, if not strictly deny, will gain a kind of "seal of approval"
from the user, allowing certain tasks to be performed.


in my case, I have had a few occurances of apps installing themselves absent
any kind of consent. for example, at one point, one program (either firefox
or yahoo im, or some other program) did automatic updates, and then went and
installed yahoo toolbar. at this, I was annoyed, and went and uninstalled it
(actually, as a general rule I don't run yahoo im much of the time, since it
does annoying stuff and I suspect leaks system resources, or at least
something is doing this).


many developers assume that users are stupid, much as many language
designers assume this of the programmers. I disagree on both these
points.

It's not necessarily a matter of being stupid as much as it is a matter
of not having enough expertise. Often, the bar is just too high.
Computer security is complicated, and even those who have dedicated a
lot of time and energy to studying it do not always take the right
decisions. Can you seriously expect someone who isn't interested in
computer security, and only uses computers as tools, to make the right
choices?


maybe, maybe not.

however, IMO, the OS is hardly doing a very good job either much of the
time. some more things I would like notified and verified, and some less
things I would like to be notified about as well (of particular note here:
little pop-up notification messages one has to click to dispell, like that
the network has reconnected, ... and endless "are you sure you want to do
this?" dialogs).


and so, everything is ass-backwards.
the user has to verify lots of little things with endless dialogs, and the
apps meanwhile can go and do things absent user consent.


the problem then is how most current OSs handle security.

at present the only real way to restrict apps is to run them as more
restricted, often synthetic users, and afaik this is typically not the
default (linux does this for some apps, don't think this is done on windows
though).


my ideas for security had been, rather than being "user"-centric, they are
"key"-centric.

so, rather than restricting system files by say, whether it the user "foo"
or "administrator", and setting up ACLs accordingly, it is based more around
whether the user, or the app they are running, has a certain key (ie:
"sysfiles" or similar).

as such, when a superuser initiates an action, this key is passed to the
application (likely, this would depend on how the app is set up and how it
is spawned), and the application then has the right to perform the action
(but not other actions).

and so on...

in this case, a restricted user thus lacks keys, so they can't give keys,
and thus not perform tasks.


Regards,

Bob

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.


.

Relevant Pages

  • Re: Are bad developer libraries the problem with M$ software?
    ... rarely poeple on security lists. ... If you want to add language specific content to the OWASP Guide feel ... > I think that most on the list would agree that, overall, most web apps are ... > programmers when they haven't been offered a clue. ...
    (SecProg)
  • Some Noob Questions
    ... For instance, IIRC, the mozilla projects are written in C++ - although the addons are generally done in Java. ... Security is an issue - would like to write secure code, of course - would J2EE be suitable for these sort of apps? ... What I want, basically, is the best language for writing networking apps, with an eye toward security. ...
    (comp.lang.java.programmer)
  • Re: Access verses VB.net
    ... Woody, to be honest the argument should be the other way around. ... desktop apps. ... Access has very limited security. ... You won't get laughed at by all the other programmers ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Are bad developer libraries the problem with M$ software?
    ... I think that most on the list would agree that, overall, most web apps are ... Most of what I learn is gleaned from online tutorials, ... tutorial branded explicitly as a security text. ... programmers when they haven't been offered a clue. ...
    (SecProg)
  • Re: AD GPO - Run only allowed windows program
    ... Re you restricting all applications except one you define, ... restricting certain apps? ... Are you using software restriction policies, or just the user admin ...
    (microsoft.public.windows.server.active_directory)
Loading