Tag Info

New answers tagged

0

I was looking for something like this (bash): hash=$(sudo cat /etc/shadow |grep "^$USER:" |cut -d: -f2) cmphash=$(mkpasswd -m sha-512 -S "$(echo "$hash" | cut -d '$' -f3)") cmp <(echo "$hash") <(echo "$cmphash") && echo "Correct password!" This works but harcodes the hash method which somehow identified by the number in echo "$hash" | cut ...


2

Most modern Unix systems use PAM to handle authentication. The pam_unix module is the one that does password authentication against /etc/password and /etc/shadow. However, you shouldn't reinvent the wheel. Asking for the user's password and running as root is a basic configuration of sudo, the de facto standard way to elevate privileges. Note that properly ...


1

Setting a password with passwd or chpasswd generates a random salt, so users who happen to have the same password would not have identical hashes. In order to have identical hashes this way, you'd have to have a misconfigured system that somehow doesn't save entropy between reboots, and systems that are so completely identical as to repeat the random seed ...


1

You could simply read documentation on this vulnerability and update instructions. E.g. redhat provides extremely detailed information: Do I need to reboot or restart services after installing the update for CVE-2014-6271 and CVE-2014-7169? If your system uses exported Bash functions, restarting affected services is recommended. Affected ...


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 ...


3

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

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 ...


6

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. ...


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 ...


0

Instead of using sudo to grant the possibility to use unshare, you could use the setuid bit, because the unshare program is designed to work with it. It says in the man page: The unshare command drops potential privileges before executing the target program. This allows to setuid unshare. So after executing sudo chmod u+s /usr/bin/unshare, running ...


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.


-1

First change user and group to root chown -R root:root /tmp/uploads then change permissions so that only root can write chmod -R 755 /tmp/uploads EDIT: If you only need to restore files owners, I would save your files and owner in a file (There sure are better ways to do this, but this is the first thing that comes to my mind). Be sure ...


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. ...


0

This doesn't answer the exact question asked, but an alternate solution is to have the log live on a different server / VM, make it append-only using chattr +a and then mount it over the network. This is not without drawbacks, but in my opinion is one of the best approaches to solving this problem.


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 ...


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 ...


0

As @wurtel said in his comment, I believe that the login process is being timesliced by other boot-time processes, combined with hard drive I/O. The ironic answer would be to log in (natch!) and watch top and/or iostat and/or vmstat to see what the system is busy doing while you try to log in (again). I would say "always wait for the password prompt" ...


0

The default behaviour of the TTY is to echo (immediately display) whatever the user types to the screen. This provides instant feedback of keys pressed. This is the mode the TTY device is in when the login: prompt is shown. Before asking for the password, the login program makes a system call to change the mode of the TTY to not echo typed characters (so ...


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/


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 ...


0

You can add a password to /etc/group or /etc/gshadow. Format is similar to /etc/passwd, except that the number of fields differs. You still need to put the password in the second field, though.


0

I ended up talking to the organization's IT and resolved the issue easily. My mistake consists of several missteps: including the wrong certificate not including the right root certificate not ordering the certificates in the right order The "CA certificate" file needs to be a single text file (PEM format) containing a list of certificates, chained in ...


0

Get a friend to try logging in, or use a smartphone, or go to a public hotspot and try from there, or leach the internet of your neighbours, or just wait until some scriptkiddo tries to log in. There are many ways, but they all involve "just do it"...


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.


0

FIPS 140 applies to a specific product. Validating a cryptographic library does not make a product using it validated, nor does validating a product make its components validated. FIPS 140 level 1 compliance is not really a security certification, it's mostly a functional certification. To meet FIPS 140 level 1, you need (when the product is running in FIPS ...



Top 50 recent answers are included