Re: Enabling telnet, ftp, pop3 for root...

matt_left_coast wrote:

They can get ANY PRIVILEGE THEY WANT, they can stop any logging you have
going. In the example I gave above, before they open the shell they have a
command that shuts off logging, then opens the shell and turns back on
logging, The one shell is NOT logged. Since the commands were run in a
script, they are not logged. Your method fails. Never mind that they can
run ALL the commands they want from the script, and that does not get
logged.


The most they could do is kill the log daemon. However, since the logs were not retained on the same machines as the machines generating the log messages, that would leave an obvious hole in the logs -- which would prompt an investigation because there would be missing data.

Since nobody had root access to the machine that held the logs, there wasn't a way that somebody could abuse privilege by hiding what they were doing, without making it quite apparent that they were trying to hide their actions. "SUDO to root by user X" ... no further log data? That's quite suspect.

In case you're curious: Somebody did try this. They were fired.

With today's legal requirements on keeping data, people are trying to
make sure that everything is logged, not just what they know for sure
must be. It covers their rear ends.

They just run the commans from an init file, The commands run there are not
logged.


Root access doesn't create every potential problem. You are making the rather broad assumption that the system is entirely self-contained, that there are no checks and balances, and that logins are privileged or not across the entire network. This is just not true. Those are all hurdles that are unnecessary when implementing security. Do they make life a little bit harder on the admins? Sure they do. But they also make life a lot easier for those that are trying to just hold things together, and for compliance.

You can't modify an init that doesn't exist on the filesystem, you know.

In addition, if you're using a BSD system in multiuser mode, you'll find that if you make files immutable, you limit the ways in which they can be edited. You have to bring the system down to single-user mode to strip the file's immutable bit, and then go from there. I've read that Linux has the same functionality, though I've not attempted to use it yet. However, our systems at work had this enabled for a fair lot of the system, so the admins had a time window in which they could patch software and alter configurations and the like during a week, and all of that had to be approved by management.

When you have a system of checks and balances, it is hard to overthrow the entire empire. It may be possible, but, it is more probable that you'll be caught unless the other administrators are dumbasses and don't know what to look for.

If you have to delete 2,000 users, there's no reason you can't use sudo.

Except if you allow them to do the simplest admin task, edit and
run /etc/init.d files, you give them full root access. They can do anything
they want.


If /etc/init.d doesn't exist, or /etc/rc.d doesn't exist, on the local filesystem, then you do not have privilege to edit it. Plain and simple. If you pull / from a read-only resource, then you aren't able to change it, logically. Thus, you can't inject something like that into the boot-time system logic. What gives you the right to make such broad assumptions? Have you truly never given these questions real thought, or are you just spewing from an ignorant base of knowledge?

That's what shell loops and constructs are for. UNIX has enough
tools to make anything possible -- so, in an environment where security
is worth more then uptime / reliability, then security gets it. In an
environment where they are competing goals, then best effort at minimum
must be made at both. And if uptime is the absolute requirement, then
you're going to lose a little bit in terms of security. But, that
should not stop you from using as many tools as you have possible to
make it done right.

Good luck on you job search.


One could say the same to you. It would appear you haven't even contemplated situations in which high security is required. As the amount of required security increases, so does the overhead that is required to maintain it, however, if the data is worth it, then, the data is worth it. Security is paramount.

- Mike
.

Relevant Pages

  • Re: Security of using sudo rather than su?
    ... Security isn't just about cracked passwords. ... in as root. ... Then there is the point that access to specific commands needing root ... That is, they have root access, but only ...
    (Ubuntu)
  • Re: HELP! - Ive screwed up and now cant access root
    ... There is a bit of a security hole ... get to a root shell fairly easy. ... >> I was walking through the guide, and started working on root access. ... I was just doing the commands that the ...
    (comp.os.linux.security)
  • Re: More on SCADA comm security
    ... RF security has not been an issue ... The hardware designer will include some tamper detection, ... routine network commands resulting in RF sessions ... encryption, not something homespun. ...
    (comp.arch.embedded)
  • Re: Sending commands to a remote program.
    ... At no point in this question did you suggest that you would be encrypting the commands. ... typically only means the routers and firewalls at your customer site). ... POSSIBLY compromise my security. ...
    (microsoft.public.vc.mfc)
  • [UNIX] Berkeley pmake Security Vulnerability
    ... Berkeley pmake Security Vulnerability ... There is a format string bug in the Berkeley's pmake 2.1.33 and below ... If the user puts a shell definition into the Makefile, ... static char eb; ...
    (Securiteam)