On Sun, Dec 16, 2012 at 7:10 AM, Paul de Weerd <we...@weirdnet.nl> 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 <we...@weirdnet.nl> 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
