>> the same exploits. Think of a binary generated elsewhere (where
> "gcc" is available) and put into your environment.
That's pretty bad news :(
>
> I am convinced that 100 % security is impossible - and correspondingly
> would use a pragmatic approach: I would rely on OS level
> constraints (us
"Lakshmipathi.G" writes:
> Could you please share more info about creating raw binary executable
> and its potential
> problem.
In an earlier message, you reported to have banned "gcc" to
avoid "C" level exploits. A "raw binary executable" would allow
the same exploits. Think of a binary generate
> If you permit file I/O and anything that can spawn a process, it is
> possible to create a raw binary executable and trigger its execution.
> --
Yes,we permit file i/o with quota limits and spawning a process is
allowed upto a limit.
If I'm not wrong, we will be safe if user invokes sub
Hi -
Thanks for the response. Yes, we used OS features to
restrict the system user accounts.
We don't allow gcc - this helped us to avoid kernel exploits via C code like :
https://www.centos.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=42827&forum=59
https://bugzilla.redhat.com/show_bu
"Lakshmipathi.G" writes:
> We have a server running a web-based terminal emulator (based on shellinabox
> for screen-casting check www.webminal.org) that allows users to learn
> simple bash commands. This Linux environment secured by things like quota,
> selinux,ulimit etc
>
> Now some users ar
Hi -
We have a server running a web-based terminal emulator (based on shellinabox
for screen-casting check www.webminal.org) that allows users to learn
simple bash commands. This Linux environment secured by things like quota,
selinux,ulimit etc
Now some users are requesting python access. How
