Tag Info

Hot answers tagged

6

To be honest, if you're going to allow users to run everything except a few commands, you're going to run into problems. For example, you're disallowing access to the user* commands yet users can still run vipw or even just edit the password and shadow files using a text editor. And if you lock down access to vi for example, what's do prevent them ...


5

Use attributes: chattr -R +i files (as root) will add the +i attribute recursively to your folders and files which will prevent ANY alternations. Note that root will also be locked and you would need to unset the i manually every time. Ownership and alike will be left unchanged.


5

Don't allow USB access. Truth is that if someone has physical access to the machine, there's not a lot you can do. In this narrow case your best bet is to disable booting to USB and lock the BIOS (or whatever EFI setup utility is being used) with a password. It's a bit like putting a pad lock on a garage door, there are ways around it, but it's an easy ...


4

There is really only one answer to this: full disk encryption. The way full disk encryption is usually done with Linux, your /boot partition is not encrypted and contains the kernel and initramfs — just enough functionality to start a minimal environment that prompts you for the passphrase to decrypt the root filesystem and get access to everything else. ...


2

I read with Wayland there comes the infrastructure to prohibit it, but now it's still a problem. Just see xinput test-xi2 The first article I read about the problem: http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html Further and deeper discussion: http://lwn.net/Articles/517375/


2

There is no thing as default autostart from a removable device in the DEs I know. So the only malicious code executed would bugs in the filesystem (unlikely) and bugs in the applications used to open the files. I would search for known security problems in the programs used (like LibreOffice etc). Where to find these depends on the program and the ...


2

Not sure what you mean by "a directory and its users inside". The root user can always write to any file, so to make a file or directory writable only to root you make it non-writable by user, group, and others. Note that the webroot dir is supposed to be writable by the apache user, so what you're trying to do is to give it the incorrect permissions. ...


2

On Ubuntu: $ sudo cat /var/log/auth.log|grep ssh|grep Accept On CentOS/RHEL: $ sudo cat /var/log/secure|grep ssh|grep Accept This will show all connections, and how they authenticated [since the log file's last rotation]. If you only want to see password connections, just pipe through another grep: ... grep ssh|grep Accept|grep password


1

Environment variable approach Here's one possibility....if you're happy to have PermitUserEnvironment set to true in your sshd_config then you could use a combination of environment variable against the key and some checking in /etc/profile to alert/reject anyone still using password approach. In your $HOME/.ssh/authorized_keys file you'd have something ...


1

In order to attack a server the attacker must first know its IP address. With IPv6 you will have so many addresses to choose from that it is not feasible to find the correct address by scanning the IP range. This means you can simply assign two different IPv6 addresses to the interface. You let the domain name of your site keep pointing to the same IP ...


1

I do not remember doing anything that day that may have generated these files, nor did I download them as I don't even know what these files are or why they're there. You can have a look at history, maybe there is a clue and you remember what could have caused this. Since these files look a lot like they are part of your system, you can try to locate ...


1

Solution Create a new Group: groupadd -r updaters The -r option reserves a system group, i.e. 0 - 100. Add Users to Above Group: useradd -G updaters john, useradd -G updaters sally. You can also use the user alias section to acheive this. See Sudoer File Examples for a fully functioning User Alias Section. In my opinion, doing it the way I've done ...


1

You seem to be using the wrong tool for the job. Passwords for groups are a rarely-used feature; most of the times, you assign each user to whatever groups you want, and they get group privileges when they log in, without having to do anything special. If you want users to have to take some action when they want to use group privileges, for example for ...


1

While eCryptFS is actively maintained by Canonical/Ubuntu engineers and the design is cryptographically sound, eCryptFS has never been formally evaluated for FIPS 140-2 certification or compliance, and it's unlikely that it ever will be. Full disclosure: I am one of the authors and maintainers of eCryptFS.



Only top voted, non community-wiki answers of a minimum length are eligible