21–30 of 57 posts
Loopholes of this kind exist these days as well. When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
On succifiently offline systems, you can still run software like that. It's quite freeing to have a server with 777 on your home directory when the biggest problem it'll cause is someone pranking you by altering your terminal color scheme to something hideous.
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot as regular user, e.g. `zypper --installroot ~/tw install bash`.
FUSE doesn't really relate to single vs. multi-user AFAICT.
Users are perfectly sandboxed if you configure the system that way. Depending on the distribution that's even the default.
Loopholes of this kind exist these days as well. When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
In the Middle Ages, when Internet access wasn't in your pocket all the time, I was in a hostel which had Internet kiosks, you'd put a coin in a machine, and the PC would start 2 browser windows: 1 with just a countdown, and one for you to browse. You'd have to put more coins or when the time ends the browser would be killed. Of course there was nothing else in the UI except this window and the browser, but on ancient…
Earlier quoted context omitted.
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
Unix was very much made for multi user environments. The problem with staying compatible with Unix today is that back when Unix came to be, everyone on the system was more or less trusted. The biggest security concern was making sure that everyone who was logged in was billed correctly. On succifiently offline systems, you can still run software like that. It's quite freeing to have a server with 777 on your home dir…
I don't know about that... It doesn't even support multiple administrators. And you can't even distinguish between actions performed by the system itself and the administrative user.
Yes I know about sudo.
What do you need to do and what do the (even audit) logs say about who performed an activity whenever administrative activity happens?
Do organization still apply for these kind of patents?
We used to be a real society
Earlier quoted context omitted.
Unix was very much made for multi user environments. The problem with staying compatible with Unix today is that back when Unix came to be, everyone on the system was more or less trusted. The biggest security concern was making sure that everyone who was logged in was billed correctly. On succifiently offline systems, you can still run software like that. It's quite freeing to have a server with 777 on your home dir…
> Unix was very much made for multi user environments. ... The biggest security concern was making sure that everyone who was logged in was billed correctly. I don't know about that... It doesn't even support multiple administrators. And you can't even distinguish between actions performed by the system itself and the administrative user. Yes I know about sudo. What do you need to do and what do the (even audit) logs…
You can easily create multiple accounts that have the uid 0. Groups are a fundamental part of discretionary access system and several administrative groups exist by default. Your modern desktop oriented distribution may not take advantage of these facts.
> logs say about who performed an activity whenever administrative activity happens?
Simply enable process accounting and setup a program to capture that information. The early BSD distributions had this and had many command line tools to query the information it stored.
>Ritchie is the inventor of the elegant setuid concept, for which a patent was awarded. Do organization still apply for these kind of patents?
Wow, they even used the accurate term "crackers", I feel so old.