> You say your audit trail is lost but then cite environment variables.
> Don't count environment variables as "audit". Ever.
With Apache password-protected directories tied to LDAP, this seems to be
working. Users must authenticate to get in to the system from a browser. We
then have AUTHENTICATE_UID or REMOTE_USER set. The user is passed on from
our scripts that perform operations. I'm not sure how that can be
circumvented, at least from the Web. It's SSH sessions that are trickier.
> Both 'su' and 'sudo' are logged.
Yes, of course, good point! So now I will try using 'sudo logger' to log
operations from our scripts and then we will have a complete audit trail in
the syslong (usually /var/log/messages).
Re: sudo and history, yes we are good there, but also good points.
Thanks Rick!
-Mike M
On Tue, Dec 20, 2016 at 11:38 AM, Rick Troth <r...@casita.net> wrote:
> Remember that some of the audit trail will be in your SYSLOG traffic.
>
>
> On 12/19/2016 09:12 AM, Michael MacIsaac wrote:
> > We cannot SSH as root in our organization which is good for preserving
> > audit trail because all users must use their own credentials.
>
> And that's a GOOD thing.
> Many customers either don't know this method (and why would they?) or
> don't like it (because it's an added step, annoying). Security isn't
> easy and isn't exactly fun.
>
>
> > I (but not all users) can then 'su to root', and my login user is
> preserved
> > in the environment variable SUDO_USER.
>
> The concept "su to root" takes a couple different forms.
> You can 'su' to root from (e.g.) mike if you know the password.
> (Password maint is a pain, but let's not open that can-o-worms just
> yet.) Clearly you want to use 'sudo' instead. Good!
>
>
> > However, then as root I can 'su to another user' and the audit trail
> seems
> > to be lost. Has anyone solved this issue?
>
> You say your audit trail is lost but then cite environment variables.
> Don't count environment variables as "audit". Ever.
>
> Both 'su' and 'sudo' are logged. That's your audit trail.
> Best practice w/r/t audit would be to fan-out SYSLOG traffic both
> locally and remotely.
> The local copy is per-host unique for per-host troubleshooting. The
> remote copy is untouchable by a malicious user or an intruder hitting a
> specific host.
>
> Put selected users, or (better) selected groups, into /etc/sudoers then
> let them 'sudo su -' as needed.
> Break that down: 'sudo' is the magical verb letting you "do stuff",
> controlled by /etc/sudoers.
> 'su' is the stuff you want to do (and the doing gets logged), and the
> lone dash "-" means "reprofile",
> establishing a fresh environment as if you logged on as that user (as if
> you logged in as root).
>
> Forcing the profile means everyone gets a consistent environment.
> It starts with /etc/profile and traditionally then sources
> $HOME/.profile, but BASH skews things.
> (Am omitting those details for the time being. Not everyone runs BASH,
> not even all Linux.)
>
> Most shells have command history. That's another audit trail.
> BASH has a nice feature that you can get timestamped history. Very nice!
>
> At one shop, some even wanted keystroke logging. Want that too?
>
> -- R; <><
>
>
>
>
> ----------------------------------------------------------------------
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www.marist.edu/htbin/wlvindex?LINUX-390
> ----------------------------------------------------------------------
> For more information on Linux on System z, visit
> http://wiki.linuxvm.org/
>
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
