[X4U] security

David Ledger dledger at ivdcs.demon.co.uk
Wed Feb 28 07:24:20 PST 2007


>From: James Hurley <jhurley0305 at sbcglobal.net>
>I have a Mac OS X security question.
>On BBC news this morning there was a warning about a new security
>threat. I think it was called Farming.
>
>It allow someone to alter your router so that your browser will
>direct you to a web site of their choice and not what you type into
>the browser address box.

I havn't heard of the threat myself yet. Such an attack would involve 
getting your system to use their DNS server to convert domain names 
to IP addresses rather than a real one. This has been known to be a 
possible problem since DNS was proposed. Your router will know the IP 
addresses of a couple or three DNS servers to use. It gets these 
either from the ISP they connect to at connection time or by you 
entering them manually.

Some routers _may_ allow their configuration to be changed from 
outside world. My Netgear router and the SMC I had before that will 
not accept an admin login from the WAN side, only the LAN (your) side 
unless it is specifically enabled. The Netgear will allow you to set 
up an IP address (or range of IP addresses) on the Internet side from 
which you can log in (to the router). Even if you leave the router 
admin password at the default you can't log in to it from the outside 
world without allowing it.

>What exactly does the Mac OS X security password protect you from? It
>is just logging into your computer on startup or is there something
>more?

In Unix, access to all things is controlled by permissions and all 
processes run 'as' someone. The user owning a process has to have 
access rights to an object, or use a proxy, to access the object. The 
initial system processes are owned by 'root' (user id zero -- uid=0). 
'The system' (kernel) can do anything, but only does things on 
request.

If, in 'Terminal' you use the single word command 'df' (without 
quotes) you will see that '/' - the top level of your disc - is on 
device /dev/disk1s10 (or similar). If you then do:
ls -l /dev/disk1s10
it will show you that your disc is owned by root, it is readable and 
writable by root, and that it is readable by anyone in the group 
'operator'. This means that neither you nor any other user can read 
or write your disc. When you log in you authenticate yourself as 
'James' to the root process that is driving the login screen. The 
system knows that any process running as user 'James' is a descendant 
of an authenticated login. There is no other way to create a process 
running as 'James' (except for methods requiring their own 
authentication by root at the time or in the past). When your login 
startup sequence starts the Finder application for you, that sequence 
needs to read the Finder program from disc. The library routines that 
do this use 'system calls' to the kernel as a proxy to perform the 
disc read and return the data found. The proxy only works if 
permissions allow it. When the Finder runs it uses the same methods 
to read the disc so as to know what to display. The Finder runs as 
'James', so it can only display things that 'James' is allowed to 
see. That's why if you have another user on your machine you can't 
see their files unless they open up the permissions on them. The same 
applies to all other applications.

A disc is visible in two ways; as a stream of bytes from beginning to 
end and as a hierarchical filesystem. Only root (normally as the 
kernel) ever accesses it the first way, but it needs access the first 
way in order to interpret the second for us. This means that without 
permission to write to the 'stream of bytes' nothing can be written 
to disc. The kernel uses the permissions on the files as seen through 
the second, interpreted, view to decide whether it will accept or 
reject a request from any user other than root.


If 'James' is an admin user, it means 'James' is in a list of users 
who may initiate a process to run 'as' another user, most usefully 
root, by re-authenticating themselves.

Sorry if this is a bit rambling. It must be at least a day of a Unix 
course on top of a few days of background to cover this sort of thing.

David


-- 
David Ledger - Freelance Unix Sysadmin in the UK.
Chair of HPUX SysAdmin SIG of hpUG technical user group (www.hpug.org.uk)
david.ledger at ivdcs.co.uk
www.ivdcs.co.uk


More information about the X4U mailing list