How can I secure an emacs-server? - security

I'd like to ensure that only I can connect to an emacs server that I initialised. I frequently use machines that other people could be SSH'd into, and I don't see what's to stop them opening emacsclient and running M-x kill-emacs which would screw me over.
I looked at the documentation for emacsserver and emacsclient but couldn't find what I was looking for.
Is there a way to do this?

That happens out of the box, of course! The Emacs server creates a socket that only you can access (permissions 600 or 700, in a directory with permissions 600 for good measure).

It looks like you can specify server-socket-file for the server and server-socket-dir for emacsclient. Simply place the socket in a directory where only you have access and you should be set.

Related

Best Practice to copy .vim and .vimrc to fresh server/terminal?

Quite often I get access to a new server somewhere and I really prefer my own custom configured vim to the standard one.
What are some best practices to get a new vim behave like the one on you machine?
Its not as easy as scp or sftp, usually I have to ssh into these server across multiple hops and sometimes public key authentification is disabled (so no direct ssh tunnel :( )
I already tried zipping it and uploading it somewhere, but thats usually not very straight forward.
Any help is appeciated!
Check out this tutorial for getting started with a dotfiles repository: https://medium.com/#webprolific/getting-started-with-dotfiles-43c3602fd789#.o97wkok0m
Keep in mind:
To “activate” the dotfiles, you can either copy or symlink them from
the home directory. Otherwise they’re just sitting there being
useless.

Location of emacs socket

I use emacs on a remote server. Since my sessions usually involve dozens of files and processes, I've been using the emacs server and connecting to it with the emacs client. That has the advantage that, if my ssh connection is interrupted for whatever reason (which happens very often since I'm in England and the server's in California), I simply connect to the emacs server again and continue working like nothing has happened.
However, some time ago, the administrators of the server have changed its configuration so that "unused" files get regularly purged from the /tmp directory, which is where the emacs socket is by default. Since the time stamp doesn't get updated after its initial creation, the purging process assumes that it's an unused file, which means that I can't connect to my server any more although it's running.
Does somebody know of a way to tell emacs to create the socket in a directory other than the default?
By the way, I also tried using a script that renews the socket's time stamp regularly, but it's still being deleted.
Thanks in advance.
It seems that server-socket-dir and server-auth-dir are the variables you are looking for, from the documentation C-hvserver-socket-dirRET
The directory in which to place the server socket. If local sockets
are not supported, this is nil.
C-hvserver-auth-dirRET
Directory for server authentication files. We only use this if
server-use-tcp' is non-nil. Otherwise we useserver-socket-dir'.
I finally found out myself, so sharing with everybody. Works with TCP and unix sockets.
ATMP="${HOME}/.tmp" # alternative tmp directory, choose any directory you like
mkdir $ATMP
env TMPDIR=${ATMP} emacs --daemon=$SOCKETNAME # start the daemon; SOCKETNAME can be anything
emacsclient -s ${ATMP}/$SOCKETNAME $OTHER_ARGS # start the client

Running codes from local machine on a remote linux server without loading them to the server

I have a bunch of codes written in MATLAB (file.m) that I would like to run them on a remote Debian server but because of security reasons I cannot copy the code on the server. Is there anyway I can run it on the server such that nobody can access the content of the codes? I was thinking may be by referencing them (e.g. using ssh or any other way) on local machine without loading the codes to the server I can do it but I don't know how. Thanks,
-J
What's wrong with putting the code on the server and chmoding it so others can't read it?
Some other possible suggestions depending on your requirements:
Pipe the code into a matlab process over ssh (as if you just typed it in to the interactive console). This is made much harder because matlab doesn't let you define functions at the command line.
Mount your desktop using sshfs and run it from matlab that way.
If you have the fancy version of the parallel computing stuff, you can start a Matlab worker process on the server and send code to it remotely, I think.
If you want to protect the sourcecode of your .m files, you can scramble them with pcode. That way matlab will be able to execute them, but the original .m file can't be reconstructed, although bad people can still steal your .p code and execute (but not modify) it.
I don't know what kind of security you have in mind. Executing code on a server without actually transmitting the code to it sounds impossible to me. If you don't trust the remote server, you'll have to execute in on your own machine and have the server send you the data that has to be processed.
Have a look at fuse.

Using directory traversal attack to execute commands

Is there a way to execute commands using directory traversal attacks?
For instance, I access a server's etc/passwd file like this
http://server.com/..%01/..%01/..%01//etc/passwd
Is there a way to run a command instead? Like...
http://server.com/..%01/..%01/..%01//ls
..... and get an output?
To be clear here, I've found the vuln in our company's server. I'm looking to raise the risk level (or bonus points for me) by proving that it may give an attacker complete access to the system
Chroot on Linux is easily breakable (unlike FreeBSD). Better solution is to switch on SELinux and run Apache in SELinux sandbox:
run_init /etc/init.d/httpd restart
Make sure you have mod_security installed and properly configured.
If you are able to view /etc/passwd as a result of the document root or access to Directory not correctly configured on the server, then the presence of this vulnerability does not automatically mean you can execute commands of your choice.
On the other hand if you are able view entries from /etc/passwd as a result of the web application using user input (filename) in calls such as popen, exec, system, shell_exec, or variants without adequate sanitization, then you may be able to execute arbitrary commands.
Unless the web server is utterly hideously programmed by someone with no idea what they're doing, trying to access ls using that (assuming it even works) would result in you seeing the contents of the ls binary, and nothing else.
Which is probably not very useful.
Yes it is possible (the first question) if the application is really really bad (in terms of security).
http://www.owasp.org/index.php/Top_10_2007-Malicious_File_Execution
Edit#2: I have edited out my comments as they were deemed sarcastic and blunt. Ok now as more information came from gAMBOOKa about this, Apache with Fedora - which you should have put into the question - I would suggest:
Post to Apache forum, highlighting you're running latest version of Apache and running on Fedora and submit the exploit to them.
Post to Fedora's forum, again, highlighting you're running the latest version of Apache and submit the exploit to them.
It should be noted, include the httpd.conf to both of the sites when posting to their forums.
To minimize access to passwd files, look into running Apache in a sandbox/chrooted environment where any other files such as passwd are not visible outside of the sandbox/chrooted environment...have you a spare box lying around to experiment with it or even better use VMWARE to simulate the identical environment you are using for the Apache/Fedora - try get it to be IDENTICAL environment, and make the httpd server run within VMWare, and remotely access the Virtual machine to check if the exploit is still visible. Then chroot/sandbox it and re-run the exploit again...
Document the step-by-step to reproduce it and include a recommendation until a fix is found, meanwhile if there is minimal impact to the webserver running in sandbox/chrooted environment - push them to do so...
Hope this helps,
Best regards,
Tom.
If you already can view etc/passwd then the server must be poorly configured...
if you really want to execute commands then you need to know the php script running in the server whether there is any system() command so that you can pass commands through the url..
eg: url?command=ls
try to view the .htaccess files....it may do the trick..

How to detect ftp connection

I'm using vsftpd and I want to write a shell script that will detect a connection to my server and send me an email with information who and when has logged in.
I don't know where to start. Can someone point me in the right direction.
Thanx
Read the log.
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/ref-guide/s1-ftp-vsftpd-conf.html
Enable the transfer log.
Read the file.
I'm not familiar with vsftpd, but you could have your shell script look at the output of netstat to see if you've got any connections on port 21 (the default ftp port).
The most reliable way is using log analysis. If you use a tool like OSSEC (free and open source), it can run any scripts or generate email alerts when logins, logouts, failed logins, etc happens.
link: http://www.ossec.net
Same applies for "fail2ban", though the purpose of this thing is something else (you guessed it).
J.

Resources