[aklug] Re: profiles in paranoia (was: terminal types and curses programming)

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Sun Feb 01 2009 - 22:19:50 AKST

On Sat, 31 Jan 2009, Mike Bishop wrote:

> I am not sure I follow this. None of my systems have a trap in
> /etc/profile (or that new stuff in /etc/profile.d) (Suse 10.2, Ubuntu
> Heron, Arch). I am fairly certain my SVR3/SVR4 systems don't either.

It's been the standard on both AIX and Solaris for quite some time.

> You have to login to a shell to fire profile, so interrupting it would
> give you, em, a shell, right?

If you read the man pages, shells use a number of hints to determine how it
was invoked, including whether it's a login shell, interactive, etc. You
may find situations where this isn't a problem. It also depends on the
shell. /etc/profile, for instance, is used by at least three different
shells (POSIX, Korn, and Bash).

> If a custom script is fired by init, then yes, traps are required.
> If a login process fires it's own custom script (eg: a menu display) then
> that script/program needs to protect against signals that might dump it
> back to the initiating shell. But this is not the province of /etc/profile
> I think.

It may not be justified everywhere, but one example is IBM on their HMCs,
they use a trap function to prevent programs from dumping into a
restricted shell if something goes wrong with the program, including a
SIGSEGV.

As far as I'm concerned, better safe than sorry. I do enough in my
/etc/profile to want to make sure that whoever gets a shell gets stuck with
the parameters I set for them. Whether that's strict ulimits or a
restricted shell.

Security is best done in layers, rather than trusting a single layer to
never fail.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sun Feb 1 22:20:01 2009

This archive was generated by hypermail 2.1.8 : Sun Feb 01 2009 - 22:20:01 AKST