Re: KSH command logged to syslog
On 2012/12/17 10:42, Jiri B wrote: > On Mon, Dec 17, 2012 at 02:03:03PM +, Stuart Henderson wrote: > > Wouldn't it be better to use an ssh forced command, which then looks > > up the users desired shell (or other command called directly from ssh) > > and wraps it in a logger? > > ForceCommand runs under destination user permissions so if you > won't make your ForceCommand app setuid the user could delete > the log file. you probably don't want it on the same machine anyway..
Re: KSH command logged to syslog
On Mon, Dec 17, 2012 at 02:03:03PM +, Stuart Henderson wrote: > Wouldn't it be better to use an ssh forced command, which then looks > up the users desired shell (or other command called directly from ssh) > and wraps it in a logger? ForceCommand runs under destination user permissions so if you won't make your ForceCommand app setuid the user could delete the log file. jirib
Re: KSH command logged to syslog
On 2012-12-16, David Coppa wrote: >> .profile can be interrupted with ctrl+c. > Because it is under controle or the user and he/she can disable such funcionality. > > the safer way imho is patching ksh Wouldn't it be better to use an ssh forced command, which then looks up the users desired shell (or other command called directly from ssh) and wraps it in a logger?
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 8:07 AM, Alexander Hall wrote: > > I still want to know the reason for all this. If it's for security, it sure > feels ass-backwards and questionable at best. > it's useful for honeypot scenarios, with all proposed solutions so far being influenced by either lazyness or desire to maintain a modicum of portability with other unices. it's not useful for accounting on regular accounts the best balance between effort and results i believe is to extend the ktrace hooks to switch on curproc uid and put a cap on the logfile. what apis linux honeypot loggers use? do they sufficiently resemble ktrace? it's the only facility i see in openbsd besides systrace that fits the bill of already logging all sorts of io (not just pty)
Re: KSH command logged to syslog
Andres Perera wrote:
>On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd
>wrote:
>> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
>> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd
>wrote:
>> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
>> | > | > .profile can be interrupted with ctrl+c.
>> | > |
>> | > | >>> Because it is under controle or the user and he/she can
>disable
>> | > | >>> such funcionality.
>> | > |
>> | > | the safer way imho is patching ksh
>> | >
>> | > After that, expect all your users to suddenly switch to one of
>the
>> | > other shells available on your system...
>> |
>> | because once you patch ksh, you can't ever again edit /etc/shells
>>
>> switching shells:
>>
>> Step 1: login
>> Step 2: exec (zsh|csh|perl|tcsh|bash|...)
>> Step 3: ...
>> Step 4: profit
>>
>> Sure, you can edit /etc/shells and prevent users from changing their
>> login shells with chsh, but what does that buy you if they can still
>> switch shells ?
>
>no, you are patching ksh for a reason. you add logging capabilities
>and remove the ability to exec. is it a featureful shell, not really
>
>then again, is the resulting patched ksh significantly different than
>some free shell hosts provide? nope, they both tend to be as useless.
>if i recall correctly, sdf had such a stunted shell
>
>>
>> And besides .. the users that want to run another shell in the first
>> place are screwed ? You'd have to patch 'em all .. good luck with
>> maintaining that.
>
>the alternative login shell below is even more restrictive; only
>/bin/sh. ksh in posix mode isn't fun at all. this is the price you pay
>for security in 2013
>
>>
>>
>> Then, you could log all stdin/stdout to some file (even more data!
>> fun!). If you really want to circumvent this logging, you could
>> create a covert channel that will show data on the client side but
>has
>> no visible input/output in the server side.
>
>well, it's logging terminal input. does what it says in the can
>
>the can doesn't say "logs arbitrary socket io"
>
>>
>>
>> I'm still curious why any of this is a good idea.
>>
>> | > Or a nice syslog DoS, where people run while :; do echo ${RANDOM}
>>
>> | > /dev/null; done (or a less intentional version of the same) to
>flood
>> | > your logs with crap.
>> |
>> | and fsize becomes immutable as well apparently (syslog be
>forgotten)
>>
>> Not sure I understand your point here. What about fsize ? You want
>> to limit the size of the logfile ? So that all you have to do is
>fill
>> it up to the max size and then you can do whatever you want without
>> having your actions logged ?
>
>now that i think about it, it wouldn't work with O_APPEND ~O_CREAT on
>the logfile below
>
>i'm not sure "whatever you want without having your actions logged" is
>accurate in the original case, since ksh aborts by default on SIGXFSZ
>and modifications to builtins can make it uncatchable
>
>in any case, presumably the quota system is up to spec and the writing
>is done entirely by the user
I still want to know the reason for all this. If it's for security, it sure
feels ass-backwards and questionable at best.
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
> | On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> | > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > | > .profile can be interrupted with ctrl+c.
> | > |
> | > | >>> Because it is under controle or the user and he/she can disable
> | > | >>> such funcionality.
> | > |
> | > | the safer way imho is patching ksh
> | >
> | > After that, expect all your users to suddenly switch to one of the
> | > other shells available on your system...
> |
> | because once you patch ksh, you can't ever again edit /etc/shells
>
> switching shells:
>
> Step 1: login
> Step 2: exec (zsh|csh|perl|tcsh|bash|...)
> Step 3: ...
> Step 4: profit
>
> Sure, you can edit /etc/shells and prevent users from changing their
> login shells with chsh, but what does that buy you if they can still
> switch shells ?
no, you are patching ksh for a reason. you add logging capabilities
and remove the ability to exec. is it a featureful shell, not really
then again, is the resulting patched ksh significantly different than
some free shell hosts provide? nope, they both tend to be as useless.
if i recall correctly, sdf had such a stunted shell
>
> And besides .. the users that want to run another shell in the first
> place are screwed ? You'd have to patch 'em all .. good luck with
> maintaining that.
the alternative login shell below is even more restrictive; only
/bin/sh. ksh in posix mode isn't fun at all. this is the price you pay
for security in 2013
>
>
> Then, you could log all stdin/stdout to some file (even more data!
> fun!). If you really want to circumvent this logging, you could
> create a covert channel that will show data on the client side but has
> no visible input/output in the server side.
well, it's logging terminal input. does what it says in the can
the can doesn't say "logs arbitrary socket io"
>
>
> I'm still curious why any of this is a good idea.
>
> | > Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> | > /dev/null; done (or a less intentional version of the same) to flood
> | > your logs with crap.
> |
> | and fsize becomes immutable as well apparently (syslog be forgotten)
>
> Not sure I understand your point here. What about fsize ? You want
> to limit the size of the logfile ? So that all you have to do is fill
> it up to the max size and then you can do whatever you want without
> having your actions logged ?
now that i think about it, it wouldn't work with O_APPEND ~O_CREAT on
the logfile below
i'm not sure "whatever you want without having your actions logged" is
accurate in the original case, since ksh aborts by default on SIGXFSZ
and modifications to builtins can make it uncatchable
in any case, presumably the quota system is up to spec and the writing
is done entirely by the user
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 06:38:08AM -0430, Andres Perera wrote:
| On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
| > On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > | > .profile can be interrupted with ctrl+c.
| > |
| > | >>> Because it is under controle or the user and he/she can disable
| > | >>> such funcionality.
| > |
| > | the safer way imho is patching ksh
| >
| > After that, expect all your users to suddenly switch to one of the
| > other shells available on your system...
|
| because once you patch ksh, you can't ever again edit /etc/shells
switching shells:
Step 1: login
Step 2: exec (zsh|csh|perl|tcsh|bash|...)
Step 3: ...
Step 4: profit
Sure, you can edit /etc/shells and prevent users from changing their
login shells with chsh, but what does that buy you if they can still
switch shells ?
And besides .. the users that want to run another shell in the first
place are screwed ? You'd have to patch 'em all .. good luck with
maintaining that.
Then, you could log all stdin/stdout to some file (even more data!
fun!). If you really want to circumvent this logging, you could
create a covert channel that will show data on the client side but has
no visible input/output in the server side.
I'm still curious why any of this is a good idea.
| > Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
| > /dev/null; done (or a less intentional version of the same) to flood
| > your logs with crap.
|
| and fsize becomes immutable as well apparently (syslog be forgotten)
Not sure I understand your point here. What about fsize ? You want
to limit the size of the logfile ? So that all you have to do is fill
it up to the max size and then you can do whatever you want without
having your actions logged ?
| here is something that doesn't require patching
|
| create log files and change to system append-only with chflags. dir
| should be, e.g., chown root:wheel, chmod go=rx
|
| #include
| #include
| #include
| #define sp "/usr/bin/script"
| #define sf "/var/db/ghetto_act/%ju"
|
| main()
| {
| char *so;
| if (asprintf(&so, sf, getuid()) == -1) return 1/0;
| execl(sp, sp, "-a", so, NULL);
| return 1/0;
| }
|
| >
| > Why is this a good idea, exactly ?
| >
| > Paul 'WEiRD' de Weerd
| >
| > --
| >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
|
| o look, a brainfuck program. this is so quirky and tech oriented i
| feel identified with you
Great, glad you like it.
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: KSH command logged to syslog
btw, this program should be the only entry in /etc/shells so only root
is allowed privacy
On Sun, Dec 16, 2012 at 6:38 AM, Andres Perera wrote:
>
> #include
> #include
> #include
> #define sp "/usr/bin/script"
> #define sf "/var/db/ghetto_act/%ju"
>
> main()
> {
> char *so;
> if (asprintf(&so, sf, getuid()) == -1) return 1/0;
> execl(sp, sp, "-a", so, NULL);
> return 1/0;
> }
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 5:47 AM, Paul de Weerd wrote:
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is patching ksh
>
> After that, expect all your users to suddenly switch to one of the
> other shells available on your system...
because once you patch ksh, you can't ever again edit /etc/shells
>
> Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> /dev/null; done (or a less intentional version of the same) to flood
> your logs with crap.
and fsize becomes immutable as well apparently (syslog be forgotten)
here is something that doesn't require patching
create log files and change to system append-only with chflags. dir
should be, e.g., chown root:wheel, chmod go=rx
#include
#include
#include
#define sp "/usr/bin/script"
#define sf "/var/db/ghetto_act/%ju"
main()
{
char *so;
if (asprintf(&so, sf, getuid()) == -1) return 1/0;
execl(sp, sp, "-a", so, NULL);
return 1/0;
}
>
> Why is this a good idea, exactly ?
>
> Paul 'WEiRD' de Weerd
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
o look, a brainfuck program. this is so quirky and tech oriented i
feel identified with you
> http://www.weirdnet.nl/
Re: KSH command logged to syslog
My guess, compliance to some standard
Den 16 dec 2012 11:17 skrev "Paul de Weerd" :
> On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
> | > .profile can be interrupted with ctrl+c.
> |
> | >>> Because it is under controle or the user and he/she can disable
> | >>> such funcionality.
> |
> | the safer way imho is patching ksh
>
> After that, expect all your users to suddenly switch to one of the
> other shells available on your system...
>
> Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
> /dev/null; done (or a less intentional version of the same) to flood
> your logs with crap.
>
> Why is this a good idea, exactly ?
>
> Paul 'WEiRD' de Weerd
>
> --
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/
Re: KSH command logged to syslog
On Sun, Dec 16, 2012 at 11:02:31AM +0100, David Coppa wrote:
| > .profile can be interrupted with ctrl+c.
|
| >>> Because it is under controle or the user and he/she can disable
| >>> such funcionality.
|
| the safer way imho is patching ksh
After that, expect all your users to suddenly switch to one of the
other shells available on your system...
Or a nice syslog DoS, where people run while :; do echo ${RANDOM} >
/dev/null; done (or a less intentional version of the same) to flood
your logs with crap.
Why is this a good idea, exactly ?
Paul 'WEiRD' de Weerd
--
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
http://www.weirdnet.nl/
Re: KSH command logged to syslog
> .profile can be interrupted with ctrl+c. >>> Because it is under controle or the user and he/she can disable >>> such funcionality. the safer way imho is patching ksh
Re: KSH command logged to syslog
Maximo Pech wrote: >I have found another possible solution, you can use script(1), calling >it >from the .profile of the user, with a line like this at the end of such >file: > >exec script > >Then you change the permissions of the .profile so that the user cannot >change it. You could also set the output file for script(1) to a file >located on a directory with the sticky(8) bit activated so the user >cannot >delete the log file of the session but is able to write to it. You would need to alter the directory rights too. I don't think sticky means what you think it means. .profile can be interrupted with ctrl+c. /Alexander > >2012/12/15 Jiri B > >> On Fri, Dec 14, 2012 at 10:11:20PM -0600, Maximo Pech wrote: >> > Why not use something like gnu screen or tmux (if it offers the log >> session >> > funcionality)? >> >> Because it is under controle or the user and he/she can disable >> such funcionality. >> >> jirib
Re: KSH command logged to syslog
I have found another possible solution, you can use script(1), calling it from the .profile of the user, with a line like this at the end of such file: exec script Then you change the permissions of the .profile so that the user cannot change it. You could also set the output file for script(1) to a file located on a directory with the sticky(8) bit activated so the user cannot delete the log file of the session but is able to write to it. 2012/12/15 Jiri B > On Fri, Dec 14, 2012 at 10:11:20PM -0600, Maximo Pech wrote: > > Why not use something like gnu screen or tmux (if it offers the log > session > > funcionality)? > > Because it is under controle or the user and he/she can disable > such funcionality. > > jirib
Re: KSH command logged to syslog
And why not tweak it to disable the ability to disable the log functionality? 2012/12/15 Jiri B > On Fri, Dec 14, 2012 at 10:11:20PM -0600, Maximo Pech wrote: > > Why not use something like gnu screen or tmux (if it offers the log > session > > funcionality)? > > Because it is under controle or the user and he/she can disable > such funcionality. > > jirib
Re: KSH command logged to syslog
On Fri, Dec 14, 2012 at 01:50:49PM +0100, Dustin Fechner wrote: > On 12/14/2012 12:20 PM, Lorenzo Crapovich wrote: > > Hi folks.I'm looking for a clean solution, to log through syslog > > every single shell command that a user make. > > Why not log to /var/account/acct? > See accton(8) and sa(8). Logs just commands, not arguments and doesn't log whole session. jirib
Re: KSH command logged to syslog
On 12/14/2012 12:20 PM, Lorenzo Crapovich wrote: > Hi folks.I'm looking for a clean solution, to log through syslog > every single shell command that a user make. Why not log to /var/account/acct? See accton(8) and sa(8).
Re: KSH command logged to syslog
On Fri, Dec 14, 2012 at 11:20:09AM +, Lorenzo Crapovich wrote: > Hi folks.I'm looking for a clean solution, to log through syslog every single > shell command that a user make.I've found many wrapper scripts, or stuff like > 'sudosh, snoopy logger', but actually, it sounds pretty dirty imho. > What solution guys could you suggest me ? > Greetings. > Lorenzo Use console server which would do ssh and log everything, in ports 'conserver'. jirib
