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

From: Mike Bishop <mbishop@mtaonline.net>
Date: Sat Jan 31 2009 - 09:14:54 AKST

On Sat, Jan 31, 2009 at 03:36:27AM -0900, bryanm@acsalaska.net wrote:
> On Wed, January 28, 2009 8:24 am, Arthur Corliss wrote:
> > On Mon, 26 Jan 2009, Christopher Howard wrote:
> >
> >> I'm going to sound like a real noob here, but can you explain a bit more
> >> about the 'trap' and 'exit' part? Is this something I'm supposed to add to
> >> some init script or something? (I'll read the man pages if you'll point me
> >> to
> >> the right ones.)
> >
> > It's worth mentioning for the more paranoid out there: if you want to
> > control your user's environment (*especially* if you're using the rc file to
> > selectively enable a restricted shell) you should wrap all of /etc/profile's
> > code between two trap calls (one to disable the default signal handlers, and
> > one to re-enable them once you're finished with your initialization).
> >
> > Sounds like a good poll for everyone here: can everyone check your distro's
> > /etc/profile and report if they use trap as the first & last commands? It'd
> > be good to see what the relative paranoia of the various distros are.
> > Report back to the list!
>
> bryan@atlantis:~$ cat /etc/slackware-version
> Slackware 11.0.0
> bryan@atlantis:~$ grep trap /etc/profile
> bryan@atlantis:~$
>
> So you're saying that without a trap, a malicious user could interrupt
> the boot process and leave the system in an unintended and potentially
> vulnerable state?
>

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.

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

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.

Rgds,

--
Mike Bishop 
Willow, Alaska
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Jan 31 09:15:15 2009

This archive was generated by hypermail 2.1.8 : Sat Jan 31 2009 - 09:15:15 AKST