I'm working on an application controller for a program that is spitting text directly to /dev/tty.
This is a production application controller that must be able to catch all text going to the terminal. Generally, this isn't a problem. We simply redirect stdout and stderr. This particular application is making direct calls to echo and redirecting the result to /dev/tty (echo "some text" > /dev/tty). Redirects via my application controller are failing to catch the text.
I do have the source for this application, but am not in a position to modify it, nor is it being maintained anymore. Any ideas on how to catch and/or throw away the output?
screen -D -m yourEvilProgram
should work. Much time passed sinced I used it, but if you need to read some of its output it could even be possible that you could utilize some sockets to read it.
[Added: two links, Rackaid and Pixelbeat, and the home page at GNU]
The classic solution to controlling an application like this is Expect, which sets up pseudo-terminals, does logging, and drives the controlled application from a script. It comes with lots of sample scripts so you can probably just adapt one to fit your needs.
This is what I did in python
import pty, os
pid, fd = pty.fork()
if pid == 0: # In the child process execute another command
os.execv('./my-progr', [''])
print "Execv never returns :-)"
else:
while True:
try:
print os.read(fd,65536),
except OSError:
break
I can't quite determine whether the screen program mentioned by #flolo will do what you need or not. It may, but I'm not sure whether there is a logging facility built in, which appears to be what you need.
There probably is a program out there already to do what you need. I'd nominate sudosh as a possibility.
If you end up needing to write your own, you'll probably need to use a pseudo-tty (pty) and have your application controller sit in between the user's real terminal connection and the the pty device, where it can log whatever you need it to log. That's not trivial. You can find information about this in Rochkind's "Advanced UNIX Programming, 2nd Edn" book, and no doubt other similar books (Stevens' "Advanced Programming in the UNIX Environment" book is a likely candidate, but I don't have a copy to verify that).
Related
Sorry for my noob question as I am very new to linux. Please consider the below linux command :
/opt/mongodb-mms-automation/bin/mongodb-mms-automation-agent
-f /etc/mongodb-mms/automation-agent.config
-pidfilepath /var/run/mongodb-mms-automation/mongodb-mms-automation-agent.pid
>> /var/log/mongodb-mms-automation/automation-agent-fatal.log 2>&1
According to my understanding >> redirects standard output to file and 2>&1 means that standard error will be redirected to the same location as standard output. So in the above case I expect the standard output and standard error both to be redirected to /var/log/mongodb-mms-automation/automation-agent-fatal.log.
But obviously this is not the case. I can see that all info / error messages are being redirected to a file /var/log/mongodb-mms-automation/automation-agent.log. Can someone please explain what error I am making in reading this command?
Regards,
Meena
Standard output and standard error are just default destinations; the program could be doing a number of things which will sabotage any attempts to save the logs by redirecting to a file:
It writes straight to the terminal output, such as /dev/pts/0.
It detects whether standard output/error are connected to a file or a terminal, and changes behaviour accordingly.
Anything else the application developer considered to be the most useful behaviour.
In other words, it's application specific. You're probably better off finding the logfile configuration setting and changing that if you really need to. Usually I find it's easier and safer to leave the defaults (since they may be handy for example for security reasons such as sandboxing) and instead pointing to the default location in whatever software is trying to process that file in some way.
Not sure if this is the right place to ask.
Say I write a shell that takes stdin input, filters this input so let's say only certain commands like
ls (list contents of binary directory and subdirectory)
update (git clone)
build (go build)
test (go test)
start (systemctl start this.service only)
stop (systemctl stop this.service only)
running (is the binary being executed and with how many GOMAXPROCS?)
usage (memory, cpu usage)
gensvc (generate .service file)
exit (leave shell/logout)
work, you guessed it, I'm trying to give a user only very limited maintenance access over ssh.
Say I'm careful with \0 (I'd write it in Go anyway using bufio.Scanner)
Is there any way to stop the running shell and execute /bin/sh or similar or any way to get around this shell?
The idea is a user should push their stuff via git to a bare repo, this repo is cloned to the filesystem to a certain directory, then go build is called and the binary is ran with a systemd .service file that is generated previously.
Thinking logically, if the user is only able to write certain strings that are accepted, no there is no way. But maybe you know of one, some ctrl+z witchcraft ;) or whatever.
The only attack surface is the input string or rather bytes. Of course the user could git push a program that builds its own shell or runs certain commands, but that's out of scope (I would remove capabilities with systemd and restrict device access and forbid anything but the connection to the database server, private tmp and all, namespace and subnamespace it TODO)
The only problem I see is git pushing but I'm sure I could work around that in a git only mode argv and adding it to ~/.ssh/authorized_keys. something like lish gitmode and execute stdin commands if they start with git or something like it.
Example:
https://gist.github.com/dalu/ce2ef43a2ef5c390a819
If you're only allowed certain commands, your "shell" will read the command, parse it and then execute it then you should be fine, unless I misunderstood it.
Go "memory" can't be executed, not without you doing some nasty hacks with assembly anyway, so you don't have to worry about shell injection.
Something along these lines should be safe:
func getAction() (name string, args []string) {
// read stdin to get the command of the user
}
func doAction() {
for {
action, args := getAction()
switch action {
case "update": //let's assume the full command is: update https://repo/path.git
if len(args) != 1 {
//error
}
out, err := exec.Command("/usr/bin/git", "clone", "--recursive", args[0]).CombinedOutput()
// do stuff with out and err
}
}
}
If you are implementing the shell yourself and directly executing the commands via exec() or implementing them internally, then it is certainly possible to produce a secure restricted shell. If you are just superficially checking a command line before passing it on to a real shell then there will probably be edge cases you might not expect.
With that said, I'd be a bit concerned about the test command you've listed. Is it intended to run the test suite of a Go package the user uploads? If so, I wouldn't even try to exploit the restricted shell if I was an attacker: I'd simply upload a package with tests that perform the actions I want. The same could be said for build/start.
Have it reviewed by a pentesting team.
People can be very creative when breaking out a sandbox of any type. Only if you never accept the user's input you can consider yourself rather safe on premises (but here any command is an input) - paper security assumptions are considered a weak to assess the software. They are similar to 'no-bug' assumptions for an algorithm on paper: as soon as you implement it, 99% of time a bug raises
I need to write some commands in command window using C++ code. How to implement it. I have tried with CreateProcess function but it seems some wrong in it. Please refer my code below:
STARTUPINFO sInfo = {0};
sInfo.cb = sizeof(sInfo);
PROCESS_INFORMATION pInfo = {0};
CreateProcess("C:\\WINDOWS\\System32\\cmd.exe",""0,0,TRUE,
NORMAL_PRIORITY_CLASS,0,0,&sInfo,&pInfo);
It opens the command window successfully. My doubt is how to write command through code in it.
First thing, you need not to create a separate process just to write text output to a console window.
It depends what and how you want to write. You may create a console application itself, or create a console itself, and attach to the current process. You need to use pipes for the same and redirect the output to given pipe (i.e. send data to pipe). At the other end of pipe, you will read the text/buffer and render the output wherever you would like to.
These articles may help:
Console Output from GUI program
Real time Console Output redirection
Since your question is not very clear, this is just assumption.
Or, are you playing with the console itself - like changing colors, dimension etc?
I've written a fan control script in Lua, and I'm running Linux. The fan control needs to write to /sys/ so I need to be super user.
I want to inform the user if they are NOT super user. What's the best way to go about doing this?
The only certain test is to check whether the POSIX geteuid() call returns zero.
For this you may have to use a Lua library like luaposix.
Or you can shell out and run id -u to see if it outputs 0.
Since it's Linux, you can try this, which is stock Lua and does not need additional libraries:
function running_as_root()
local f=io.open"/root"
if f==nil then return false else io.close(f) return true end
end
But why not just try to write to /sys/ and report failure if that happens?
best thing to do is just report failure: you could have a system where other users than root have access to sysfs.
fd = assert(io.open("/sys/...."))
I building my sites on the localhost (runs wamp on windows), and when I upload it to my server, I always get
"Cannot modify header information - headers already sent"
I understand that there shouldn't be any blank lines and everyhing, and usually this works out. but now I need to redirect someone after the header has been sent, how can I make my server act like my localhost ?
i'm using cpanel and WHM:
cPanel 11.25.0-R42399 - WHM 11.25.0 - X 3.9
CENTOS 5.4 x86_64 virtuozzo on vps
I will appreciate any help
In short, you need to prevent PHP from outputting anything to the browser before you get to the point where you want to use the header() function.
This should be done by careful programming practices, of which your 'no blank lines' is one, or by storing PHP's output in an output buffer, and only outputting when you're ready for it.
See the ob_start() and ob_flush() methods. You use ob_start() at the start of your application. This disables output and stores it into a buffer. When you're ready to start outputting, use ob_flush() and PHP will send the buffer's contents to the browser, including the headers that are set till that point. If you don't call ob_flush() then the buffer is output (flushed) at the end of the script.
The reason why it works on your WAMP development environment is most likely that output buffering is already enable by default in the php.ini. Quite often these all-in-one packages enable a default buffer for the first 4k bytes or so. However, it is generally better to explicitly start and flush the buffer in your code, since that forces better coding practices.
Well,
I guess by more thinking and better programing you can manage to keep all redirects before any HTML is written.
This problem solved by the old rules...
#user31279: The quickest and dirtiest way I know of is to use # to suppress the warning, so e.g.
#header('Location: some-other-page.php');