Andres Perera <andre...@zoho.com> wrote:
>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
I still want to know the reason for all this. If it's for security, it sure
feels ass-backwards and questionable at best.
