Hacker Newsnew | past | comments | ask | show | jobs | submit | program9's commentslogin

I've worked on apps like this, and I didn't know or care which user was going to use the features requiring elevation. So I couldn't manage permissions per user. My approach to security was to simply limit the input (method parameters usually) from the unprivileged process. For example, not letting the client send arbitrary commands to execute, use filesystem path whitelists, only elevate when required, etc. If the privileged code uses a resource, and that resource can be changed/replaced by an unprivileged user, then the privileged code can be manipulated. Like a Registry key in HKCU for example, or a file in a user's AppData folder. Using enums as method parameters for privileged code helped me avoid some obvious vulns I might've otherwise created. I've definitely done it the wrong way before. It can be tough.


This is generally how I've approached this problem as well. I like using the `ServiceController.ExecuteCommand` method and just send some integer value from the client -> server...and the server maps the integer value to a pre-determined command.

https://docs.microsoft.com/en-us/dotnet/api/system.servicepr...

You've definitely outlined the risk clearly of allowing a client to specify anything arbitrarily.

I once wrote a sudo implementation for Windows Vista / Windows 7 and first attempt used named pipes communicating to a windows service that did some token manipulation to execute things as the user (but with elevated token attached as well). There be (security) dragons.

I like using named pipes and they are a great IPC mechanism for communicating amongst processes of the same privilege level. I would not use them for message passing between processes of different privilege levels.


People will pay for that


I personally find that super attractive if they lack all skills and intelligence and their only redeemable feature is being hot. If I was the type to pay for OnlyFans, I would certain shell out for a girl like that.


Would you rather pay for a boring hot person or an interesting hot person?


No -- downstream devs are responsible for the safety of their own apps, users, and org.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: