System users will be created with no aging information in/etc/shadow, and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in/etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups).
They don't get a/home/ directory either per default.
Does there exist any DNS resolver out that that have not had a single remote exploit? I would say that systemd-resolved is in "good" (should really be "bad") company there and certainly not where nobody else have gone before. A few days after the bug in systemd-resolved where shouted all over the Internet there where a new CVE issued for bind but no one seams to have been as upset about that.
And no, systemd-resolved is not core-Linux, not more than dnsmasq or bind is.
systemd does not have TCP capacities either. systemd-resolved which is a DNS resolver does of course since it would be strange to have a DNS resolver without network capacities. So systemd have not had a remote access bug either, systemd-resolved had one, and so have dnsmasq, bind and many other DNS resolvers.
The unit files are portable because the exact same thing will happen regardless of if your specific system would allow that username or not. If "0day" would work on one system but not on another (which currently is the case) then the unit file would not be portable since it would work on one of those systems but not the other.
This old FUD again? Systemd does not and have never swallowed any logs. In fact it (in contrast with sysv init) even preserves everything the daemon outputs to stdout and stderr by sending it to the journal together with the logs from syslog.
It makes unit files more portable since the restrictions on usernames are stricter in systemd that on some other distribution which means that your unit file will work on those distributions where the username restrictions are stricter than the one you created the unit file on. I.e let's say that your distribution allows any byte sequence as a username and you create a unit file with "0x00 0x02" as the username, then some one else tries to use your unit file on a distribution that does not allow this and the unit file refuses to work, so if systemd denies your username even on the less restrictive distribution then it makes sure that your unit file works in that other distribution.
Well that rpm/deb/whatever could run scripts as root when you install it with dpkg/apt anyway. No one is going to attack you this way and the main reason to run the service as user XX is to try and limit the damage in case the specific service gets exploited.
Second that. Had a work computer with Windows 2000 on it. Got some cheap WLAN card for it and it turned out that it would not work if the internal sound card was enabled so you had to choose between wireless or audio. Installing Gentoo on the same machine made both cards work simultaneously for some reason. My guess is that the fault lied in the crappy ass Windows drivers supplied with the wlan card.
Unless it's a part of the script that they are given:
1. Call people and say "Hello I'm calling from Windows and we have detected that you have a security problem with your computer" (yes they have always claimed to be from "Windows" when they have called me.
2. Make victim give remote access.
3. Run exploit.exe
4. Hang up
And then the people in the UK where doing the final steps with the credit card theft and so on.
Sounds like a reverse SELinux/AppArmor. With SELinux/AppArmor you create profiles for applications where you can control which directories and/or files they can read, write and create. This solution sounds like they mark certain folders as special and whitelist access to them from certain applications.
If so then they are far far long away from "where nobody else have gone before".
There does not exist man pages on your computer?
System users will be created with no aging information in /etc/shadow, and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups).
They don't get a /home/ directory either per default.
Full escalation? You don't start home written unit files in order to contain escalation attacks.
Does there exist any DNS resolver out that that have not had a single remote exploit? I would say that systemd-resolved is in "good" (should really be "bad") company there and certainly not where nobody else have gone before. A few days after the bug in systemd-resolved where shouted all over the Internet there where a new CVE issued for bind but no one seams to have been as upset about that.
And no, systemd-resolved is not core-Linux, not more than dnsmasq or bind is.
systemd does not have TCP capacities either. systemd-resolved which is a DNS resolver does of course since it would be strange to have a DNS resolver without network capacities. So systemd have not had a remote access bug either, systemd-resolved had one, and so have dnsmasq, bind and many other DNS resolvers.
The unit files are portable because the exact same thing will happen regardless of if your specific system would allow that username or not. If "0day" would work on one system but not on another (which currently is the case) then the unit file would not be portable since it would work on one of those systems but not the other.
Is that why tools such as "adduser" have a "--system" flag to "Create a system account."?
This old FUD again? Systemd does not and have never swallowed any logs. In fact it (in contrast with sysv init) even preserves everything the daemon outputs to stdout and stderr by sending it to the journal together with the logs from syslog.
It makes unit files more portable since the restrictions on usernames are stricter in systemd that on some other distribution which means that your unit file will work on those distributions where the username restrictions are stricter than the one you created the unit file on. I.e let's say that your distribution allows any byte sequence as a username and you create a unit file with "0x00 0x02" as the username, then some one else tries to use your unit file on a distribution that does not allow this and the unit file refuses to work, so if systemd denies your username even on the less restrictive distribution then it makes sure that your unit file works in that other distribution.
Well that rpm/deb/whatever could run scripts as root when you install it with dpkg/apt anyway. No one is going to attack you this way and the main reason to run the service as user XX is to try and limit the damage in case the specific service gets exploited.
Hardly (considering that I'm not American), but I've been told that sarcasm doesn't work on the Internet so sorry that you misread my post.
"an old analogue tape" is not a reference to a master tape. It's referring to one of these: http://www.telegraph.co.uk/con...
So the NSA?
So you don't do business then ;)
I think you missed one step where the lead programmer opens a thread on Stack Overflow with "I make app how? Please advise"
I wonder if those old boxes in India running XP are even capable of running Windows 10?
Can you even run Windows 10 on those old boxes?
Second that. Had a work computer with Windows 2000 on it. Got some cheap WLAN card for it and it turned out that it would not work if the internal sound card was enabled so you had to choose between wireless or audio. Installing Gentoo on the same machine made both cards work simultaneously for some reason. My guess is that the fault lied in the crappy ass Windows drivers supplied with the wlan card.
It's Sony, they will find a way
Better sound range than an old analogue tape yes, but not than a CD.
If you use such high quality power poles then you must also invest a bunch of Shakti stones: http://www.shakti-innovations....
Unless it's a part of the script that they are given:
1. Call people and say "Hello I'm calling from Windows and we have detected that you have a security problem with your computer" (yes they have always claimed to be from "Windows" when they have called me.
2. Make victim give remote access.
3. Run exploit.exe
4. Hang up
And then the people in the UK where doing the final steps with the credit card theft and so on.
Well you have a valid point there!
Sounds like a reverse SELinux/AppArmor. With SELinux/AppArmor you create profiles for applications where you can control which directories and/or files they can read, write and create. This solution sounds like they mark certain folders as special and whitelist access to them from certain applications.
So the worlds first perpetuum mobile eh?