Re: securety related question...

On Sat, 5 Oct 2002, R. Bosch wrote:

> Yes, my spelling is maybe wrong :-}
>
> But realy, I have a question.
>
> I had browsed through an report about securety holes in Linux (windows
> was there too), and it sayd that one of the things one can do is running
> services (daemons) as a restricted user. I know I read it somewhere, but
> where... I don't know. Therefor the following question:
>
> How does a *realy* restricted user look like and wat are the best way to
> make one?

They pretty much look like every other non-root user on the system,
although usually they'll all be assigned numeric uids in a certain range
separate from actual users for the sake of neatness (and being able to set
lower limits to some things like suexec).  Slackware, along with a lot of
other Linux distros, puts all the daemon/role accounts between 99 and 1.

About the only significant thing other than that which I can think of is
that their default shells will usually be unset or /bin/false, and the
home directory will usually be set to somewhere that exists, but is only
significant in the context of that daemon/role... like the games role
account will typically have it's home directory set to /usr/games (where
all the games binaries are installed).

Big sidebar:  I should probably explain the use of the word "role" because
I know it's going to throw some people.  Generic daemonized user accounts
are called "role" accounts because they are meant not to be a particular
user (like, say Yul Brenner) but simply to temporarily play the _role_ of
one (like, the King of Siam).  The root account is _also_ a role account,
and the one thing you can say about role accounts is that since they don't
intend a particular user, no one should be logging in directly as a role
account (a tenet of proper useage accounting).  If they need to use that
role, they should login as their normal account and then use su to change
user to it, although sudo would be even better.  (The notable exception to
this is that root should be allowed to login directly from console, or you
can be really screwed).

> Thanks in advance!!
>
> btw:
> It's *AMAZING* howmuch files are suid/guid!! 8-|
> Was lookig at qt and stuff :-} the smaller programs/libs under /usr
> were not that numerous though.

Suid/guid apps are dangerous because the override the normal security
model.  Once you've gotten a better grasp of how things work, I highly
recommend stripping the suid bits off of everything you can.  One of the
very first things you can expect a cracker to do once they've gained an
initial account on your machine will be to hunt for all the suid apps and
find one with a weakness they can exploit to gain more privledges.

One good example of a program that under typical useage doesn't need to be
suid is `mount`.  Unless you make a habit of letting lusers mount
filesystems (meaning you're only ever using mount as root...) there's
absolutely no need for the suid bit.  Xterm, on the other hand, can use
it's suid it to write to wtmp/utmp to properly maintain the login counts,
but doesn't strictly need to do so on a single-user workstation.

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe blfs-support' in the subject header of the message