Tag Info

Hot answers tagged

23

Short answer: Yes. In the "olden days", it was possible to effectively prevent any other X application from reading a specific input by grabbing it. While this can still be done to this day, the XI2 protocol specification seems to suggest that this can't be done any more (see the description of Raw Events around line 2220). Thus under X alone you are not ...


4

Under the following conditions you could lock yourself out at the keyboard. If you block all outbound network traffic with IPTABLES. AND If you use some sort of network authentication like LDAP or NIS for user logins. As a result the system can not access the external service so you won't be able to login with those user ID's. AND you have no other local ...


2

When you've been rooted (and it sounds like you have been), the recommended practice is to reinstall the OS and to carefully restore your data from backups. If it's an important system, I'd disconnect it from the network straight away. If the server isn't that important, it can be educational to spend time attempting to track down the root cause so that you ...


2

The apt file in /etc/cron.daily includes instructions for this: # Create /etc/apt/apt.conf.d/02periodic file to set your preference. .... # # APT::Periodic::Unattended-Upgrade "0"; # - Run the "unattended-upgrade" security upgrade script # every n-days (0=disabled) # Requires the package "unattended-upgrades" and will write # a log in ...


2

If it's absolutely important to run only on Saturdays, then do this: Remove the package anacron. Note that this also removes ubuntu-desktop, but you probably won't need it on a server. This is necessary, because otherwise it's impossible to control on which day of the week Anacron will run the jobs in /etc/cron.weekly. Edit the file /etc/crontab, it should ...


2

What the above is talking about is on the client side. To answer that, all users that can log-in (with the exception of root, see below) should not be in the local machine's /etc/passwd and /etc/shadow. Instead, those users should be in the NIS server's /etc/passwd and /etc/shadow Tip use NIS+ instead of NIS. Tip that article was written in 2003, I ...


2

I assume these counters (eth0, eth1) refer to layer 2 data. Thus the eth1 traffic would be the ppp0 traffic plus the PPPoE overhead. Furthermore Ethernet transfer has collisions (as shown in your output), virtual interface traffic doesn't. Another source for traffic increase is the MSS handling (for TCP). I.e. the router sends ICMP packets which have not ...


2

The personal data in /etc/passwd is user names, office locations and phone numbers. That's the 1970s version of the company phonebook. When Unix was designed, it was expected that people who have an account on the same machine would be members of the same organization (colleagues, fellow students, etc.). If you don't want your users to have access to that ...


2

I would have to agree. /etc/passwd has not contained very sensitive data for a while now. I believe /etc/shadow is where lots of data that needs to be protected should be stored.


1

The unattended upgrade script in /etc/cron.daily/apt uses upgrade intervals expressed in days, so setting anything more frequent than one day is not possible. You can use standard cron - put this in /etc/cron.d: SHELL=/bin/bash PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 0 0-23/4 * * * root apt-get -q update && apt-get ...


1

Sounds like you are getting confused between the pi user and the pi group. You cannot add a group to a group, only users. There is a group with the same name as a user, the groups the user is in have no effect on the users that are in the group.


1

I am using ubuntu and had same issue Solution: add-shell /sbin/nologin sudo usermod -s /sbin/nologin ftpme sudo vi /etc/pam.d/vsftpd Then comment and add lines as following #%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed auth required ...


1

There are multiple newer ways to store this kind of data, including but not limited to LDAP and NIS. The question you have to ask is why there's private information in /etc/passwd in the first place.


1

When I worry about this, I run sudo -k; sudo date && sudo -n wooden-horse-command. Then I'll be prompted for the password exactly once (by sudo date), and the sudo ticket should be fresh for the following command. Not that this gains much in terms of security, you understand. A malicious program that installs a keylogger will be more effective at ...


1

in simplest form, if login and authentication is dependant on network connectivity while console login is disabled (that can be done too, for physical security purposes).



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